none
Проектирование многодоменного леса - Domain Services RRS feed

  • Вопрос

  • Доброго времени суток! 

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

    Коротко: Существует 1 лес: 1 root domain (company.com) и множество поддоменнов (XXX.company.com) для филиалов, каждый в своем сайте, разделенных территориально. Структура сети такая, что нет связи между филиалами, только с головным HQ офисом, т.е. root domain. Получается, что-то наподобие звезды. Связь мостов между сайтами отключена, и все подключения создаются вручную между HQ и BRANCH.

    В данный момент осуществляется переход к однодоменной структуре с множеством сайтов. Т.е. вместо отдельного домена для филиала, будут установлены контроллеры из Root Domain в новом сайте. Все как выше, только в одном домене и множеством сайтов. С этим сложностей нет.

    Странность: Создается новый сайт, настраиваю новые контроллеры виртуальные Win 2008 R2 SP1 ENG. Проверяю работоспособность - все отлично, логи чисты, dcdiag /q чист, контроллеры работают отлично.

    Но периодически, раз в 2-3 дня появляются следующие ошибки для каждого филиала в лесу (к которым он и не должен иметь доступа!):

                NETLOGON 5719

    This computer was not able to set up a secure session with a domain controller in domain XXX.COMANY.COM due to  the       following: There are currently no logon servers available to service the logon request. 

    Вопрос: Что сделано не верно и по какой причине может возникать подобная ошибка?

    17 июля 2014 г. 6:14

Ответы

  • Но периодически, 2-3 дня, обращения регистрируются разом, с ошибкой на 19 доменов и тишина, без каких либо жалоб со стороны пользователей. Как будто есть некий процесс с расписанием, который выполняет проверку в заданный промежуток времени.

    

    Ну, процесс такой есть - он как раз NetLogon называется (точнее, это служба в разделяемом процессе).

    Чтобы иметь возможность аутентификации пользователей из доверенных доменов по NTLM, он пытается устанавливать защищенный канал с контроллерами доверенных доменов. Не происходит такого только на RODC.

    А поскольку пользователей, для которых эта аутентификация реально нужна, у вас нет, то, в общем, можете смело игнорировать эту ошибку.


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

    • Помечено в качестве ответа Nikolay_KZ 18 июля 2014 г. 10:37
    18 июля 2014 г. 10:12
  • В данном случае транзитивные отношения к делу не относятся: у домена в корне дерева (я правильно понимаю, что речь идет об ошибках на КД именно этого, корневого домена) отношения доверия с дочерними доменами на следующем уровне дерева (как я понимаю, это - ваша ситуация) самые что ни на есть непосредственные (можете посмотреть в AD Domains and Trusts).

    Что касается доверия между двумя разными ветками в дереве то там (при отсутствии сокращенных доверий) путь доверия действительно идет через корневой домен. Более того, если используется аутентификация NTLM, то пользователь из одного из таких доменов может авторизоваться на площадке другого домена (при условии, что путь пойдет через КД корневого домена в цетральном сайте) - контроллеры доверяющих и доверенных доменов будут обращаться друг к другу по цепочке, через защищенные каналы друг с другом. А вот аутентификация по Kerberos работать не будет - там для получения билета происходит попытка обращения к КД соответсвующего домена напрямую.


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

    • Помечено в качестве ответа Nikolay_KZ 19 июля 2014 г. 12:26
    18 июля 2014 г. 15:22

Все ответы

  • имхо первично

    NTP & check DNS

    17 июля 2014 г. 7:20
  • NTP архитектура в порядке, синхронизация успешная и постоянная, ошибок в логах нет. Время сконфигурировано везде, даже на менеджмент устройствах (IBM AMM, Switch, ESXI и естественно контроллеры домена).

    DNS так же работает без ошибок, настроены на синхронизацию между HQ и BRANCH. Зона одна "Companty.com"

    17 июля 2014 г. 7:35
  • (к которым он и не должен иметь доступа!):

    поясните.

    ===

    а таки всетаки имхо днс.

    соа как резолвится?

    17 июля 2014 г. 8:24
  • Смотрите:

    Вот 2 филиала и root домен, разделенные географически.

    ( Y.COMP.COM - VOLGOGRAD ) <- BRANCH01 SITE

                \/

    ( COMP.COM - PITER )  <- HQ SITE

                /\

    ( Z.COMP.COM - MOSKOW ) <- BRANCH02 SITE

    Связи сайтов по IP:

                HQ - BRANCH01

                HQ - BRANCH02

    Физически Y.COMP.COM и Z.COMP.COM не связаны и не должны друг друга искать.

    Пространство DNS у них всех одно. И каждый сервер DNS имеет записи всех остальных доменов и если не знает направляет запрос выше к HQ DNS серверам.

    17 июля 2014 г. 9:41
  • Если хост из домена z.comp.com обращается к ресурсу resorce.y.comp.com, то контроллер домена z.comp.com будет обращаться к контроллеру домена y.comp.com.

    Возможно, что у вас что-то реально обращается по иным филиалам.

    Самый железобетонный способ отследить такую активность - просто мониторьте траффик на DC с ошибками.

     

    Microsoft Certified Doing Nothing Expert

    17 июля 2014 г. 9:55
  • Зона одна "Companty.com"

    ? ммм.

    т.е. днс ххх.company.com держит и реплицирует так же и ууу.company.com?

    17 июля 2014 г. 10:40
  • Дело в том, что если бы ошибки возникали периодически на определенные домены я бы так и подумал. (Хотя это не возможно, так как все сервисы сфокусированы в HQ и в филиалах нет практически ничего). К тому же контроллеры, которые рассматриваются в этой теме, созданы в новой подсети, где еще нет клиентов. В новом сайте и подсети только 2 новых контроллера.

    Но периодически, 2-3 дня, обращения регистрируются разом, с ошибкой на 19 доменов и тишина, без каких либо жалоб со стороны пользователей. Как будто есть некий процесс с расписанием, который выполняет проверку в заданный промежуток времени.

    



    • Изменено Nikolay_KZ 17 июля 2014 г. 11:12
    17 июля 2014 г. 11:11
  • Zone Replication Scope как настроен?
    17 июля 2014 г. 12:16
  • Не очень красиво сделано, но в свое оправдание могу сказать, что это не моя работа ))

    Одна прямая зона для всех "COMPANY.COM" с репликацией на все контроллеры с DNS в лесу, даже для поддоменов. Все контроллеры доменов указаны как серверы имен.

    Обратные зоны я настраиваю для каждого филиала свои с включенным устареванием. Обычно это маска /16 и все эти подсети и являются адресным пространством филиала по архитектуре.

    Как то так.


    18 июля 2014 г. 3:28
  • Но периодически, 2-3 дня, обращения регистрируются разом, с ошибкой на 19 доменов и тишина, без каких либо жалоб со стороны пользователей. Как будто есть некий процесс с расписанием, который выполняет проверку в заданный промежуток времени.

    

    Ну, процесс такой есть - он как раз NetLogon называется (точнее, это служба в разделяемом процессе).

    Чтобы иметь возможность аутентификации пользователей из доверенных доменов по NTLM, он пытается устанавливать защищенный канал с контроллерами доверенных доменов. Не происходит такого только на RODC.

    А поскольку пользователей, для которых эта аутентификация реально нужна, у вас нет, то, в общем, можете смело игнорировать эту ошибку.


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

    • Помечено в качестве ответа Nikolay_KZ 18 июля 2014 г. 10:37
    18 июля 2014 г. 10:12
  • Спасибо за ответ. Поверю вам на слово.

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

    18 июля 2014 г. 10:36
  • В данном случае транзитивные отношения к делу не относятся: у домена в корне дерева (я правильно понимаю, что речь идет об ошибках на КД именно этого, корневого домена) отношения доверия с дочерними доменами на следующем уровне дерева (как я понимаю, это - ваша ситуация) самые что ни на есть непосредственные (можете посмотреть в AD Domains and Trusts).

    Что касается доверия между двумя разными ветками в дереве то там (при отсутствии сокращенных доверий) путь доверия действительно идет через корневой домен. Более того, если используется аутентификация NTLM, то пользователь из одного из таких доменов может авторизоваться на площадке другого домена (при условии, что путь пойдет через КД корневого домена в цетральном сайте) - контроллеры доверяющих и доверенных доменов будут обращаться друг к другу по цепочке, через защищенные каналы друг с другом. А вот аутентификация по Kerberos работать не будет - там для получения билета происходит попытка обращения к КД соответсвующего домена напрямую.


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

    • Помечено в качестве ответа Nikolay_KZ 19 июля 2014 г. 12:26
    18 июля 2014 г. 15:22
  • Да я так и думал. Получается, что ошибки исчезнут тогда, когда все дочерние домены будут удалены.

    Спасибо, все предельно ясно.

    19 июля 2014 г. 12:28