Рекомендации по разработке Active Directory для многосетевых серверов

Заказчик поручил мне разработать работающий дизайн Active Directory для сценария со следующими требованиями (упрощенно, на самом деле они намного хуже):

• Существует подсеть для клиентских систем.
• Существует подсеть для серверных систем.
• Две сети не связаны.
• У каждого сервера должно быть две сетевые карты, одна в сети серверов, другая в сети клиентов.
• Трафик между клиентами и серверами должен проходить только по сети клиентов.
• Трафик между серверами должен проходить только по сети серверов.
• Это должно относиться и к контроллерам домена.

Излишне говорить, что это не очень хорошо с тем, как Active Directory использует DNS для поиска контроллеров домена; любой возможный подход приведет к одному из следующих сценариев:

• Контроллеры домена регистрируют свой «клиентский» IP-адрес в домене DNS; клиенты будут общаться с ними по этому адресу, но так же поступают и серверы, и трафик репликации AD.
• Контроллеры домена регистрируют свои IP-адреса на стороне сервера в домене DNS; серверы будут общаться с ними, используя этот адрес, и трафик репликации будет проходить по этой сети, но клиенты не смогут получить к ним доступ.
• Контроллеры домена зарегистрируют оба IP-адреса в домене DNS; Кто-то может догадаться, что любая система сделает, чтобы достичь их.

Конечно, эти требования абсолютно сумасшедшие, и все они не могут быть удовлетворены одновременно, если только не использовать сумасшедшие решения, такие как разделение службы DNS на две сети и заполнение ее записей SRV вручную (argh) или размещение серверов. Контроллеры домена, использующие DNS, и клиенты находят контроллеры домена, используя WINS (двойное число).

Решение, которое я придумал, состоит в том, чтобы иметь два контроллера домена в сети «серверы» и два контроллера домена в «клиенте», определяя два сайта AD и пересекая границу между двумя сетями только с трафиком репликации контроллера домена. Это все еще потребует некоторого искажения DNS, потому что у каждого сервера будут все еще две сетевые карты (кроме двух серверных контроллеров домена и чисто внутренних серверов), но у него есть по крайней мере некоторые шансы на работу.

Любой совет, кроме как бежать как можно быстрее?

Позвольте мне начать с того, что я согласен со многими другими - либо убедить клиента в обратном, либо бежать.

Однако, учитывая ваши перечисленные требования (их много в списке), я могу придумать (и частично протестировать), по крайней мере, основу для этого.

Есть несколько конкретных аспектов, которые необходимо учитывать.

1. Репликация доменных служб Active Directory
2. Процесс локатора DC клиентов / рядовых серверов
3. Разрешение имен и трафик для служб не AD DS

Один и два имеют много общего - в общем, мы находимся на прихоти Microsoft и должны работать в рамках процессов Microsoft DS DS.

Номер три, у нас есть немного места для работы. Мы можем выбрать метки, используемые для доступа к сервисам (файлы, экземпляры базы данных и т. Д.).

Вот что я предлагаю:

Создайте свои контроллеры домена (DC)

• Скорее всего как минимум два.
• Каждый DC будет иметь два сетевых адаптера, по одному в каждой IP-сети / узле AD DS - пока они называются clt и srv.
• Настройте только один сетевой адаптер в каждом контроллере домена прямо сейчас в сети srv.

Правильно настроить сайты и службы AD

• сайт и подсеть srv
• сайт и подсеть clt
• снимите флажок «Соединить все ссылки на сайты» с Сайтов -> Межсайтовый транспорт -> Щелкните правой кнопкой мыши «IP»
• удалите DEFAULTIPSITELINK, если он существует (или если вы переименовали его), чтобы не было настроенных ссылок сайта. Обратите внимание, что это неизвестно для меня - KCC, скорее всего, будет сбрасывать ошибки в журнал событий службы каталогов, говоря, что два сайта (srv и clt) не соединены с разными интервалами. Однако репликация будет продолжаться между двумя контроллерами домена, поскольку они могут связываться друг с другом с помощью IP-адресов на одном сайте.

Настройка дополнительной зоны в AD DS Integrated DNS

• Если вашим доменом AD DS является acme.local , создайте вторую Первичную интегрированную зону AD с включенными динамическими обновлениями под названием clt.acme.local .

Настройте второй NIC на вашем DC

• Эти NIC будут NIC в сети / сайте clt.
• Установите их IP-адреса
• Вот волшебная часть - Свойства адаптера -> Свойства IPv4 -> Дополнительно -> Вкладка DNS -> Установите суффикс DNS для этого соединения на clt.acme.local -> check Зарегистрируйте это соединение ... -> Установите флажок Использовать это соединение DNS-суффикс ... -> ОК, до конца.
• ipconfig / registerdns
• Это зарегистрирует IP-адрес сетевого контроллера clt в зоне clt.acme.local, предоставляя нам метод для контроля того, какой IP / сеть будет использоваться позже.

Настройте сетевые карты рядового сервера

• Сетевые адаптеры рядового сервера на сайте clt должны иметь свой DNS-суффикс и флажки, установленные так же, как и выше.
• Эти настройки могут использоваться со статическим и DHCP, не имеет значения.

Настройка поведения DNS-заглушки на сайтах

• DC -> Настройка DC srv NIC для использования самого себя и других IP-адресов srv DC. Оставьте DC NIC DNS clt пустым (хотя статический IP необходим). (DNS-сервер DC по-прежнему будет прослушивать все IP-адреса по умолчанию).
• Рядовые серверы -> Настройте рядовой сервер srv NIC для использования IP-адресов сайта DC srv. Оставьте рядовой сервер clt NIC DNS пустым (можно использовать статический IP).
• Клиенты / Рабочие станции -> Настройка DNS (либо через DHCP, либо через статический) для использования IP-адресов сетевых контроллеров DC.

Настройте сопоставления / ресурсы соответствующим образом

• Когда серверы общаются друг с другом, обязательно используйте .acme.local -> разрешит IP-адрес сети srv.
• Когда клиенты общаются с серверами, обязательно используйте .clt.acme.local -> разрешит сетевой IP-адрес clt.

О чем я говорю?

• Репликация AD DS все еще будет происходить, поскольку контроллеры домена могут разрешать друг друга и соединяться друг с другом. В зонах acme.local и _msdcs.acme.local будет содержаться только репликация AD DS IP сетевого адаптера DC srv, которая будет выполняться только в сети srv.
• Процесс локатора DC для рядовых серверов и рабочих станций будет функционировать - хотя существует вероятность задержек в различных частях различных процессов AD DS, когда сайт неизвестен, если возвращено несколько IP-адресов DC - они будут испытаны, завершены с ошибкой и перейдут пока один не работает. Эффекты на DFS-N также не были полностью оценены - но все еще будут функционировать.
• Службы не AD DS будут нормально работать, если вы будете использовать вышеупомянутые метки .acme.local и .clt.acme.local, как описано.

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

@Комментарии

@Massimo 1/2 Не путайте несколько сайтов AD DS в зоне acme.local и, следовательно, записи SRV, заполненные контроллерами домена в этих сайтах в зоне acme.local, с необходимостью записей SRV в зоне clt.acme.local. Основной DNS-суффикс клиента (и домен Windows, к которому они присоединены) по-прежнему будет acme.local. Клиентские / рабочие станции имеют только один сетевой адаптер, основной DNS-суффикс которого, вероятно, получен из DHCP и имеет значение acme.local.

Зоне clt.acme.local не нужны записи SRV, поскольку она не будет использоваться в процессе определения локатора домена. Он используется только клиентами / рабочими станциями для подключения к сервисам рядового сервера не AD DS с использованием IP-адресов рядового сервера в сети clt. Связанные с AD DS процессы (локатор DC) будут использовать не зону clt.acme.local, а сайты AD DS (и подсети) в зоне acme.local.

@Massimo 3

Будут записи SRV для сайтов AD DS clt и srv - только то, что они будут существовать в зоне acme.local - см. Примечание выше. Зоне clt.acme.local не требуются записи SRV, связанные с DC.

Клиенты смогут найти штраф DC. Клиентские DNS-серверы указывают на clt IP-адреса DC.

Когда запускается процесс локатора DC на клиенте

• Если клиент знает свой сайт, вопрос DNS будет _ldap._tcp. [Site] ._ sites.dc._msdcs.acme.local SRV. Это вернет обратно специфичные для сайта контроллеры домена, в которых зарегистрированы записи SRV.
• Если клиент не знает своего сайта, вопрос DNS будет _ldap._tcp.dc._msdcs.acme.local SRV. Это вернет все DC. Клиент будет пытаться привязаться к LDAP DC, пока не найдет тот, который отвечает. Когда клиент находит его, он выполняет поиск сайта, чтобы определить сайт клиента, и кэширует сайт в реестре, чтобы будущие экземпляры локатора DC происходили быстрее.

@Massimo 4

Тьфу, хороший улов. На мой взгляд, есть два пути решения этой проблемы.

1. Меньшее влияние (по сравнению с 2 ниже) заключается в создании записи в файле hosts на клиентских компьютерах / рабочих станциях для dc1.acme.local и dc2.acme.local, указывающих на IP-адреса сетевых контроллеров для DC.

или

2. Вручную создайте необходимые записи SRV в файле netlogon.dns на каждом из контроллеров домена. Это, вероятно, будет иметь некоторые последствия для сети сервера. Рядовые серверы могут время от времени связываться с DC в сети clt, если это настроено.

В общем, все это не красиво, но это не обязательно конечная цель. Возможно, клиент просто тестирует ваши технические решения. Положите его на их стол переговоров и скажите им: «Вот, это будет работать, но я беру с вас 4-кратную норму оплаты за настройку и поддержку. Вы можете снизить ее до 1,5-кратной нормы - 0,5-кратного заряда PITA, выполнив [правильное решение]. "

Как отмечалось ранее, моя рекомендация - убедить иначе или бежать. Но это смешное маленькое упражнение. :)

В итоге я выбрал решение для двух сайтов:

• Два DC для сети «серверы», два DC для сети «клиенты».
• Два сайта AD, один для сетей "серверов" и один для клиентов.
• Контроллеры домена в сети «серверы» будут иметь только NIC, установленный на нем (клиенты вообще не будут с ними разговаривать), так что это легко.
• У DC в зоне «клиентов» будет два, но они будут регистрировать в DNS только свои клиентские.
• Серверы будут общаться со своими DC, клиенты будут общаться со своими.

Конечно, это означает включение трафика репликации между двумя сетями; контроллеры домена в сети «клиенты» по- прежнему будут иметь сетевой адаптер в сети «серверы», но, поскольку он не будет зарегистрирован в DNS, контроллеры домена в этой сети будут связываться с ними, используя свои IP-адреса на стороне клиента; так что NIC фактически будет полностью бесполезным, и некоторые порты брандмауэра нужно будет открыть. Единственным другим вариантом будет искажение hostsфайлов DC , но будем надеяться, что этого можно избежать.

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

Спасибо за все советы :-)

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

• Сколько было клиентов?
• Это весь внутренний трафик?
• Каков функциональный уровень доменов?
• Используется ли протокол TLS?

Используя метод KISS, можно было бы создать две VLAN «SVR» и «CLT», включив SSL / TLS и называя их «День» ....