none
Лесные доверия RRS feed

  • Вопрос

  • Добрый день, коллеги.

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

    Сам вопрос построения довольно простой, и не раз выполнялся, но только в небольших и средних масштабах.

    А вот как быть если надо построить доверия между лесами с сотнями контроллеров домена в разных айпи-сетях с обеих сторон? Должен ли иметь сетевую доступность каждый контроллер в одном лесу с каждым контроллером в другом?

    Ведь на DNS-запрос о имени домена DNS-сервер ответит всеми айпи-адресами контроллеров. Как-то повлиять на это netmask-ordering'ом или привязкой сетей к сайтам не получится. А как тогда быть? Есть ли в таких довериях механизм на подобии бридж-хэдов в репликации?

    Спасибо.

    8 июня 2016 г. 11:39

Ответы

  • При Kerberos DC доверенного домена не ищет DC доверяющего домена - его ищет сам клиент. А DC доверенного домена просто возвращает ссылку (referral) на домен, куда нужно обратиться (следующий в цепочке доверия по пути к службе, не обязательно тот, в котором находится служба) вместе с билетом TGT для обращения к контроллеру этого домена. Найти контроллер этого домена и получить у него билет службы или ссылку на следующий домен в цепочке вместе с билетом TGT для доступа к нему - это задача клиента. Клиент ищет контроллер домена через записи SRV, обращаясь к своему серверу DNS. Поэтому, создав там нужные зоны, можно ограничить клиент желательным подмножеством контроллеров домена.

    А ещё можно управлять приоритетом контроллеров домена через поле приоритета записей SRV, ссылающихся на каждый из контроллеров домена. Если контроллер домена регистрирует их сам (настройка по умолчанию), это можно делать с помощью политики - групповой или локальной (она точно так же доступна через консоль gpedit.msc и на DC). Но эта настройка - глобальная, она влияет на все клиенты, в любом домене.

    Что касается NTLM, то там контроллер для создания защищённого канала  к доверенному домену ищется заранее, при запуске службы Netlogon, что несколько смягчает проблему. И там точно так же можно управлять поиском контроллеров домена через DNS - на том сервере, с которым работает контроллер доверяющего домена (реально это потребуется лишь для контроллеров корневого домена доверяющего леса).


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



    9 июня 2016 г. 10:35

Все ответы

  • Это - смотря какой протокол аутентификации вы будете использовать.

    Если NTLM, то там обмен данных при аутентификации идёт по цепочке защищённых каналов: от сервера к его контроллеру домена, дальше - по цепочке доверия к корню леса сервера, затем - по межлесному доверию к корню леса клиента, и далее, по цепочке доверия - к контроллеру домена клиента. Защищённые каналы при этом устанавливаются один раз с доступным с данного контроллера домена соответствующим контроллером домена, так что неполная доступность контроллеров одного леса из сетей, обслуживаемых другим лесом, на аутентификацию NTLM сильно не повлияет.

    А вот с Kerberos всё интереснее. Там запросы аутентификации по всей цепочке доверия (TGS-обмен) идут с клиента к контроллерам каждого домена в цепочке. И если большинство контроллеров домена для клиента недоступно по IP, то попытки обращения к недоступным контроллерам до того, как клиент перебором найдёт доступный, могут приводить к существенным задержкам. Одно радует, что при аутентификации Kerberos проходить по цепочке доверия нужно всего один раз за время действия билета (оно 10 часов по умолчанию). Если это создаёт проблемы, то управлять тем, к каким контроллерам домена будет обращаться клиет для каждого домена, можно вручную с помощью создания зон DNS для доменов другого леса в цепочке на серверах DNS, к которым обращаются клиенты: нужные записи - это записи SRV (записи A напрямую для поиска KDC клиенты Windows не используют - только через ссылки в записях SRV) в поддоменах _tcp, _udp и _msdcs домена. Соответственно, зоны нужно создавать для этих поддоменов.

    PS Имеется возможность настраивать маску для Netmask ordering, чтобы она покрывала не один последний октет ("сеть класса С"), как по умолчанию, а любую нужную вам  подсеть IP. Если это поможет решить вашу проблему, я могу рассказать, как это настроить.

     


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


    • Изменено M.V.V. _ 8 июня 2016 г. 12:23
    8 июня 2016 г. 12:20
  • Используются оба протокола, думаю мало у кого всё настолько технологично, везде верно прописаны spn и протокол ntlm вырублен на корню.

    Речь идёт про то как трафик доверия пустить через контроллеры в лесах у которых есть сетевая доступность?

    Или доступность должна быть вида каждый на каждого?

     Если DC в исходном лесу будет искать доступный DC в чужом лесу простым перебором это может быть слишком долго. 

    Если с одной стороны несколько сотен DC и с другой как быть то?

    P.S. про dnscmd и маску знаю, этот механизм не подходит к данной проблеме.

    Спасибо.

  • При Kerberos DC доверенного домена не ищет DC доверяющего домена - его ищет сам клиент. А DC доверенного домена просто возвращает ссылку (referral) на домен, куда нужно обратиться (следующий в цепочке доверия по пути к службе, не обязательно тот, в котором находится служба) вместе с билетом TGT для обращения к контроллеру этого домена. Найти контроллер этого домена и получить у него билет службы или ссылку на следующий домен в цепочке вместе с билетом TGT для доступа к нему - это задача клиента. Клиент ищет контроллер домена через записи SRV, обращаясь к своему серверу DNS. Поэтому, создав там нужные зоны, можно ограничить клиент желательным подмножеством контроллеров домена.

    А ещё можно управлять приоритетом контроллеров домена через поле приоритета записей SRV, ссылающихся на каждый из контроллеров домена. Если контроллер домена регистрирует их сам (настройка по умолчанию), это можно делать с помощью политики - групповой или локальной (она точно так же доступна через консоль gpedit.msc и на DC). Но эта настройка - глобальная, она влияет на все клиенты, в любом домене.

    Что касается NTLM, то там контроллер для создания защищённого канала  к доверенному домену ищется заранее, при запуске службы Netlogon, что несколько смягчает проблему. И там точно так же можно управлять поиском контроллеров домена через DNS - на том сервере, с которым работает контроллер доверяющего домена (реально это потребуется лишь для контроллеров корневого домена доверяющего леса).


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



    9 июня 2016 г. 10:35