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 при минимизации количества ручной аутентификации, что «киоск» пользователей в домене DOMAIN_B придется терпеть.

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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