Назад | Перейти на главную страницу

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

У нас есть двухдоменная среда. У нас были проблемы с медленным подключением, сбоями аутентификации и зависанием ресурсов только в часы OFF-PEAK, когда было очень мало пользователей.

Проблема возникала, когда пользователь из ДОМЕНА A получает доступ к ресурсу, расположенному в ДОМЕНЕ B, и использует аутентификацию ntlm. Нет проблем с доступом пользователей из DOMAIN A к ресурсам в DOMAIN A или с доступом пользователей из DOMAIN B к ресурсам в DOMAIN B.

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

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

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

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

Как бы то ни было, DC, который работает, - это server 2008, те, которые не работают, - server 2012 R2, однако проблема существовала на некоторых контроллерах домена до миграции на 2012 R2, мы просто не определили проблему, пока после того, как мы закончили их перенос.

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

Изменить: дополнительная информация ...

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

Каждые

[LOGON] SamLogon: Transitive Network logon of DOMAINA\testuser Entered

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

[LOGON] SamLogon: Transitive Network logon of DOMAINA\testuser Returns 0x0

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

[LOGON] ... DOMAINA\testuser ... Returns 0xC0020017
[LOGON] ... DOMAINA\testuser ... Returns 0xC0020050
[LOGON] ... DOMAINA\testuser ... Returns 0xC000005E

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

77% of errors were: 0xC0020017 RPC SERVER UNAVAILABLE
21% of errors were: 0xC0020050 RPC CALL CANCELED
 1% of errors were: 0xC000005E NO LOGON SERVERS AVAILABLE
 0% of returns were: 0x0 (no error)

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

Изменить: дополнительная запрошенная информация ...

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

C:\>nltest /dsgetdc:DOMAINA.local
           DC: \\DC-A3.DOMAINA.local
      Address: \\555.555.555.127
     Dom Guid: 9f3a0668-c245-4493-be03-0f7edf534d27
     Dom Name: DOMAINA.local
  Forest Name: DOMAINA.local
 Dc Site Name: Company
Our Site Name: Company
        Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9
The command completed successfully

Изменить: дополнительная информация ...

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

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

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

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

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

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

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