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