- PVSM.RU - https://www.pvsm.ru -
Всегда приятно вспомнить как удалось решить какую-нибудь нетривиальную задачу. Но бывает и наоборот. Задача была вроде понятна, но вот решить её не удалось. Ниже я расскажу грустную историю из моей практики. Грустная она потому, что я, до сих пор, не знаю, как решить ту проблему. История, в очередной раз, напомнит как важно уделять должное внимание резервному копированию и тщательному обдумыванию своих действий. Ну а если кто-то из читателей расскажет мне, что можно было сделать, чтобы добиться лучшего результата, то это будет просто замечательно.
Итак, жил-был системный администратор и был у него Active Directory домен. Так как инфраструктура была небольшой и досталась ему в наследство давно, то был в ней всего один контроллер домена с установленной на нём Windows Server 2003. Ресурсов сильно не хватало, поэтому на этом же сервере было установлено довольно большое количество приложений, которыми пользовался сам администратор и некоторые его коллеги. Ну и вишенкой на торте — резервных копий в этой компании никогда не делалось. Что могло пойти не так? Подробности под катом.
Ничто не может оставаться неизменным вечно и решило техническое руководство, что пора переходить на более свежую версию Active Directory, а значит нужно обновить контроллер домена. Как перейти на более свежую версию Windows Server в своем домене, если у вас есть всего один контроллер, на котором стоит много дополнительного софта и для которого нет резервных копий? Конечно — in-place upgrade! Во время обновления что-то пошло не так и процесс прервался с ошибкой. После этого посыпались ошибки от различных систем и приложений, и наш герой, поняв, что со старым контроллером беда, решил исправить ситуацию добавив новый контроллер (очень жаль что он не начал с этого). Был поднят новый сервер с Windows Server 2008 и он попытался ввести его в домен, чтобы затем сделать контроллером. Получив очередное сообщение об ошибке, администратор понял, что пришла пора искать помощь на стороне.
Именно здесь начинается наше с ним знакомство. Небольшая ремарка — в процессе поиска способа ему помочь участвовало несколько человек, но чтобы упростить повествование, я не буду акцентировать на этом внимание, тем более, что никаких технических деталей это не добавит.
По этическим причинам я не могу демонстрировать скриншоты из чужой рабочей среды. Поэтому, для написания истории я (теперь уже зная, что именно сломалось) воспроизвёл ситуацию в тестовой лаборатории. Для желающих, в конце статьи будет сказано, как вы можете сделать тоже самое, если вам захочется попробовать свои силы в решении этой задачки. Таким образом, нашими пациентами будут домен Test.local, Windows Server 2003 контроллер TESTDC, Windows Server 2008 сервер TESTNEWDC.
При попытке ввести новый сервер в домен выдавалась следующая ошибка:
Как обычно, проблемы с Active Directory начинаются с DNS. Заглянув в оснастку управления DNS на TESTDC мы увидели пустой сервер без зон. Так явно быть не должно, так как этот единственный контроллер, по совместительству являлся и единственным DNS сервером.
Итак, задача номер один — восстановить работоспособность DNS. Без него о рабочем домене не может быть и речи. На всякий случай, уточнили у заказчика, что все зоны были Active Directory integrated. Значит найти их файлы на самом сервере не удастся. Данные DNS должны загрузиться из разделов Active Directory базы. Но, похоже, что с этим были проблемы. Заглянули в System и Application логи, чтобы посмотреть, что происходит при старте службы DNS. Так и есть — в логах пестрили ошибки Event ID 4000 [1] и Event ID 4007 [2], характерные для проблем с работой AD integrated зоны:
Это был очень неприятный знак, так как невозможность загрузки информации из Active Directory базы единственного доступного контроллера намекала, на серьезность случившегося. Однако, оставалась надежда, что получится руками заставить всё это заработать. При попытке создать зону заново, подтвердилась мысль, что DNS не может ничего получить из Active Directory. Он не мог получить даже список контроллеров домена на которых хранятся соответствующие разделы:
В качестве обходного решения было решено попробовать подменить родную DNS зону локальной заглушкой. Понятно, что в ней не будет всей необходимой информации, но контроллер можно заставить принудительно обновить DNS записи Active Directory, а всё остальное пока могло подождать. Так что, была создана локальная основная зона test.local и в ней были разрешены динамические обновления. Самый простой способ, который предлагает Microsoft [3] для регистрации DNS записей контроллера домена — рестартовать на нём сервис NetLogon. Это и было сделано. В результате, была получена локальная зона с нужными записями:
Здесь мы взяли паузу. Заказчик проверил функциональность приложений и систем в своей среде. Всё работало. пользователи могли штатно использовать свои учётные записи. У заказчика слегка отлегло от сердца — по крайней мере люди могли вернуться к работе.
Но основная проблема не была решена. Мы вернулись к попытке ввести новый сервер в домен. Для введения в домен использовался аккаунт доменного администратора test.localadministrator, который успешно логинился на старый контроллер. Снова ошибка. Правда, на этот раз, другая. Теперь «Login Failure: The target account name is incorrect».
Помня о проблеме загрузки информации из Active Directory, здесь появилась идея попробовать вместо доменного аккаунта локальный аккаунт администратора со старого контроллера testdcadministrator. Понятно, что, по сути, это тот же аккаунт, так как при создании домена, локальный built-in администратор первого контроллера становится built-in администратором домена, но, тем не менее, это сработало. Сервер был успешно введен в домен и его аккаунт появился в Active Directory базе:
Пришло время попытаться сделать его контроллером. Снова ошибка. Процесс получения роли контроллера через dcpromo завершался с сообщением «Access denied»:
В Active Directory логах старого контроллера при этом часто встречалось сообщение об ошибке Event ID 40960 — опять проблема с учётной записью, на сей раз, с записью самого контроллера:
Вообще, мысли о такой возможности появились ещё на этапе обнаружения ошибки с DNS [4], но очень уж не хотелось в это верить.
Итак, стало окончательно ясно, что пошло не так во время in-place upgrade — были потеряны те данные о доменной учётной записи контроллера, что хранились на нём локально. В итоге, у нас был частично работоспособный домен, но не было контроллера домена. Был лишь сервер, на котором хранилась Active Directory база. Так как он не помнил своего компьютерного пароля, то для домена он, по сути, был никем. Выше была приведена ссылка, на статью Microsoft, которая предлагает метод решения этой проблемы:
Проблема в том, что для этого нужно иметь второй рабочий контроллер, а его не было.
Вообще, раз у нас есть проблема с несовпадением пар логин-пароль хранящихся локально и в базе Active Directory, то для её решения нам нужно иметь возможность как-то эти данные изменять.
С локальной версией учётной записи всё просто. Есть замечательная утилита от Joeware — machinepwd [5]. Она позволяет задать произвольный пароль компьютерной записи (а если запись эта еще не сломана, то не только локально, но и в AD базе).
Сложнее с записью хранящейся в AD. Так как учётные записи контроллеров критически важны для этой службы, от она защищает их от любых посягательств. Мы попробовали следующее:
Последней надеждой было достать текущий пароль контроллера из Active Directory. После этого можно было бы установить такое же локальное значение пароля. Есть много инструментов для извлечения этой информации (например: Mimikatz DC sync [7]). Однако, даже имея доступ администратора, извлечь пароль в открытом виде можно только если ДО его последней смены была включена настройка Store passwords using reversible encryption [8]. В нашем случае, она была выключена. Так как пароль принадлежал компьютерной учётной записи, то не было никаких шансов подобрать его по словарю имея на руках NTLM hash.
Неприятно это признавать, но я так и не придумал, как в этой ситуации исправить положение. Заказчик был вынужден передподнимать домен в праздники (спешки, в принципе, не было — с локальной зоной DNS, пользователи даже не заметили, что что-то не так, так что он мог спокойно подготовиться к этой операции). Не получилось даже воспользоваться инструментами миграции — для переноса паролей они требовали наличия доверительных отношений между старым и новым доменами, но для установления этих отношения нужен живой контроллер домена. Понятно, что человек сам себе злобный буратино и сделал не так всё, что только было можно, но всё-таки мне было обидно.
Надеюсь, вам понравилась эта история с немного грустным финалом. В качестве послесловия, несколько напоминаний начинающим администраторам Active Directory:
P.S. Если вы хотите получить тестовую среду с такой же проблемой, то всё что вам нужно, это поднять Windows Server 2003 контроллер домена, скачать утилиту machinepwd, ссылку на которую я дал выше, отключить на контроллере сетевое подключение, остановить службу KDC и, с помощь machinepwd, задать новый компьютерный пароль.
P.P.S. Если вы знаете способ в такой ситуации починить связь между контроллером и доменом, то поделитесь им, пожалуйста с аудиторией. Ваш подвиг не будет забыт!
Автор: Aivendil
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/backup/183072
Ссылки в тексте:
[1] Event ID 4000: https://technet.microsoft.com/en-us/library/cc735673(v=ws.10).aspx
[2] Event ID 4007: https://technet.microsoft.com/en-us/library/cc774603(v=ws.10).aspx
[3] предлагает Microsoft: https://support.microsoft.com/en-us/kb/556002
[4] ошибки с DNS: https://support.microsoft.com/en-us/kb/2751452
[5] machinepwd: http://www.joeware.net/freetools/tools/machinepwd/
[6] keytab: https://kb.iu.edu/d/aumh
[7] Mimikatz DC sync: https://adsecurity.org/?p=2053
[8] Store passwords using reversible encryption: https://technet.microsoft.com/en-us/library/hh994559(v=ws.11).aspx
[9] Источник: https://habrahabr.ru/post/309132/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.