Реанимация контроллера домена

Что вы знаете об отпуске? Отпуск — это круто! Кто-то едет окучивать грядки, кто-то пляжи. Но однозначно, самая плохая мысль, которая может придти в голову — работать в отпуске. Если вы, сидя на пляже, пытаетесь проверить рабочую почту, участвуете в конференциях, раздаете какие-то указания, проверяете работу сотрудников, то вам, скорее всего надо к доктору. Это не отпуск, это мука.
Я провел отпуск правильно. Выключил телефон, благо компания Билайн позаботилась о том, чтобы у меня не было никакой связи в том месте, где я находился, не заходил в интернет, и полностью посвятил себя простому деревенскому быту. А вот вернувшись в Северную Пальмиру, я обнаружил приличное количество писем от одного веселого заказчика, которого я на самом деле обожаю, ибо он обеспечивает меня не просто работой, а постоянными симуляторами геморроя. В общем и целом, задачка была опять из разряда: “Шеф, усе пропало!”. Основная задача была связана с восстановлением организации Exchange практически с нуля, но внезапно выплыл некий side project, в виде мертвой службы ADDS в домене, который обслуживает инфраструктуру (гипервизоры и все, что с ними связано).

Что же произошло?
Умер сервер с ролью контроллера домена вместе с дисками, на которых находился его VHD. Умер от слова совсем, и восстановлению не подлежит. Слово “бэкап” произносить в данном контексте неуместно, т.к. парни не просто смелые, а отважные. И резервных копий нет и, похоже, никогда и не было. Но есть же второй контроллер домена! Круто!
Правда есть один нюанс: ни один инструмент управления службой ADDS не смог подключиться к ней со словами “The domain can’t exist or can’t be contacted”. Т.е. домен вроде как есть, но в то же время его вроде как и нет.
Куда нужно сходить первым делом, если есть какие-то проблемы с доступом к Active Directory? Ведущие собаководы утверждают, что первым делом надо смотреть в Domain Name System, т.к. “99% проблем с AD это проблемы с DNS!” (городская легенда).
Но там все оказалось вполне себе неплохо. Поудалял записи от старого контроллера (некоторые, типа А удаляются простым Delete, некоторые, типа NS надо удалять на вкладке Name Servers соответствующих зон). Привел в порядок, одним словом. Результат? Нулевой.
Смотрим дальше… При запуске DCDIAG получаем ошибку 1355, причем у меня их было несколько (GC_SERVER_REQUIRED, PDC_REQUIRED и еще всякие разные, в общем все сводилось к такому вот шаблону текста: DcGetDcName(PDC_REQUIRED) call failed, error 1355). По моему скромному разумению все это указывает на проблемы с механизмом Domain Controller Locator.
Вначале меня посетила мысль о том, что роли FSMO остались на стром контроллере, но это не совсем укладывалось в текущую картину, т.к. роли FSMO особо на DC Locator не влияют. Вернее влияют, но не в контексте обычной аутентификации. Проверив расположение ролей с помощью NTDSUTIL, я обнаружил отсутствие информации о старом контроллере. Т.е. метаданные из базы кто-то вычистил до меня (на самом деле, заказчик мне привел экспертное заключение каких-то абстрактных специалистов, что домену пришла труба, и никаких вариантов восстановления просто нет, кроме как создать новый домен, и “перезавести машины в него”. Видимо это и были авторы удаления метаданных).
Что было еще более интересным, так это отсутствие shared folders, которые мы привыкли видеть на любом контроллере домена: SYSVOL и NETLOGON. По сути эти каталоги представляют собой хранилище политик домена (SYSVOL) и логон-скриптов (NETLOGON).
Соответственно, физически они расположены (при дефолтной инсталляции) в C:\Windows\sysvol\<Имя домена>\sysvol (SYSVOL Shared Folder) и C:\Windows\sysvol\<Имя домена>\sysvol\scripts (NETLOGON Shared Folder). Создание этих shared folders вручную ни к какому результату не приводит: ни контроллер от этого работать не начнет, ни сами настройки не сохранятся (при первой же перезагрузке эти shared folders исчезают).
Лезем в Event Viewer. В логе службы ADDS все на первый взгляд ровно. Как и на второй. Интересности обнаруживаются в логе службы репликации распределенной файловой системы (Applications and Services Logs\DFS Replication). Там я нашел довольно интересное событие DFSR Error 4612, которое говорит о том, что каталог SYSVOL на данном контроллере был инициализирован и ожидает начальной репликации от умершего контроллера. И, что самое забавное, данный контроллер до завершения процесса репликации не будет работать. Прямо так в логе и пишется. Т.е. по идее, создание роли контроллера домена было не завершено до конца с самого начала, и он никогда не функционировал, как контроллер. Тупо стоял и молотил воздух.
Как же его завести, если того самого контроллера, с которого он ожидает начальной репликации, не существует? Тут на помощь нам приходит процедура авторитативного восстановления SYSVOL. Почему авторитативного? Потому что других “авторитетов” в сети, кроме этого единственного контроллера нет. Не на кого положиться, и ему придется принимать решение самому. Для этого, правда, он должен быть держателем роли PDC Emulator. Захват роли процедура не сложная, с учетом неработоспособности соврменных инструментов управления (консоли и модуль Active Directory в PowerShell), придется работать по старинке. Так как же произвести процедуру авторитативного восстановления SYSVOL при неработающем редакторе ADSIedit? Использовать вместо этого LDP.exe.
Итак, что же было сделано:
1. Остановлена служба репликации:
net stop DFSR или Stop-Service DFSR
2. Далее мне нужно изменить значение двух аттрибутов сервиса SYSVOL Subscription контроллера домена, объект которого можно найти по LDAP-пути CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
msDFSR-Enabled=FALSE (говорит о том, что репликации нет, дефолтное значение TRUE)
msDFSR-Options=1 (говорит о том, что наш контроллер обладает авторитативным экземпляром, т.е. истинным и верным, дефолтное значение 0)
Проблема была в том, что ADSIedit при попытке подключения к любому из контекстов AD, говорил, что домена не существует, либо он недоступен.
Меня спасла утилита LDP.exe, которая позволяет напрямую подключиться к экземпляру NTDS.dit (вру, конечно, т.к. подключение происходит по LDAP-протоколу на порт 389).
2а. Запускаем LDP.exe, жмем Connection — Bind (Ctrl+B) и цепляемся прямо к контроллеру домена, на котором мы ее и запустили в контексте текущего пользователя (прав-то, надеюсь, достаточно? Нужны права группы Domain Adminы). По сути просто жмем ОК.
2б. Дальше нам нужно подключиться к Default Naming Context, для чего жмем View — Tree (Ctrl+T) и в BaseDN выбираем корень домена в LDAP формате: DC=domain,DC=com).
2в. Ищем объект службы SYSVOL Subscription, последовательно раскрывая ветки дерева. Напоминаю, объект находится по пути CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>.
2г. Выделяем объект, и в контекстном меню (умное слово, на самом деле это меню правой кнопки мыши :)) выбираем Modify (Ctrl+M).
2д. В области Edit Entry, в поле Attribute вводим msDFSR-Enabled, в поле Values вводим FALSE. Выбираем Operation = Replace, жмем кнопку Enter, видим, что операция появилась в Entry List. Вводим данные для второго аттрибута (Attribute = msDFSR-Options, Values = 1, так же жмем Enter, и проверяем наличие в Entry List), и вот после этого жмем кнопку Run. И получаем ошибку 0x2098 Insufficient access rights :) Лечится просто: запустите LDP.exe от имени администратора (RunAs Administrator), UAC на серверах все-таки зло… В итоге должно получиться сообщение, что вызов ldap_modify_s изменил 2 аттрибута объекта службы SYSVOL Subscription.
2е. Не 3акрываем LDP.exe, она нам еще понадобится.
3. Запускаем службу репликации распределенной файловой системы:
net start DFSR или Start-Service DFSR
NOTE: Перед запуском этой команды рекомендуют очистить каталоги
%WINDIR%SYSVOL\<Имя домена>\sysvol\Policies
%WINDIR%SYSVOL\<Имя домена>\sysvol\Scripts

чтобы не получить кучу неработающих политик. Но у меня там было чисто, т.к. контроллер даже не выполнил начальной репликации.
4. В журнале службы (Applications and Services Logs\DFS Replication) сразу же получаем событие от DFSR EventID 4114, которое говорит о том, что репликация каталога SYSVOL отключена.
5. Меняем значение msDFSR-Enabled обратно в TRUE (шаги 2а — 2д, обратите внимание, что меняем значение только одного аттрибута, msDFSR-Options не трогаем)
6. Запускаем репликацию (из командной строки, запущенной с повышением привилегий, иначе опять получите сообщение о недостатке прав):
repadmin /syncall /AdP
7. Запускаем dfsrdiag /ADPoll (если получаете сообщение, что команда не распознана, установите DFS Management Tools, они в Features\Remote server Administration Tools\Role Administration Tools\File Services Tools или Add-WindowsFeature RSAT-DFS-Mgmt-Con)
8. В журнале DFS Replication должно появиться событие DFSR EventID 4602, говорящее о том, что процесс авторитативного восстановления запущен.
На этом все. Перезагружаем сервер и пробуем запустить, например, ADUC. Но тут меня ждал Его Величество Облом. Не работает.
Дело оказалось в том, что каталог SYSVOL был, но политик в нем не было. А их должно быть минимум две: Default Domain Policy c GUID {31B2F340-016D-11D2-945F-00C04FB984F9} и Default Domain Controller Policy c GUID {6AC1786C-016F-11D2-945F-00C04FB984F9}.
Восстановить их можно с помощью утилиты DCGPOFIX, которая воссоздает политики, используя для этого политики, которые хранятся в базе AD (CN=Policies,CN=System,DC=Domain,DC=ru). Один нюанс, даже два:
1. Все изменения, которые вы делали в этих двух политиках, придется делать заново, т.к. большинство настроек хранятся в GPT как раз в каталоге SYSVOL\Policies, а у нас там ничего нет.
2. Сертификат для EFS, если он используется в Default Domain Policy так же не пересоздается. придется все делать вручную. И дай Бог, чтобы у вас не было включено шифрование EFS на уровне политик…
Собственно после выполнения этой последней процедуры, контроллер ожил и заработал.
Выводы и уроки:
1. Развертывание дополнительного контроллера домена — не просто NNF (Next-Next-Finish), хотя казалось бы, чего там сложного, но данный случай показывает, что не проконтролировав процесс начальной репликации, в итоге администратор получил тыкву, практически бесполезную единицу.
2. Резервное копирование — это не для трусов, оно для умных. Наличие простой копии System State могло сильно упростить жизнь.
3. Ну и если вы встряли в подобное, не стоит сразу делать выводов космического масштаба и… ну вы поняли :) Есть городская легенда, что службу ADDS можно спасти при наличии всего лишь файла NTDS.dit. Так что never give up. Пишите мне, в конце концов, придумаем что-нибудь ;)

 

 

 

Реклама
Реанимация контроллера домена

Реанимация контроллера домена: 6 комментариев

  1. К:

    Мои за мой отпуск угробили БД OpsMgr. Не совсем прям насмерть, но раздули в семь раз почти. Со всеми вытекающими.

  2. Вообще странно… Я думал у тебя народ дрессированный. В семь раз за пусть даже месяц (или у тебя, как у нас 14 дней отпуск?) это что же надо было творить-то?

  3. К:

    Да собсно проблема была простая, но нечастая.
    Одна из систем «двинулась крышей». Выяснить, что там с ней пошло не так уже невозможно, но смысл в том, что она стала пытаться зайти в соседнюю систему (это нормально, это интеграция) вместо обычных 10-15 раз в минуту по 20-50 раз в секунду. А событие входа снимается правилом-коллектором. Оно дефолтное и много лет проблем не приносило. А тут оно стало собирать по 15-20 ГБ в сутки. Ну остальное вытекает. До меня они или не пытались дозвониться или я был в самолетах (судя по логам началось все как раз в тот день, который я провел в самолетах). Они не придумали ничего лучшего как позвать нашего ДБА, который включил AutoGrow. Весь кабздец от начала до моего вмешательства продолжался примерно 4 дня.
    Такая фигня блин. Если б дозвонились, я бы уже или починил или сказал погасить систему на сутки пока я не доберусь до компа с инетом. Последствия были бы сильно меньше.

  4. sdd:

    За статью спасибо, весьма полезно.
    У меня был случай забавный случай. Купили сервер + win 2003, решил его сделать основным DC, а старый сделать рядовым сервером, потому как старый уже был, пора было списывать.
    Новый сервер ввел в домен и поднял AD DS, репликация прошла нормально. Далее перенес роли. И вот тут пошло наперекосяк. Новый сервер принял роли, а старый не отдал. В общем поимел 2 сервера, которые считали себя единственными DC. Компы в сети домен не видели.
    После некоторого времени, затраченного на попытки привести всё в порядок — плюнул на всё и ввел все компы в домен нового сервера. Благо, что ошибок он не показывал. С тех пор отработал он у меня 7 лет, как часы. Пока не устарел и не начали диски помирать от старости.
    А для себя я сделал вывод: если сеть небольшая, то иногда быстрее будет снести развалины и построить заново, чем восстанавливать пепелище.

  5. Алексей:

    Здравствуйте! Меня ввело в заблуждение примечание к 3 пункту
    3. Запускаем службу репликации распределенной файловой системы:
    net start DFSR или Start-Service DFSR
    NOTE: Перед запуском этой команды рекомендуют очистить каталоги
    %WINDIR%SYSVOL\\sysvol\Policies
    %WINDIR%SYSVOL\\sysvol\Scripts
    чтобы не получить кучу неработающих политик. Но у меня там было чисто, т.к. контроллер даже не выполнил начальной репликации.

    Можно немного поподробнее об этом моменте: просто мне необходимо применить авторитативное восстановление SYSVOL, и в указанных папках много политик. Если я их очищу, то смогу ли я в конце простым копированием назад всех политик вернуть их работоспособность? Или все сложнее гораздо

  6. Дима:

    Спасибо за статью, хорошо написано и с юмором

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

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

Логотип WordPress.com

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

Google+ photo

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

Фотография Twitter

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

Фотография Facebook

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

w

Connecting to %s