Сайты Active Directory - Дизайн и возможности подключения
Короткий вопрос ; все ли клиенты должны иметь возможность общаться со всеми контроллерами домена в многосайтовом домене?
Предпосылки: В настоящее время я пытаюсь сделать существующий домен многосайтовым. Я много читал документацию Microsoft, но некоторые требования и технические особенности остаются для меня неясными. Все - Windows Server 2012 R2.
Чтобы немного объяснить, что у нас есть, у нас есть существующий сайт с двумя контроллерами домена в отдельной сети управления. Затем у нас есть примерно 100 клиентских серверов в отдельных клиентских сетях, каждый из которых имеет доступ к сети управления, в которой размещены контроллеры домена. Назовем этот домен "int.company.com".
Теперь мы собираемся настроить клиентские серверы во втором месте, на некоторых из этих серверов будут выполняться дубликаты служб с нашего существующего сайта (репликация аварийного восстановления на уровне приложений будет реализовано), и на некоторых из этих серверов будут работать новые службы. Администраторами будет тот же персонал, что и на существующем сайте, это удаленный сайт центра обработки данных, а не сайт с обслуживающим персоналом.
Судя по различным передовым методам проектирования, которые я прочитал, использование одного домена кажется лучшим путем вперед. это один и тот же персонал, работающий с идентичными / похожими службами.
Я установил второй сайт с одним контроллером домена и создал 2 отдельных сайта в AD Sites and Services и назначил правильное управление и клиентские подсети для обоих сайтов . Есть постоянная сеть VPN, правила брандмауэра, позволяющие контроллерам домена общаться друг с другом, и отчеты dcdiag, все в порядке на всех 3 контроллерах домена. На всех 3 контроллерах домена также работают интегрированные DNS-серверы AD.
Однако я испытываю трудности с подключением клиентских серверов на обоих сайтах. В тот момент, когда вы просматриваете "int.company.com", он возвращает IP-адреса всех контроллеров домена на всех сайтах, я понимаю из документации по сайтам и службам, что клиентские серверы всегда будут искать свои локальные контроллеры домена любым способом, но мы также есть различные приложения и сторонние службы, использующие ldap против "int.company.com", который не знает сайта. Текущая сеть VPN типа «сеть-сеть» не направляет трафик для клиентских серверов, а только сеть управления для контроллеров домена.
В идеале мы предполагали, что это будет работать так, чтобы клиентские серверы на сайте A общались только с контроллерами домена на сайте A, а клиентские серверы на сайте B общались только с контроллерами домена на сайте B.
Итак, вернемся к вопрос, все ли клиенты должны иметь возможность разговаривать со всеми контроллерами домена? Или это значит, что мы? Не лучше ли создать отдельный домен с доверительным отношением, чтобы обеспечить большую изоляцию трафика?
Заранее благодарим!
Да, они делают. Если контроллеры домена регистрируют свои записи DNS, все клиенты должны иметь доступ к ним и использовать их.
Если у вас есть контроллеры домена, которые недоступны или расположены на сайте, который вы предпочитаете клиентам на других сайтах не использовать, вы можете настроить контроллеры домена так, чтобы они не регистрировали записи DNS. Это типично для лучевых сайтов в конфигурации узлового и оконечного серверов.
Key: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value: DnsAvoidRegisterRecords
Value type: REG_MULTI_SZ
Value Data:
LdapIpAddress
Ldap
DcByGuid
Kdc
Dc
Rfc1510Kdc
Rfc1510UdpKdc
Rfc1510Kpwd
Rfc1510UdpKpwd
GC
GcIpAddress
GenericGc
Хотя я не не согласен с Грегом, я также не хотел редактировать его ответ своими мыслями по этому поводу.
Прочтите это: https: // blogs. technet.microsoft.com/askds/2011/04/29/sites-sites-everywhere/ - и - https://support.microsoft.com/en-us/help/247811/how-domain -controllers-are-located-in-windows - убедитесь, что вы правильно настраиваете сайты и специфичные для сайта записи DNS.
Ваши поисковые запросы DNS не будут возвращать специфичные для сайта записи DNS, только общие записи, которые Это хорошо. А проверка связи с доменом будет выполнять только циклический перебор этих общих записей.
Если у вас есть записи DNS для конкретного сайта, а сайты и подсети настроены правильно, тогда клиенты должны сначала использовать соответствующие локальные контроллеры домена.
Для ваших приложений, использующих фактический LDAP (я предполагаю, что вы имеете в виду это вместо того, чтобы просто приложение, использующее AD через ОС), тогда вы должны установить первичный и вторичный LDAP / DC для этих приложений, а не использовать общее доменное имя для конфигурации LDAP.
Читая между строк, можно сказать, что здесь есть несколько проблем:
Знают ли клиенты домена сайт? Да. Процесс поиска контроллера домена будет искать контроллер домена на ближайшем к клиенту сайте, предполагая, что все настроено правильно. Однако это не суть вашего вопроса / проблемы.
Знает ли сайт о приложениях / услугах? DFS поддерживает сайт, Exchange Server поддерживает сайт и т. Д., Но у вас есть приложения, которые не поддерживают сайт. При запросе корневого домена ваши приложения получают ответ, содержащий все записи DNS для всех контроллеров домена. Алгоритм выбора адреса назначения, подробно описанный в RFC 6724 (который отменяет RFC 3484), должен работать, чтобы «упорядочить» список так, чтобы запись, ближайшая к клиенту, была выбрана и использовалась клиентом (в частности, с использованием правила 9 адреса назначения Алгоритм выбора). Это длинный способ сказать: когда клиент запрашивает корневой домен и получает ответ с несколькими записями,клиент должен выбрать ближайшую к нему запись. Таким образом, даже при запросе корневого домена ваши приложения должны обмениваться данными с контроллером домена на своем собственном сайте или на следующем ближайшем сайте.
(некоторые из моих ответов цитируются по ссылкам ниже).