Аутентификация Active Directory через доверие и запросы пользователей из доверенного домена
Домен A (корень лесного дерева) (основной домен)
Домен B (Прямой Исходящий) (Прямой Входящий)
Между двумя лесами домен A/B существует двустороннее доверие. Этот сценарий используется для соединения двух компаний.
Теперь предположим, что у нас есть приложение, которое использует активный каталог для аутентификации в Домене А.
Пользователь из домена B добавляется в группу, которая существует в домене A, что позволяет ему получить доступ к этому приложению. Это приложение использует ADSI для подключения к контроллеру домена Domain A для аутентификации пользователя.
Первый вопрос. Используя ADSI от контроллера домена в Домене A, узнает ли он, что нужно пройти через доверие и проверить пользователя в Домене B? Или же приложение должно указывать на контроллер домена в домене B?
Второй вопрос: чтобы получить список всех пользователей в домене B из домена A, смогу ли я запросить это, например, в powershell, используя ADSI/LDAP от контроллера домена в домене A, или мне нужно будет специально обратиться к контроллеру домена в домене B?
Спасибо!
1 ответ
1) Приложение не будет использовать ADSI для аутентификации пользователя. ADSI - это интерфейс COM, а не протокол сетевой аутентификации. Он будет использовать Kerberos или LDAP. Очень полезно знать, какой протокол он на самом деле использует, поскольку доверительные отношения AD применяются только к аутентификации Kerberos.
1a) Если приложение использует Kerberos, оно отправит запрос на обслуживание в локальный DC. Это проверит соответствующий SPN, а затем вернет направление к DC в целевом домене. Затем рабочая станция запросит билет службы из домена назначения и затем получит доступ к приложению. Этот процесс описан в конце этой статьи.
1b) Если ваше приложение использует LDAP, его необходимо настроить так, чтобы оно указывало на один или несколько контроллеров домена в целевом домене. Вы можете использовать само доменное имя в качестве цели, хотя я бы проверил разницу в задержке между использованием жестко закодированного имени DC и просто доменного имени. Если вы используете жестко закодированное имя DC, у вас должен быть какой-то способ определения одного или нескольких вторичных целевых DC, если первый не работает.
2) Если вы выполняете запросы LDAP (через ADSI или иным способом), вам нужно указать фактический целевой домен и учетную запись, которая имеет разрешения на поиск в LDAP (например, любую учетную запись в целевом домене). Вам может потребоваться указать фактическое имя DC (я не проверял его). Ваш локальный домен имеет ссылки на доверяющий домен - он не хранит в нем никаких реальных объектов.