Проверка подлинности SharePoint (WSS) на нескольких доменах

Question

Во-первых, немного предыстории: у нас есть сайт интрасети на основе WSS 3.0, который размещен на сервере в DOMAIN_A.LOCAL и настроен на использование встроенной проверки подлинности Windows для проверки подлинности. пользователи против учетных записей пользователей Active Directory DOMAIN_A.LOCAL .

Эта установка прекрасно работает для пользователей, которые вошли в Windows с использованием учетной записи AD из DOMAIN_A.LOCAL , но когда пользователи пытаются получить доступ к сайту с ПК, подключенного к Windows При использовании учетной записи AD из другого домена (например, DOMAIN_B.LOCAL ) возникают следующие проблемы:

1. Пользователь должен вручную ввести свои учетные данные как DOMAIN_A \ UserName , а не просто UserName , иначе Internet Explorer автоматически вставляет DOMAIN_B и вызывает сбой аутентификации.

2. После входа в систему пользователь, выполняющий что-то, требующее, чтобы браузер передал свою аутентификацию клиентскому приложению, например щелкает документ Microsoft Office в библиотеке документов, чтобы открыть его для редактирования, Похоже, что неверные учетные данные (предположительно DOMAIN_B ) передаются автоматически, что вынуждает пользователя вручную вводить свои DOMAIN_A учетные данные еще раз.

Мой вопрос, тогда это:

Есть ли способ реализовать тип поведения «домен по умолчанию» при использовании встроенной проверки подлинности Windows (как это можно сделать при использовании обычной проверки подлинности с открытым текстом), чтобы при использовании пользователем DOMAIN_B не входит в домен до имени пользователя, DOMAIN_A автоматически вставляется для них?

Конечно, я понимаю, что это развертывание может иметь серьезные недостатки, поэтому я также открыт для предложений по другой реализации.

Таким образом, основная проблема связана с двумя разными типами пользователей, которым необходим доступ к одному и тому же контенту на одном сайте SharePoint. Пользователи в DOMAIN_A имеют свои собственные рабочие места, работающие полный рабочий день, где они входят в Windows сами. К сожалению, пользователи в DOMAIN_B должны использовать общие компьютеры, которые вошли в систему с использованием общих учетных записей типа «киоск», которые не имеют разрешений в SharePoint - таким образом, требование DOMAIN_B пользователи должны предоставлять свои учетные данные по требованию при доступе к определенной странице в SharePoint. Я хотел бы сохранить удобство встроенной аутентификации Windows для «статических» пользователей DOMAIN_A , при этом сводя к минимуму количество ручной аутентификации, которое пользователи «киоска» в ДОМЕН_Б терпеть.

Answer 1

DOMAIN_A.LOCAL должен доверять DOMAIN_B.LOCAL , в противном случае пользователи из DOMAIN_B.LOCAL получат запрос на ввод учетных данных, поскольку их DOMAIN_B.LOCAL учетная запись неизвестна в DOMAIN_A.LOCAL .

Учитывая, что DOMAIN_B.LOCAL предназначен для пользователей кисок, вы, вероятно, не хотите доверять этому домену.

Вам потребуется расширить веб-приложение в новую зону и либо внедрить проверку подлинности на основе форм, либо использовать проверку подлинности Windows с обратным прокси-сервером, например ISA-сервером.

Answer 2

Я искал в Интернете учетные записи пользователей SharePoint с несколькими доменами и наткнулся на интересный инструмент под названием Microsoft Front End Identity Manager. Вы слышали об этом?

Итак ... Если вы используете развертывание с несколькими лесами, где учетные записи пользователей распределены по двум или более лесам. Это часто наблюдается, когда две организации объединяются, и им необходим доступ к доменам из обеих организаций. Вы можете использовать атрибут различающегося имени (ms-ds-Source-Object-DN) в объекте пользователя, чтобы создать связь между учетными записями пользователей. В этой ассоциации одна учетная запись считается основной учетной записью, а другие являются альтернативами основной учетной записи. Существует инструмент под названием Microsoft Front End Identity Manager для создания этой взаимосвязи между объектами учетной записи пользователя. Одна из особенностей Microsoft Front End Identity Manager заключается в том, что сервер SharePoint может вести список альтернативных учетных записей, по которым определяется профиль. Когда вы используете любую учетную запись для поиска профиля пользователя, сервер SharePoint возвращает пример основного профиля учетной записи (домен \ имя пользователя).

Answer 3

К сожалению, если вы хотите сохранить интеграцию с Microsoft Office (что, как вам кажется, нужно), вам придется придерживаться проверки подлинности Windows. Использование проверки подлинности с помощью форм удалит большинство функций, которые, по-видимому, вы хотели бы сохранить, для получения дополнительной информации здесь .

В идеале вы хотите использовать предложение, упомянутое Джейсоном, которое будет своего рода обратным прокси. Однако, возможно, это будет связано с затратами, если у вас еще нет чего-то похожего на ISA-сервер, поэтому в действительности, вероятно, DOMAIN_B лучше всего научится набирать DOMAIN_B \ перед своим именем пользователя.

Answer 4

Возможно, это не то, что вы хотите услышать, но вы можете прибегнуть к аутентификации на основе форм.