О перерывах в репликации Active Directory

Как и многих специалистов IT, у меня есть своя домашняя лаборатория. Устроена она на обычном компьютере (правда, с 32 ГБ памяти), под VMWare Workstation.  На виртуальных машинах в наше время можно попробовать очень многое. Но после того, как попробовал, я очень редко ликвидирую старые, некогда настроенные стенды — наборы виртуальных машин. Большинство из них спокойно лежат на диске и ждут своего часа (мало ли что понадобится посмотреть для ответа на вопрос на форуме Technet), но это возможно не всегда. Например, если в состав набора входит несколько контроллеров домена в одном лесу, то оставлять их лежать просто так нельзя  — пролежат они больше времени жизни захороненных объектов и откажутся после этого реплицироваться. Поэтому такие виртуалки, на которых находятся контроллеры доменов, я время от времени (раз в один-два месяца) запускаю, чтобы они не забыли друг про друга.

Один из таких наборов содержит у меня три контроллера домена (КД) под управлением Windows 2012 R2 в двух подсетях, соединённых маршрутизатором: два — в одной подсети (и сайте), один — в другой (и тоже в отдельном сайте) . На днях я в очередной раз запустил всё это хозяйство, и решил вдруг проверить — а действительно ли они реплицируются, и тут выяснилось — что нет: по некоторым (неважным для последующего рассказа) причинам один из интерфейсов маршрутизатора отключился от виртуального сегмента LAN, в результате чего связь между подсетями оказалась потеряна. Причём потеряна она была не далеко в этот раз, но (к счастью) до того, как истекло время жизни захороненных объектов — всё это неплохо было видно в выдаче команды repadmin /showrepl.

После восстановления работоспособности маршрутизатора я решил провести реплликацию вручную, через консоль AD Sites & Services. Репликация от одиночного КД прошла нормально, но вот обратная репликация — на одиночный КД с группы из двух КД идти отказалась. Ошибка при этом вылезла странная: «The naming context is in the process of being removed or is not replicated from the specified server». Странная — потому что все контексты (т.е. разделы каталога) давным-давно были реплицированы куда надо и ниоткуда не удалялись.

Более подробный анализ, с помощью команды repadmin /showrepl позволил получить значительно более вменяемое сообщение об ошибке: «The target principal name is incorrect». Может, для непосвященного оно звучит не менее загадочно, но я-то по своему опыту знаю, что одна из причин такой ошибки — неверный пароль сервера , использованный при получении от KDC билета Kerberos для доступа к этому серверу (в нашем случае — к КД-партнёру по репликации). После чего причина возникновения проблемы стала понятной.

Windows устроена так, что компьютеры-члены домена (и контроллеры домена в том числе) по истечении некоторого срока (30 дней по умолчанию) изменяют пароль своей учётной записи в домене. Причём, контроллеры домена делают это, обращаясь не к себе самому, а к другому контроллеру домена — если он, конечно, доступен. При этом компьютер хранит только две копии пароля: текущий и предыдущий — на случай, если для доступа к нему будет использован билет, полученный на основе предыдущего пароля. Так что произошло следующее: два контроллера домена — те, которые находились в одной подсети — успешно поменяли свои пароли — и разЮ и другой, а вот третий КД не смог ни пароль свой поменять, ни получить измененённые в AD для пароли двух других КД. В результате после восстановления контроллеры домена из подсети с двумя КД смогли без проблем обращаться к одиночному КД (т.к. его пароль не поменялся), а вот одиночный КД не имел в своей базе данных каталога AD актуального пароля для этих двух КД — ни текущего, ни предыдущего. Поэтому любые билеты Kerberos, полученные на этом КД для доступа к другим КД не годились. Это привело к ошибкам репликации, то есть — к невозможности поучить-таки новые значения паролей. Ситуация, таким образом, оказалась тупиковой.

Теперь, зная причину проблемы, можно найти способ её устранения: нужно заставить одиночный КД получить билет для доступа к другому КД не с самого себя, а с одного из этих других КД — тогда билет будет создан на основе актуального пароля. Для этого делаем следующее:

1. На одиночном КД останавливаем службу Центр распространения ключей на одиночном KDC командой

net stop kdc

2. Очищаем на нём же кэш билетов Kerberos сеанса входа локальной системы командой

klist -li 0x3e7 purge

3. Производим репликацию с другим КД (например, через консоль AD Sites & Services )

Репликация теперь проходит успешно. Теперь можно смело запускать (командой net start kdc) службу Центр распространения ключей — проблема устранена.

Ну, и, наконец, о том где сведения из этой статьи могут пригодится на практике: такая проблема может встретиться, например, при длительном (более одного месяца) перерыве связи с филиалом, где установлен свой контроллер домена. То есть проблема может возникнуть, даже если перерыв репликации меньше, чем время жизни захороненных объектов, и эта проблема сама не пройдёт.

Так что, может быть, эта статья и принесёт кому-нибудь конкретную пользу.

 

Реклама
    • Аноним
    • 07.12.2016

    спасибо!

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: