No Image

Репликация active directory windows server 2012

642 просмотров
10 марта 2020

Обеспечение корректной репликации в лесу Active Directory – это одна из главных задач администратора AD. В этой статье попытаемся понять базовые принципы репликации базы Active Directory и методики диагностики неисправности. Стоит отметить, что репликации — один из основополагающих принципов построения современной корпоративной сети на базе AD, так, например, мы уже говорили о репликации групповых политик в домене AD и репликации зон DNS.

Для мониторинга репликации Active Directory в корпоративной среде Microsoft рекомендует использовать продукт SCOM (либо другие продукты мониторинга с похожим функционалом). Кроме того, для мониторинга репликации AD можно использовать утилиту repadmin (repadmin /showrepl * /csv) совместно с самописными скриптами анализа вывода этой утилиты. Типичные проблемы, связанные с ошибками репликации Active Directory, — ситуации, когда объекты не появляются в одном или нескольких сайтах (например, только что созданный пользователь, группа или другой объект AD не доступны на контроллерах домена в других сайтах).

Хорошая отправная точка для поиска неисправности в механизме репликации Active Directory – анализ журнала «Directory Services» на контроллерах домена. Конкретные действия будут зависеть от того, какие ошибки будут обнаружены в журнале, однако для разрешения проблем нужно достаточно четко понимать процессы репликации Active Directory.

Одним из базовых элементов управлением трафиком репликации между контроллерами домена являются сайты Active Directory. Сайты связаны между собой особыми связями, называемыми «site link», которые определяют стоимость маршрутизации данных AD (элементы леса, домена, папка SYSVOL и т.д.) между различными сайтами. Расчет алгоритма управления и маршрутизации трафика репликации в лесу ведется службой KCC.

KCC определяет партнеров по репликации для всех контроллеров домена в лесу. Для межсайтовой репликации KCC автоматически выбирает специальные сервера-плацдармы (bridgehead server), помимо этого, администратор домена может вручную указать контролеры домена, которые будут выполнять роль сервера-плацдарма для того или иного сайта, именно эти сервера и управляют межсайтовой репликацией. Сайты и сервера bridgehead нужны для того, чтобы удобно управлять трафиком репликации Active Directory, и чтобы уменьшить объем передаваемого трафика по сети.

Межсайтовую топологию в лесу можно проанализировать при помощи команды:

данная команда отобразит список сайтов в лесу Active Directory. Для каждого из сайтов указаны 3 значения: стоимость репликации между двумя сайтами, интервал репликации в минутах, а также дополнительные настроенные параметры межсайтовой связи. Вывод этой команды может выглядеть так:

В вышеприведённом логе видно, что в домене winitpro.ru существует 3 сайта, которые называется соответственно Site(0), Site(1) иSite(2). Каждый из сайтов имеет 3 набора репликационной информации, по одной для каждого сайта в лесу. Например, настроена связь между Sites(2) (LAB-Site3) и Site(0) (LAB-Site1), параметры этой связи — 10:30:0, что означает: 10 – стоимость репликации, и интервал репликации 30 минут. Также обратите внимание, что для сайта Site(2) задан сервер-плацдарм (bridgehead) – это контроллер домена с именем testlabdc2.

Контроллеры домена, партнеры по репликации – могут быть идентифицированы при помощи графического Gui или при помощи утилит командной строки. Откройте консоль MMC «Active Directory Sites and Services», разверните узел Sites, в нем найдите интересующий ваш сайт. В этом узле будут содержатся контроллеры домена, относящиеся к этому сайту. Развернув контроллер домена и выбрав пункт NTDS Settings, вы увидите всех партнеров по репликации данного контроллера домена.

В командной строке при помощи команды nslookup можно получить список контроллеров домена, относящихся к нашему сайту (естественно для этого необходимо, чтобы все DC имели корректные записи SRV). Формат команды такой:

на выходе получаем примерно следующее:

Чтобы для определенного контролера домена отобразить всех партнеров по репликации, с датой и временем последней репликации, воспользуйтесь командой:

Стоит отметить, что служба DNS – это важный компонент службы репликации Active Directory. Контроллеры домена регистрируют свои SRV записи в DNS. Каждый контроллер домена в лесу регистрирует записи CNAME вида dsaGuid._msdcs.forestName, где dsaGuid –GUID видимый у объекта в пункте NTDS Settings в консоли «AD Sites and Services». Если в журнале Directory Services есть ошибки, связанные со службой DNS, для проверки корректных записей типа CNAME и A для контроллера домена.

Если будут ошибки, перезапустите службу Netlogon, в результате чего произойдет перерегистрация отсутствующих dns записей. Если dcdiag все также будет выдавать ошибки, проверьте конфигурацию службы DNS и корректность DNS настроек на DC. Для более детального знакомства с темой тестирования служб dns, рекомендую обратиться к статье Диагностика проблем с поиском контроллера домена.

Команда repadmin имеет специальный параметр /replsummary, который позволяет быстро проверить состояние репликации на конкретном контроллере домена (указывается его имя) или на всех контроллерах (опция wildcard).

В том случае, если ошибки репликации отсутствуют, в выводе этой команды будет видно, что ошибок – 0.:

В том случае, если ошибки все-таки будут, при помощи утилиты Repadmin можно получить более полную информацию. Каждый контроллер домена имеет собственный уникальный USN (Update Sequence Number), который инкрементируется каждый раз при успешном изменении обновлении объекта Active Directory. При инициализации репликации, партнеру передается USN, который сравнивается с USN, полученным в результате последней успешной репликации с данным партнером, тем самым определяя сколько изменений произошло в базе AD со времени последней репликации.

При помощи ключа /showutdvec, можно получить список текущих значений USN, хранящихся на указанном DC.

Запустив эту команду на контроллере домена, на котором наблюдаются проблемы с репликацией, можно понять насколько различаются базы AD, просто сравнив значения USN.

Читайте также:  Taobao как заказать в россию

Тестирование репликации Active Directory при помощи утилиты repadmin можно осуществить несколькими способами:

  • replmon /replicate (позволяет запустить репликацию определенного раздела на указанный контроллер домена)
  • replmon /replsingleobj (репликация конкретного объекта между двумя DC)
  • replmon /syncall (синхронизация указанного контроллера домена со всем партнерами по репликации)

При наличии проблем с механизмом репликации Active Directory, нужно знать и уметь пользоваться утилитами repadmin, nslookup, dcdiag, крайне полезен при анализе журнал событий Directory Services. В особо сложный и нестандартных ситуациях может помочь база знаний Microsoft KB, в которой описаны типовые проблемы и методики их решения. Поиск по базе KB обычно осуществляется по идентификаторам ошибок (Event ID), полученным из указанного журнала..

Осознание того, что я попал в импортозамес пришло не сразу. Только когда из вышестоящей организации свежие поставки ПК стали стабильно приезжать с дистрибутивом «Альт Линукс» на борту, я заподозрил неладное.

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

  • DC1 — Windows Server 2012R2
  • DC2 — Альт Сервер 8.2
  • File Server — Windows Server 2012R2
  • PC1 — Windows 7
  • PC2 — Альт Рабочая станция 8.2

Задачи стенда:

Реализация:

    Установка и ввод нового контроллера

С установкой MS Windows 2012R2 всё просто и более менее понятно. В интернете есть 1001 мануал по развертыванию домена на Windows как с помощью GUI так и средствами Powershell, поэтому повторять лишний раз не буду, оставлю только ссылку на офф. документацию, для любопытствующих и тех кто захочет освежить память.

Однако один важный момент в данном пункте всё таки есть. На сегодняшний день Samba не умеет работать со схемами каталога выше 2008R2.

DsAddEntry failed with status WERR_ACCESS_DENIED info (8567, ‘WERR_DS_INCOMPATIBLE_VERSION’)

Проблема в том, что Windows 2012 и 2012R2 используют инструменты WMI для работы с доменами и лесами, стабильная поддержка которых анонсирована только к версии Samba 4.11, которая должна выйти до конца этого года.
Из этого следует, что единственным вариантом для введения самбы в домен AD, развернутый на 2012R2 сервере, является понижение схемы с 69 до 47. Разумеется на рабочей инфраструктуре без веских причин этого делать не надо, но у нас тут тестовый стенд, так что почему бы собственно и нет.

Ставим Альт Сервер 8.2. Во время установки выбираем профиль «Сервер Samba-DC (контроллер AD)». На развернутом сервере производим полное обновление системы, и устанавливаем пакет task-samba-dc, который потянет за собой всё необходимое

Далее переходим к настройке Kerberos и получению тикета. Открываем файл krb5.conf, переходим в раздел [libdefaults], и приводим к следующему виду:

Проверяем список полученых тикетов Kerberos

Теперь удаляем или переименовываем существующий конфиг самбы.

И наконец вводим в домен AD вторым контроллером:

В оснастке ADUC должна появиться запись о новом DC в домене TEST.LOCAL, а в диспетчере DNS — новая А запись, соответствующая DC2.
Репликация между контроллерами

Для начала проверим работу службы репликации каталогов (DRS)

Предупреждение «No NC replicated for Connection!» можно смело игнорировать. Оно появляется из за того, что при регистрации нового DC самба неверно устанавливает некоторые флаги репликации.

Так же неплохо будет проверить репликацию LDAP.

Указанная выше команда сравнит значения атрибутов объектов всего каталога на DC1 и DC2.

В ряде случаев атрибуты объектов на разных контроллерах могут отличаться, и вывод команды даст об этом знать. Но далеко не во всех случаях это будет признаком проблемы с репликацией.

Следующим этапом необходимо вручную настроить стабильную репликацию каталога SysVol.
Дело в том, что самба пока не поддерживает DFS-R, впрочем как не поддерживала более раннюю FRS. Поэтому для репликации между DC Samba и Windows единственным на сегодняшний день рабочим решением является односторонняя репликация средствами утилиты Robocopy из комплекта Windows Server 2003 Resource Kit Tools.

Разработчики самбы, во избежание проблем с совместимостью, рекомендуют сначала установить комплект утилит на обычную рабочую станцию, и после этого скопировать Robocopy на контроллер в папку «C:Program Files (x86)Windows Resource KitsTools»

После установки, в планировщике задач на контроллере с Windows создаём задание на выполнение репликации со следующими параметрами:

— Выполнять для всех пользователей
— Триггер на выполнение Ежедневно каждые 5 минут в течение дня
— В действиях прописываем путь к утилите robocopy, в качестве аргументов указываем:

В конкретном случае копируем содержимое каталога SysVol с DC1 на DC2.

Переносимые папки пользователей с помощью конфигурации pam_mount

Опытным путём я нащупал два жизнеспособных варианта решения этой задачи с его помощью.

    Полное монтирование папки с профилем из сети в раздел /home

Простой вариант. Отлично отрабатывает, если названия папок Мои документы, Загрузки и Рабочий стол совпадают в обеих операционных системах. Подразумевается, что ПК на Linux уже введён в домен и пользователи логинятся под своими доменными учётными записями, используя в качестве механизма аутентификации и авторизации sssd.

  • u — путь монтирования в домашнюю папку пользователя

Логин пользователя передается в макропеременную "%(USER)", используемую pam_mount, для подключения нашего сетевого ресурса, в том виде, в котором он введен в дисплейном менеджере. Поэтому важно, чтобы в ДМ логин вводился без явного указания доменного имени.

Читайте также:  Время зарядки iphone 5

В sssd.conf это решается комментированием, либо выставлением значения False в опцию use_fully_qualified_names, которая включает режим полных имён (включая домен) для пользователей и групп.

Второй способ менее прямолинейный и топорный, и на мой взгляд более удобный и предпочтительный. Отличие от первого только в конфигурации pam_mount

То есть просто отдельно монтируем каждую нашу папку в соответствующий ей каталог

Выводы

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

В целом у меня остались довольно приятные впечатления от работы с этим продуктом, даже несмотря на все нюансы, с которыми пришлось столкнуться как в статье, так и «за кулисами».

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

В этой статьe мы разобрали как развернуть контроллер домена на базе Windows Server 2012 R2. Теперь наша задача развернуть дополнительный контроллер домена, который будет подстраховкой в случае если основной выйдет из строя.

Итак мы имеем в работе:

  • Основной контроллер домена Windows Server 2012 R2 (DC1, jakonda.local, 192.168.0.2) с развернутыми службами AD DS, DNS, DHCP.
  • Развернуть дополнительный контроллер домена на базе Windows Server 2012 R2, выполнить предварительную настройку системы.
  • Поднять на дополнительном контроллере роли AD DS, DNS, DHCP.
  • Настроить репликацию данных.
  • Выполнить настройку работы DHCP сервера совместно с основным контроллером домена.

Проделываться все действия будут на виртуальной машине.

Установка Windows Server 2012 R2 и подготовительная настройка системы

Устанавливаем Windows Server 2012 R2 Standart with GUI. После установки системы обязательно:

  • Устанавливаем все имеющиеся обновления на текущий момент.
  • Выставляем корректную временную зону (+03:00 Moscow, St. Petersburg, Volgograd).
  • Изменяем имя системы на (прим. DC2).
  • Указываем в системе статический IP-адрес (в моем случае это будет 192.168.0.3), в качестве предпочитаемого DNS сервера указываем адрес DNS сервера на основном контроллере домена DC1 (192.168.0.2) и в качестве альтернативного DNS сервера указываем адрес который мы присвоили на текущем сервере DC2 (192.168.0.3).

  • Вводим систему в имеющийся домен jakonda.local.

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

Поднимаем роли AD DS + DNS + DHCP на дополнительном контроллере домена

Все действия по развертыванию и настройке ролей на дополнительном контроллере домена, мы будем производить с основного контроллера домена. Поэтому заходим в моем случае на основной контроллер домена DC1 (192.168.0.2) и добавим наш дополнительный сервер в основной, Manage — Add Servers.

Переходим во вкладку DNS, в поле Search вбиваем IP-адрес нашего дополнительного сервера (в моем случае 192.168.0.3), сервер должен появится в списке найденных, выделяем его и нажимаем кнопку переместить (>). Нажимаем ОК.

После добавления сервера, если перейти в All Servers, то мы увидим что у нас там теперь два сервера. Теперь можно из основного сервера добавлять, настраивать роли на другом сервере.

Добавляем новую роль на дополнительном сервере DC2. Переходим Server ManagerManageAdd Roles and Features.

Выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов).Нажимаем Next.

Выбираем Select a server from the server pool и выбираем сервер из списка, т.к. мы настраиваем дополнительный сервер, то выделяем dc2.jakonda.local и нажимаем Next.

Далее все как и в статье по развертыванию контроллера домена:

  • Отмечаем галочкой роль Active Directory Domain Services, в подтверждающем запросе добавления роли и компонентов, необходимых для установки AD нажимаем Add Features.
  • В выборе установки дополнительных компонентов, ничего не выбираем.
  • На завершающих этапах установки нажимаем Next и Install.

По завершении установки роли AD DS в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Promote this server to a domain controller (Повысить этот сервер до контроллера домена). Запустится мастер конфигурирования AD DS для сервера DC2.

Т.к. мы разворачиваем дополнительный контроллер домена, то нужно добавить его в уже существующий домен. Выбираем Add a domain controller to an existing domain. Автоматические подставится название текущего домена (jakonda.local) и какую доменную учетную запись использовать при выполнении данной операции. Нажимаем Next.

Проверяем установлены ли галочки (Domain Name System (DNS) Server, Global Catalog (GC)), в пункте Site name оставляем значение Default-First-Site-Name и задаем пароль для восстановления служб каталогов. Нажимаем Next.

Предупреждение о том что не может быть создано делегирование разворачиваемого DNS сервера, игнорируем. Нажимаем Next.

В дополнительных опциях в пункте Replicate from (Репликация из) выбираем основной контроллер домена DC1.jakonda.local. Это мы указываем дополнительному контроллеру домена откуда производить репликацию даннных AD, DNS. Нажимаем Next.

Пути к каталогам оставляем по-умолчанию, далее просматриваем сводную информацию по конфигурации AD DS. Нажимаем Next.

Если проверка выполнена успешно, то нажимаем Install.

После того пройдет установка, если зайти на DC2, то увидим что роли AD, DNS подняты, произведена репликация из DC1.

Если необходимо посмотреть, изменить параметры репликации, то заходим Server ManagerToolsActive Directory Sites and Services.

Читайте также:  Почему компьютер лагает и как это исправить

Так же можно с помощью командной строки принудительно запустить процесс репликации, с помощью утилиты repadmin:

Так же с помощью данной утилиты можно посмотреть результат последних репликаций:

Теперь перейдем к развертыванию DHCP на дополнительном сервере DC2 и его настройке в совместном режиме работы с DHCP на основном сервере DC1.

Поднимаем на дополнительном сервере службу DHCP и настраиваем ее режим работы

Устанавливаем роль DHCP Server аналогично как описано в этой статье только в качестве установки роли выбираем дополнительный сервер.

  • Запускаем Server ManagerManageAdd Roles and Features.
  • Выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов).
  • Выбираем Select a server from the server pool и выбираем сервер dc2.jakonda.local.
  • Отмечаем галочкой роль DHPC Server, в подтверждающем запросе добавления роли и компонентов, необходимых для установки DHCP Server нажимаем Add Features.
  • В выборе установки дополнительных компонентов, ничего не выбираем.
  • На завершающих этапах установки нажимаем Install.

После установки Роли, в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Complete DHCP configuration (Завершить конфигурацию DHCP). Запустится мастер после установочной конфигурации DHCP. В мастере выполняем следующие действия:

  • На информационной странице нажимаем Next.
  • Нажимаем Commit что бы завершить процесс авторизации в Active Directory.
  • Если процесс создания групп безопасности и авторизация в AD успешен, то получим вывод Done.
  • Нажимаем Close.

На основном контроллере домена DC1, настроен DHCP-сервер, нужно решить как будет работать DHCP-сервер на дополнительном контроллере домена DC2. Пути решения могут быть такие:

  • Split Scope (Использование разделенных областей) — возможность распределения адресного пула между двумя серверами. Например DC1 назначает 80% адресов, а DC2 назначает 20%. В случае если DC1 не доступен, то клиент сможет всегда получить адрес с DC2.
  • Failover (Отказоустойчивый) — В случае если DC1 отказывает, то DC2 принимает на себя нагрузку. Данный механизм работает в двух режимах:
  • Load Balance Mode (Балансировка нагрузки) — Работа данного режима предполагает работу двух серверов DC1 и DC2 одновременно предоставляющих IP-адреса клиентам. Запросы можно распределить в процентном отношении между серверами, по-умолчанию 50 на 50.
  • Hot Standby Mode (Режим горячей замены) — Работа данного режима предполагает что основной сервер DC1 (активный), который отвечает за выдачу IP-адресов клиентам, а дополнительный сервер DC2 (пассивный) принимает эту роль на себя в случае, отказа основного сервера.

Настройка Split Scope (использование разделенных областей). Открываем оснастку DHCP на основном сервере DC1: Server ManagerToolsDHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Advanced…Split Scope.

Описание режима Split-Scope. Нажимаем Next.

Указание дополнительного DHCP сервера, в моем случае DC2. Нажимаем Add Server.

Отмечаем пункт This authorized DHCP server и выбираем дополнительный сервер (dc2.jakonda.local). Нажимаем ОК и следом Next.

Задаем процентное соотношение распределения адресного пула между двумя серверами DC1 и DC2. Ниже видно с какого по какой адрес будет выдаваться основным и дополнительным сервером. Нажимаем Next.

Указываем задержку ответа серверов в мс. Укажем для дополнительного сервера DC2 задержку в 10 мс, выдавать все адреса будет основной сервер DC1, а дополнительный только при недоступности основного или заполнении его пула адресов.

Вывод сводной информации по настройке. Нажимаем Finish.

Если все заданные нами параметры успешно установлены, то напротив каждого пункта будет Successful. Нажимаем Close.

Открываем оснастку DHCP на дополнительном сервере DC2: Server ManagerToolsDHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Activate.

Теперь при отказе или заполнении выделенного на основной сервер DC1 пула адресов, его подстрахует дополнительный сервер DC2.

Настройка Failover (Отказоустойчивый). Открываем оснастку DHCP на основном сервере DC1: Server ManagerToolsDHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Configure Failover…

Выбираем пул к которому хотим применить Failover. Нажимаем Next.

В поле Partner Server выберем второй сервер (dc2.jakonda.local). Пункт Reuse existing failover relationships configured with this server (if any exist) (Использовать существующие отношения отработки отказа с этим сервером (если доступно)) будет активно, если ранее уже создавалось отказоустойчивый профиль, то мастер предложит воспользоваться существующим профилем. Нажимаем Next.

Задание отказоустойчивых параметров:

  • Relationship Name (Название конфигурации) — задается уникальное название создаваемой конфигурации.
  • Maximum Client Lead Time (Максимальное время упреждения клиента) — максимальное время аренды IP-адреса выдаваемого доступным сервером.
  • Mode (Режим работы):
  • Load Balance (балансировка нагрузки) — процентное отношение нагрузки между серверами. По-умолчанию 50 на 50.
  • Hot Standby (горячей замены) — выбираем состояние работы дополнительного сервера: Активный / Резервный и задаем количество IP-адресов в процентом отношении, для резервирования дополнительного сервера.
  • State Switchover Interval (Переключение режима по таймауту) — интервал автоматического переключения режима в режим отказа дополнительного сервера, по истечении заданного времени в минутах.
  • Enable Message Authentication (Включение проверки подлинности сообщений) — Для настройки проверки подлинности сообщений между серверами.
  • Shared Secret (пароль) — Задается пароль для аутентификации серверов между собой.

Задаем нужные нам параметры. Нажимаем Next.

Вывод сводной информации по указанной конфигурации. Нажимаем Finish.

Если все заданные нами параметры успешно установлены, то напротив каждого пункта будет Successful. Нажимаем Close.

В рамках текущей задачи, мы настроили работу дополнительного контроллера домена DC2, который в случае отказа основного контроллера домена DC1 подстрахует его.

Комментировать
642 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock
detector