Netlogon – Проблемы с безопасным каналом доверия домена – Только на некоторых контроллерах домена

У нас есть среда из 2 доменов. Мы сталкивались с проблемами медленных подключений, сбоев аутентификации и зависших ресурсов только в часы низкой загруженности, когда было очень мало пользователей, вошедших в систему.

Проблема возникала, когда пользователь из ДОМЕНА A обращался к ресурсу, находящемуся в ДОМЕНЕ B и использовал аутентификацию NTLM. Не было проблем с пользователями из ДОМЕНА A, обращающимися к ресурсам в ДОМЕНЕ A, или с пользователями из ДОМЕНА B, обращающимися к ресурсам в ДОМЕНЕ B.

Мы смогли отследить проблему до защищенных каналов, которые используются для трафика netlogon. Когда ресурс из домена B имел защищенный канал с одним конкретным контроллером домена (я назову его DC-B1), все работало нормально. Мы можем отследить цепочку трафика от клиента(A) -> ресурс(B) -> DC-B1(B) -> DC-A1(A) (для аутентификации) и затем обратно. Однако, если сервер ресурса в B имел защищенный канал с любым другим контроллером домена в ДОМЕНЕ B, аутентификация зависала и никогда не завершалась.

Таким образом, похоже, что, за исключением DC-B1, каждый контроллер домена в ДОМЕНЕ B испытывает трудности с созданием безопасного канала доверия с ДОМЕНОМ A. Для тестирования мы запустили nltest /sc_verify:DOMAINA с каждого контроллера домена в ДОМЕНЕ B.

Когда запускали с DC-B1, ответ был мгновенным. Когда запускали с любого другого контроллера в домене B, он зависал примерно на 40 секунд, прежде чем показать успех (никогда не показывал ошибку, просто занял много времени).

Какие-нибудь идеи, почему некоторые контроллеры домена испытывают трудности с установкой и использованием защищенного канала доверия, в то время как другой контроллер в том же домене никогда не имеет проблемы?

Для сведения, работающий контроллер — сервер 2008, те, которые не работают — сервер 2012 R2, однако проблема существовала на некоторых контроллерах доменов до миграции на 2012 R2, мы просто не смогли определить проблему, пока не завершили их миграцию.

Спасибо за помощь.

Редактирование: Дополнительная информация…

Сравнили логи NetLogon.log за выходные для каждого из контроллеров домена…

Каждая

[LOGON] SamLogon: Транзитивная сетевая аутентификация DOMAINA\testuser Запущена

запись в логе DC-B1 (это хороший контроллер) имела соответствующую

[LOGON] SamLogon: Транзитивная сетевая аутентификация DOMAINA\testuser Возвращает 0x0

однако на других контроллерах в Домене B каждый возврат имел одну из следующих 3 ошибок:

[LOGON] ... DOMAINA\testuser ... Возвращает 0xC0020017
[LOGON] ... DOMAINA\testuser ... Возвращает 0xC0020050
[LOGON] ... DOMAINA\testuser ... Возвращает 0xC000005E

И вот как часто происходили различные ошибки:

77% ошибок были: 0xC0020017 RPC СЕРВЕР НЕДОСТУПЕН
21% ошибок были: 0xC0020050 RPC ВЫЗОВ ОТМЕНЕН
 1% ошибок были: 0xC000005E НЕТ ДОМЕННЫХ СЕРВЕРОВ ДЛЯ АУТЕНТИФИКАЦИИ
 0% возвратов было: 0x0 (нет ошибки)

Мы сравнили все параметры безопасности между контроллерами, которые не работают, и тем одним, который работает, но ничего не нашли, что могло бы вызвать проблемы с RPC. Есть ли предложения, куда мы могли бы посмотреть дальше? Мы озадачены тем, почему контроллер домена 2008 в “B” не испытывает проблем при общении с 2012 DC в “A”, но 2012 DC в “B” не могут использовать пассивную аутентификацию к “A”.

Редактирование: Дополнительная запрашиваемая информация…

Тестовый запуск с DC-B2 и DC-B3 (одинаковые результаты)
(пассивная аутентификация, исходящая отсюда, не работает)

C:\>nltest /dsgetdc:DOMAINA.local
           DC: \\DC-A3.DOMAINA.local
      Адрес: \\555.555.555.127
     Dom Guid: 9f3a0668-c245-4493-be03-0f7edf534d27
     Dom Name: DOMAINA.local
  Forest Name: DOMAINA.local
 Dc Site Name: Компания
Our Site Name: Компания
        Флаги: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9
Команда выполнена успешно

Редактирование: Дополнительная информация…

Результаты от PortQry из Домен B -> Домен A (GC DC)

TCP порт 135  (epmap service):      LISTENING
TCP порт 389  (ldap service):       LISTENING
UDP порт 389  (unknown service):    LISTENING или FILTERED
TCP порт 636  (ldaps service):      LISTENING
TCP порт 3268 (msft-gc service):    FILTERED
TCP порт 3269 (msft-gc-ssl service):    FILTERED
TCP порт 53   (domain service):     NOT LISTENING
UDP порт 53   (domain service):     NOT LISTENING
TCP порт 88   (kerberos service):   LISTENING
UDP порт 88   (kerberos service):   LISTENING или FILTERED
TCP порт 445  (microsoft-ds service):   LISTENING
UDP порт 137  (netbios-ns service):     LISTENING или FILTERED
UDP порт 138  (netbios-dgm service):    LISTENING или FILTERED
TCP порт 139  (netbios-ssn service):    LISTENING
TCP порт 42   (nameserver service):     FILTERED

После того как мы прислушались к совету Грега и сосредоточились на брандмауэре, мы нашли решение. В какой-то момент в прошлом изменилось правило брандмауэра, и диапазон динамических портов (49152-65535) фильтровался. Как только сетевые специалисты добавили правило для разрешения динамических портов от ДОМЕНА B к ДОМЕНУ A, проблема была полностью решена.

По какой-то причине в сервере 2008 это вызывало проблемы только в момент создания защищенного канала. Создание защищенного канала занимало 21 секунду (или какое-то кратное 21 секунде). После создания защищенного канала аутентификация работала нормально. Задержка в 21 секунду имеет смысл из-за природы TCP-связи.

В сервере 2012 R2 поведение было другим. Независимо от того, был ли защищенный канал установлен между доменами, аутентификация не удавалась и разрушала защищенный канал, чтобы искать другой доступный контроллер домена.

Я не совсем понимаю, почему это вообще работало на сервере 2008… возможно, он использовал другой порт где-то, когда не удавалось установить соединение в эфемерных портах?

В любом случае мы извлекли ценный урок: “Это (фильтрованные порты) должно быть первым пунктом проверки, если возникают проблемы с подключением RPC” – Грег Аскью