none
Ошибки 5723, 5805 на RODC. Locator DC и мониторинг пакетов. RRS feed

  • Вопрос

  • У нас в продуктивном домене domain.local есть несколько RWDC и два RODC. Продуктивный домен связан односторонними трастами с тестовыми доменами extranet.ad и ext-tst.ad.

    В логах RODC каждые 4 часа регистрируются ошибки 5723, 5805, в которых фигурируют контроллеры из доменов extranet.ad и ext-tst.ad.

    Например:

    The session setup from the computer EXT-DC-03 failed to authenticate. The following error occurred:
    Access is denied.

    The session setup from computer 'EXT-DC-03' failed because the security database does not contain a trust account 'extranet.ad.' referenced by the specified computer.  

    Я честно перечитал половину гугла, выяснил что "трастовые пароли не кешируются на RODC", что "нужно проверить, не клонировались ли контроллеры домена без сиспрепа", но так и не понял, как же конкретно устранить эти ошибки.

    Я проверил ObjectSID на всех контроллерах домена посредством psgetsid.exe, они все разные.

    Например:

    SID for EXTRANET\rext-dc-02$:
    S-1-5-21-1398328625-2254300882-3254197521-4107

    Трасты работают, проверено. Они даже пересоздавались.

    Что еще нужно проверить и как это проверить? Я на три раза прочитал все статьи, которые смог нагуглить, нужна помощь.


    MCITP:SA, MCTS:Exchange Configuring


    • Изменено Dmitry Zobnin 14 декабря 2012 г. 11:17
    12 декабря 2012 г. 14:52

Ответы

  • 1. Переименование сайта вряд ли поможет: имя сайта для клиента возвращается с КД domain.local (который ничего не знает о сайтах в лесу extranet.ad) и поиск доверенного КД производится в сайте в домене domain.local.

    2. По идее, RODC, получив по NTLM запрос на аутентификацию по имени участника безопасности (учетной записи доверяющего домена), пароль для которого у него отсутствует, должен перенаправить запрос на аутентификацию на RWDC, опять-таки, по NTLM. Непонятно, происходит ли это у Вас. Проверить можно, промониторив пакет одновременно на RODC.

    3. Вообще, имеет смысл проверить, может ли RODC перенаправить запрос аутентифкации по NTLM на RWDC. Проще всего проверить это, попытавшись подключиться с компьютера где работает пользователь под учетной записью, пароля которой на RODC нет, к общей папке на RODC, указав его по его IP-адресу (это исключает использование протокола Kerberos, более предпочтительного в других случаях). Короче, с компьютера, на котором Вы залогинились под учеткой из группы администраторов домена наберите в окне командной строки команду

    net use \\172.16.22.12

    и посмотрите, пройдет ли она, а если нет - каков код ошибки.

    И последнее, если вам просто нужно заставить эту штуку работать, а не разбираться, что именно там не работает: попробуйте обходной путь - подавите в домене extranet.ad разрешение имен для сайта PDC-DMZ в домене domain.local. Для этого создайте на серверах DNS, выполняющих разрешение для этого домена (как я понимаю, это у Вас КД этого же домена) пустую зону с именем PDC-DMZ._sites.dc._msdcs.DOMAIN.LOCAL. Тогда попытка поиска КД домена domain.local в сайте PDC-DMZ будет неудачной, и локатор перейдет к поиску доменов в других сайтах (которые уже будут не RODC).

    PS Имеет смысл рассмотреть возможность отказа от RODC вообще: если не используются возможности, требующие нахождения серверов в одном домене (например, аутентификация по смарт-картам или ограниченное делегирование Kerberos), то имеет смысл все серверы в DMZ перевести в домен extranet.ad и использовать аутентификацию по учетным записям из domain.local через отношения доверия.


    Слава России!

    • Помечено в качестве ответа Dmitry Zobnin 19 декабря 2012 г. 10:25
    15 декабря 2012 г. 19:34
  • Принято решение убрать RODC из DMZ.

    MCITP:SA, MCTS:Exchange Configuring

    • Помечено в качестве ответа Dmitry Zobnin 19 декабря 2012 г. 10:25
    19 декабря 2012 г. 10:24

Все ответы

  • Вот что обнаружил при запросе SRV-записей о контроллерах продуктивного домена domain.local, выполненного с контроллера тестового домена extranet.ad:

    C:\Users\Administrator.EXTRANET>nslookup
    DNS request timed out.
        timeout was 2 seconds.
    Default Server:  UnKnown
    Address:  172.16.22.6

    > set type=SRV
    > _ldap._tcp.dc._msdcs.domain.local.
    Server:  UnKnown
    Address:  172.16.22.6

    DNS request timed out.
        timeout was 2 seconds.
    *** Request to UnKnown timed-out

    Похоже, что проблема в DNS и разрешение имен действительно сваливается в NetBIOS. Копаем дальше...


    MCITP:SA, MCTS:Exchange Configuring

    12 декабря 2012 г. 15:38
  • Разрешение имен через DNS починил, просто завис один из серверов DNS. Ждем результата.

    MCITP:SA, MCTS:Exchange Configuring

    13 декабря 2012 г. 7:15
  • Проблема с ДНС никак не повлияла на возникновение ошибок, поэтому я начал снифить пакеты. Привожу небольшой отчет.

    Итак, у нас есть два домена: domain.local и extranet.ad. Между ними настроен односторонний траст, ресурсы находятся в домене extranet.ad, пользователи в domain.local.

    В domain.local есть несколько сайтов, для простоты будем считать, что их два: PDC и PDC-DMZ. В PDC находятся writable DC с именами DC-03 и DC-04. В PDC-DMZ находятся два RODC с именами DC-11-RO и DC-12-RO.

    В extranet.ad тоже есть несколько сайтов, но нам важно лишь то, что один из сайтов этого домена, под именем EXTRANET-PDC-DMZ полностью совпадает с сайтом PDC-DMZ домена domain.local. Фактически это одна сеть: 172.16.22.0/23. В сайте EXTRANET-PDC-DMZ домена extranet.ad находятся два writable DC: EXT-DC-03, EXT-DC-04.

    Как я и писал в первом посте, на RO контроллерах DC-11-RO и DC-12-RO возникают ошибки траста вида:

    The session setup from the computer EXT-DC-03 failed to authenticate. The following error occurred: Access is denied.

    The session setup from computer 'EXT-DC-03' failed because the security database does not contain a trust account 'extranet.ad.' referenced by the specified computer.

    Периодичность этих ошибок – несколько часов. Я затрудняюсь сказать, что инициирует процесс аутентификации, возможно обновление траста, возможно что-то еще.

    Я установил на все затронутые проблемой контроллеры Network Monitor и стал ждать ошибки. Далее следует реконструированная картина событий с моими комментариями.

    1. Сервер EXT-DC-03.extranet.ad находится в сайте EXTRANET-PDC-DMZ  и начинает поиск контроллеров домена domain.local в том же сайте:

     QRecord: _ldap._tcp.EXTRANET-PDC-DMZ._sites.dc._msdcs.DOMAIN.LOCAL of type SRV on class Internet

    2. DNS-форвардинг между доменами у нас настроен корректно, поэтому получен ответ:

      Dns: QueryId = 0x53A9, QUERY (Standard query), Response - Name Error

    Это логично, потому что в домене domain.local нет сайта EXTRANET-PDC-DMZ.

    3. Сервер EXT-DC-03.extranet.ad формирует новый запрос для получения уже всех RW-контроллеров домена domain.local

      QRecord: _ldap._tcp.dc._msdcs.DOMAIN.LOCAL of type SRV on class Internet

    4. Получаем ответ со списком всех writable DC домена domain.local:

      Dns: QueryId = 0x24F6, QUERY (Standard query), Response - Success, 10.251.4.6, 10.1.0.6 ...

    5. Сервер EXT-DC-03.extranet.ad выбрал один из полученных серверов, а именно dc-03.domain.local, и переспрашивает его IP по записи типа A:

      QRecord: dc-03.domain.local of type Host Addr on class Internet

    6. Ответ получен:

      Dns: QueryId = 0x769A, QUERY (Standard query), Response - Success, 10.20.0.6

    7. Сервер EXT-DC-03.extranet.ad отправляет некий LDAP-запрос на сервер dc-03.domain.local:

    Filter: (&(DnsDomain=DOMAIN.LOCAL)(Host=EXT-DC-03)(DomainSid=

    )(NtVer=16:00:00:00))

    8. Сервер dc-03.domain.local отвечает на LDAP-запрос. Привожу только часть ответа:

    - NetlogonAttribute: LogonSAMLogonResponseEX (SAM Response to SAM logon request): 23 (0x17)   - SamLogonResponseEx: DC-03.DOMAIN.LOCAL      Opcode: LogonSAMLogonResponseEX      Sbz: 0 (0x0)    + Flags: 0x0000317C      DomainGuid: {4A609164-B742-4AB7-9F02-0EE59BC5943C}      DnsForestName: DOMAIN.LOCAL      DnsDomainName: DOMAIN.LOCAL      DnsHostName: DC-03.DOMAIN.LOCAL      NetbiosDomainName: DOMAIN.LOCAL      NetbiosComputerName: DC-03      UserName:      DcSiteName: PDC     ClientSiteName: PDC-DMZ      NextClosestSiteName: PDC    + Version: 0x00000015 NT Version 5 Client    + LmNtToken: Windows NT Networking: 0xFFFF    + Lm20Token: OS/2 LAN Manager 2.0 (or later) Networking: 0xFFFF

    Обратите внимание, dc-03.domain.local явно сообщил, что клиент находится в сайте PDC-DMZс точки зрения домена domain.local. Он совершенно прав, клиент находится в сети 172.16.22.0/23, а в домене domain.local эта сеть относится к сайту PDC-DMZ. Я полагаю, что именно поэтому дальше процесс обнаружения контроллера домена сворачивает в ненужную для нас сторону.

    9. Вместо того чтобы далее обращаться к dc-03.domain.local (напомню, это writable DC домена domain.local), сервер EXT-DC-03.extranet.ad формирует новый DNS-запрос, с целью выяснить какие же контроллеры есть в сайте PDC-DMZ:

    Dns: QueryId = 0xC03E, QUERY (Standard query), Query  for _ldap._tcp.PDC-DMZ._sites.dc._msdcs.DOMAIN.LOCAL of type SRV on class Internet

    10. На что получает ответ:

    Dns: QueryId = 0xC03E, QUERY (Standard query), Response - Success, 172.16.22.12, 172.16.22.11

    RODC, как известно, публикуют свои SRV-записи только для своего сайта, теперь эти записи обнаружены и мы обречены на скорую ошибку кросс-доменной аутентификации.

    11. Выбирается один из этих DC, уточняется его IP по записи типа A:

    Dns: QueryId = 0x9974, QUERY (Standard query), Query  for dc-12-ro.domain.local of type Host Addr on class Internet

    12. Получаем ответ:

    Dns: QueryId = 0x9974, QUERY (Standard query), Response - Success, 172.16.22.12

    13. Далее идет несколько запросов, которые я не смог идентифицировать, в итоге формируется запрос аутентификации:

    NRPC: NetrServerAuthenticate3 Request, PrimaryName = \\DC-12-RO.DOMAIN.LOCAL, AccountName = extranet.ad., ComputerName = EXT-DC-03, SecureChannelType = TrustedDnsDomainSecureChannel , NegotiateFlags = 0x613FFFFF

    14. Как известно, Read Only-контроллеры не имеют доступа к трастовым паролям, поэтому на DC-12-RO возникает ошибка 5723 и формируется ответ:

    NRPC: NetrServerAuthenticate3 Response, NegotiateFlags = 0x613FFFFF, AccountRid = 0, ReturnValue = 0xC000018B - STATUS_NO_TRUST_SAM_ACCOUNT

    Все, приехали.

    Каково может быть решение в моей ситуации?

    1. Если переименовать сайт EXTRANET-PDC-DMZ домена extranet.local в сайт PDC, тогда на этапе №1 сразу будет сформирован запрос к существующему сайту _ldap._tcp.PDC._sites.dc._msdcs.DOMAIN.LOCAL

    Но в этом случае есть вероятность, что процесс поиска ближайшего контроллера снова свернет на сайт PDC-DMZ, т.к. клиент аутентификации все еще остается в сети 172.16.22.0, а это, как выяснилось, проверяется.

    1. Если разделить сети сайтов EXTRANET-PDC-DMZ и PDC-DMZ, то, возможно, мы получим не лучший результат, потому что такая картина наблюдается еще с одним трастом с доменом ext-tst.ad, про который я писал в первом сообщении.

     

    Итог: я все еще не знаю, как победить данную ошибку. Я планирую поснифить пакеты из домена ext-tst.ad, возможно картина прояснится (там топология слегка отличается, появится возможность сравнить результаты).


    MCITP:SA, MCTS:Exchange Configuring



    • Изменено Dmitry Zobnin 14 декабря 2012 г. 11:22
    14 декабря 2012 г. 11:14
  • 1. Переименование сайта вряд ли поможет: имя сайта для клиента возвращается с КД domain.local (который ничего не знает о сайтах в лесу extranet.ad) и поиск доверенного КД производится в сайте в домене domain.local.

    2. По идее, RODC, получив по NTLM запрос на аутентификацию по имени участника безопасности (учетной записи доверяющего домена), пароль для которого у него отсутствует, должен перенаправить запрос на аутентификацию на RWDC, опять-таки, по NTLM. Непонятно, происходит ли это у Вас. Проверить можно, промониторив пакет одновременно на RODC.

    3. Вообще, имеет смысл проверить, может ли RODC перенаправить запрос аутентифкации по NTLM на RWDC. Проще всего проверить это, попытавшись подключиться с компьютера где работает пользователь под учетной записью, пароля которой на RODC нет, к общей папке на RODC, указав его по его IP-адресу (это исключает использование протокола Kerberos, более предпочтительного в других случаях). Короче, с компьютера, на котором Вы залогинились под учеткой из группы администраторов домена наберите в окне командной строки команду

    net use \\172.16.22.12

    и посмотрите, пройдет ли она, а если нет - каков код ошибки.

    И последнее, если вам просто нужно заставить эту штуку работать, а не разбираться, что именно там не работает: попробуйте обходной путь - подавите в домене extranet.ad разрешение имен для сайта PDC-DMZ в домене domain.local. Для этого создайте на серверах DNS, выполняющих разрешение для этого домена (как я понимаю, это у Вас КД этого же домена) пустую зону с именем PDC-DMZ._sites.dc._msdcs.DOMAIN.LOCAL. Тогда попытка поиска КД домена domain.local в сайте PDC-DMZ будет неудачной, и локатор перейдет к поиску доменов в других сайтах (которые уже будут не RODC).

    PS Имеет смысл рассмотреть возможность отказа от RODC вообще: если не используются возможности, требующие нахождения серверов в одном домене (например, аутентификация по смарт-картам или ограниченное делегирование Kerberos), то имеет смысл все серверы в DMZ перевести в домен extranet.ad и использовать аутентификацию по учетным записям из domain.local через отношения доверия.


    Слава России!

    • Помечено в качестве ответа Dmitry Zobnin 19 декабря 2012 г. 10:25
    15 декабря 2012 г. 19:34
  • Запустил на ext-dc-03.extranet.ad командную строку от имени dzobnin-adm@domain.local

    C:\Windows\system32>net use \\172.16.22.12
    The command completed successfully.


    MCITP:SA, MCTS:Exchange Configuring


    • Изменено Dmitry Zobnin 18 декабря 2012 г. 10:36
    18 декабря 2012 г. 10:36
  • 2. По идее, RODC, получив по NTLM запрос на аутентификацию по имени участника безопасности (учетной записи доверяющего домена), пароль для которого у него отсутствует, должен перенаправить запрос на аутентификацию на RWDC, опять-таки, по NTLM. Непонятно, происходит ли это у Вас. Проверить можно, промониторив пакет одновременно на RODC.

    На RODC мониторить пакеты, уходящие на RWDC не получится, у нас между ними IPSec. Похоже, что вместо "проксирования" kerberos через RODC, клиент просто переключается на RWDC. Я мельком видел сегодня утром что-то такое для еще одного траста ext-tst.ad. Сейчас снова запустил монитор чтобы проверить это.

    UPD. Так и есть. Для второго траста ext-tst.ad

    DC-TST-EXT2 -> dc-12-ro.domain.local 14:49:51 18.12.2012 NRPC: NetrServerAuthenticate3 Request, PrimaryName = \\DC-12-RO.DOMAIN.LOCAL, AccountName = ext-tst.ad., ComputerName = DC-TST-EXT2, SecureChannelType = TrustedDnsDomainSecureChannel , NegotiateFlags = 0x613FFFFF

    dc-12-ro.domain.local -> DC-TST-EXT2 14:49:51 18.12.2012 NRPC: NetrServerAuthenticate3 Response, NegotiateFlags = 0x613FFFFF, AccountRid = 0, ReturnValue = 0xC000018B - STATUS_NO_TRUST_SAM_ACCOUNT

    А через секунду:

    DC-TST-EXT2  -> dc-03.domain.local 14:49:52 18.12.2012 NRPC: NetrServerAuthenticate3 Request, PrimaryName = \\DC-03.DOMAIN.LOCAL, AccountName = ext-tst.ad., ComputerName = DC-TST-EXT2, SecureChannelType = TrustedDnsDomainSecureChannel , NegotiateFlags = 0x613FFFFF

    dc-03.domain.local -> DC-TST-EXT2 14:49:52 18.12.2012 NRPC: NetrServerAuthenticate3 Response, NegotiateFlags = 0x613FFFFF, AccountRid = 23620, ReturnValue = Success

    Между DC-12-RO.DOMAIN.LOCAL и другими RWDC домена DOMAIN.LOCAL в промежуток 14:49:51-14:50:xx никакой сетевой активности не было. То есть RODC даже не пытался перенаправить запрос на какой-то другой DC.

    Это выглядит как "Нагадил в логе и переключился на другой контроллер".


    MCITP:SA, MCTS:Exchange Configuring

    • Изменено Dmitry Zobnin 18 декабря 2012 г. 13:01
    18 декабря 2012 г. 10:51
  • На DNS-серверах домена ext-tst.ad (он непродуктивный, поэтому экспериментирую на нем) добавил пустую зону PDC-DMZ._sites.dc._msdcs.DOMAIN.LOCAL.

    Ждем результата...


    MCITP:SA, MCTS:Exchange Configuring

    18 декабря 2012 г. 13:20
  • Принято решение убрать RODC из DMZ.

    MCITP:SA, MCTS:Exchange Configuring

    • Помечено в качестве ответа Dmitry Zobnin 19 декабря 2012 г. 10:25
    19 декабря 2012 г. 10:24