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

У нас есть 2 доменных среды. У нас были проблемы с медленными подключениями, сбоями аутентификации и зависанием ресурсов только в часы ОТКЛЮЧЕНО-ПИК, когда было очень мало пользователей, вошедших в систему.

Проблема возникла, когда пользователь из DOMAIN A обращается к ресурсу, расположенному в DOMAIN B, и использует проверку подлинности ntlm. Нет проблем с пользователями из DOMAIN A, получающими доступ к ресурсам в DOMAIN A, или с пользователями из DOMAIN B, получающими доступ к ресурсам в DOMAIN B.

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

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

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

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

При этом стоит отметить, что DC, который работает, - это сервер 2008, а те, которые не работают, - это сервер 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" не будет испытывать затруднений при разговоре с DC 2012 в "A", но Dcs 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