Всегда приятно вспомнить как удалось решить какую-нибудь нетривиальную задачу. Но бывает и наоборот. Задача была вроде понятна, но вот решить её не удалось. Ниже я расскажу грустную историю из моей практики. Грустная она потому, что я, до сих пор, не знаю, как решить ту проблему. История, в очередной раз, напомнит как важно уделять должное внимание резервному копированию и тщательному обдумыванию своих действий. Ну а если кто-то из читателей расскажет мне, что можно было сделать, чтобы добиться лучшего результата, то это будет просто замечательно.
Итак, жил-был системный администратор и был у него 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 и Event ID 4007, характерные для проблем с работой AD integrated зоны:
Это был очень неприятный знак, так как невозможность загрузки информации из Active Directory базы единственного доступного контроллера намекала, на серьезность случившегося. Однако, оставалась надежда, что получится руками заставить всё это заработать. При попытке создать зону заново, подтвердилась мысль, что DNS не может ничего получить из Active Directory. Он не мог получить даже список контроллеров домена на которых хранятся соответствующие разделы:
В качестве обходного решения было решено попробовать подменить родную DNS зону локальной заглушкой. Понятно, что в ней не будет всей необходимой информации, но контроллер можно заставить принудительно обновить DNS записи Active Directory, а всё остальное пока могло подождать. Так что, была создана локальная основная зона test.local и в ней были разрешены динамические обновления. Самый простой способ, который предлагает Microsoft для регистрации DNS записей контроллера домена — рестартовать на нём сервис NetLogon. Это и было сделано. В результате, была получена локальная зона с нужными записями:
Здесь мы взяли паузу. Заказчик проверил функциональность приложений и систем в своей среде. Всё работало. пользователи могли штатно использовать свои учётные записи. У заказчика слегка отлегло от сердца — по крайней мере люди могли вернуться к работе.
Но основная проблема не была решена. Мы вернулись к попытке ввести новый сервер в домен. Для введения в домен использовался аккаунт доменного администратора test.local\administrator, который успешно логинился на старый контроллер. Снова ошибка. Правда, на этот раз, другая. Теперь «Login Failure: The target account name is incorrect».
Помня о проблеме загрузки информации из Active Directory, здесь появилась идея попробовать вместо доменного аккаунта локальный аккаунт администратора со старого контроллера testdc\administrator. Понятно, что, по сути, это тот же аккаунт, так как при создании домена, локальный built-in администратор первого контроллера становится built-in администратором домена, но, тем не менее, это сработало. Сервер был успешно введен в домен и его аккаунт появился в Active Directory базе:
Пришло время попытаться сделать его контроллером. Снова ошибка. Процесс получения роли контроллера через dcpromo завершался с сообщением «Access denied»:
В Active Directory логах старого контроллера при этом часто встречалось сообщение об ошибке Event ID 40960 — опять проблема с учётной записью, на сей раз, с записью самого контроллера:
Вообще, мысли о такой возможности появились ещё на этапе обнаружения ошибки с DNS, но очень уж не хотелось в это верить.
Итак, стало окончательно ясно, что пошло не так во время in-place upgrade — были потеряны те данные о доменной учётной записи контроллера, что хранились на нём локально. В итоге, у нас был частично работоспособный домен, но не было контроллера домена. Был лишь сервер, на котором хранилась Active Directory база. Так как он не помнил своего компьютерного пароля, то для домена он, по сути, был никем. Выше была приведена ссылка, на статью Microsoft, которая предлагает метод решения этой проблемы:
Проблема в том, что для этого нужно иметь второй рабочий контроллер, а его не было.
Вообще, раз у нас есть проблема с несовпадением пар логин-пароль хранящихся локально и в базе Active Directory, то для её решения нам нужно иметь возможность как-то эти данные изменять.
С локальной версией учётной записи всё просто. Есть замечательная утилита от Joeware — machinepwd. Она позволяет задать произвольный пароль компьютерной записи (а если запись эта еще не сломана, то не только локально, но и в AD базе).
Сложнее с записью хранящейся в AD. Так как учётные записи контроллеров критически важны для этой службы, то она защищает их от любых посягательств. Мы попробовали следующее:
Последней надеждой было достать текущий пароль контроллера из Active Directory. После этого можно было бы установить такое же локальное значение пароля. Есть много инструментов для извлечения этой информации (например: Mimikatz DC sync). Однако, даже имея доступ администратора, извлечь пароль в открытом виде можно только если ДО его последней смены была включена настройка Store passwords using reversible encryption. В нашем случае, она была выключена. Так как пароль принадлежал компьютерной учётной записи, то не было никаких шансов подобрать его по словарю имея на руках NTLM hash.
Неприятно это признавать, но я так и не придумал, как в этой ситуации исправить положение. Заказчик был вынужден передподнимать домен в праздники (спешки, в принципе, не было — с локальной зоной DNS, пользователи даже не заметили, что что-то не так, так что он мог спокойно подготовиться к этой операции). Не получилось даже воспользоваться инструментами миграции — для переноса паролей они требовали наличия доверительных отношений между старым и новым доменами, но для установления этих отношения нужен живой контроллер домена. Понятно, что человек сам себе злобный буратино и сделал не так всё, что только было можно, но всё-таки мне было обидно.
Надеюсь, вам понравилась эта история с немного грустным финалом. В качестве послесловия, несколько напоминаний начинающим администраторам Active Directory:
P.S. Если вы хотите получить тестовую среду с такой же проблемой, то всё что вам нужно, это поднять Windows Server 2003 контроллер домена, скачать утилиту machinepwd, ссылку на которую я дал выше, отключить на контроллере сетевое подключение, остановить службу KDC и, с помощь machinepwd, задать новый компьютерный пароль.
P.P.S. Если вы знаете способ в такой ситуации починить связь между контроллером и доменом, то поделитесь им, пожалуйста с аудиторией. Ваш подвиг не будет забыт!
UPDATE: В результате дискуссии в комментариях выяснилось, что я был не прав — ручная смена пароля компьютера через MachinePWD это не полная эмулция того, что случилось. В случае смены пароля через эту утилиту, контроллер можно оживитьпросто остановкой KDC и запуском netdom resetpwd без шаманства. К сожалению, я не смог найти у себя оригинальный образ сервера для продолжения экспериментов. Получилось очень обидно.
Итак, жил-был системный администратор и был у него 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.
DNS
При попытке ввести новый сервер в домен выдавалась следующая ошибка:
Как обычно, проблемы с Active Directory начинаются с DNS. Заглянув в оснастку управления DNS на TESTDC мы увидели пустой сервер без зон. Так явно быть не должно, так как этот единственный контроллер, по совместительству являлся и единственным DNS сервером.
Итак, задача номер один — восстановить работоспособность DNS. Без него о рабочем домене не может быть и речи. На всякий случай, уточнили у заказчика, что все зоны были Active Directory integrated. Значит найти их файлы на самом сервере не удастся. Данные DNS должны загрузиться из разделов Active Directory базы. Но, похоже, что с этим были проблемы. Заглянули в System и Application логи, чтобы посмотреть, что происходит при старте службы DNS. Так и есть — в логах пестрили ошибки Event ID 4000 и Event ID 4007, характерные для проблем с работой AD integrated зоны:
Это был очень неприятный знак, так как невозможность загрузки информации из Active Directory базы единственного доступного контроллера намекала, на серьезность случившегося. Однако, оставалась надежда, что получится руками заставить всё это заработать. При попытке создать зону заново, подтвердилась мысль, что DNS не может ничего получить из Active Directory. Он не мог получить даже список контроллеров домена на которых хранятся соответствующие разделы:
В качестве обходного решения было решено попробовать подменить родную DNS зону локальной заглушкой. Понятно, что в ней не будет всей необходимой информации, но контроллер можно заставить принудительно обновить DNS записи Active Directory, а всё остальное пока могло подождать. Так что, была создана локальная основная зона test.local и в ней были разрешены динамические обновления. Самый простой способ, который предлагает Microsoft для регистрации DNS записей контроллера домена — рестартовать на нём сервис NetLogon. Это и было сделано. В результате, была получена локальная зона с нужными записями:
New DC
Здесь мы взяли паузу. Заказчик проверил функциональность приложений и систем в своей среде. Всё работало. пользователи могли штатно использовать свои учётные записи. У заказчика слегка отлегло от сердца — по крайней мере люди могли вернуться к работе.
Но основная проблема не была решена. Мы вернулись к попытке ввести новый сервер в домен. Для введения в домен использовался аккаунт доменного администратора test.local\administrator, который успешно логинился на старый контроллер. Снова ошибка. Правда, на этот раз, другая. Теперь «Login Failure: The target account name is incorrect».
Помня о проблеме загрузки информации из Active Directory, здесь появилась идея попробовать вместо доменного аккаунта локальный аккаунт администратора со старого контроллера testdc\administrator. Понятно, что, по сути, это тот же аккаунт, так как при создании домена, локальный built-in администратор первого контроллера становится built-in администратором домена, но, тем не менее, это сработало. Сервер был успешно введен в домен и его аккаунт появился в Active Directory базе:
Пришло время попытаться сделать его контроллером. Снова ошибка. Процесс получения роли контроллера через dcpromo завершался с сообщением «Access denied»:
В Active Directory логах старого контроллера при этом часто встречалось сообщение об ошибке Event ID 40960 — опять проблема с учётной записью, на сей раз, с записью самого контроллера:
Вообще, мысли о такой возможности появились ещё на этапе обнаружения ошибки с DNS, но очень уж не хотелось в это верить.
Учётные записи
Итак, стало окончательно ясно, что пошло не так во время in-place upgrade — были потеряны те данные о доменной учётной записи контроллера, что хранились на нём локально. В итоге, у нас был частично работоспособный домен, но не было контроллера домена. Был лишь сервер, на котором хранилась Active Directory база. Так как он не помнил своего компьютерного пароля, то для домена он, по сути, был никем. Выше была приведена ссылка, на статью Microsoft, которая предлагает метод решения этой проблемы:
- Остановить службу KDC на повреждённом контроллере
- Выполнить с правами администратора команду netdom resetpwd /server:<PDC.domain.com> /userd:<Domain\domain_admin> /passwordd:*
- Перезагрузить контроллер
Проблема в том, что для этого нужно иметь второй рабочий контроллер, а его не было.
Вообще, раз у нас есть проблема с несовпадением пар логин-пароль хранящихся локально и в базе Active Directory, то для её решения нам нужно иметь возможность как-то эти данные изменять.
С локальной версией учётной записи всё просто. Есть замечательная утилита от Joeware — machinepwd. Она позволяет задать произвольный пароль компьютерной записи (а если запись эта еще не сломана, то не только локально, но и в AD базе).
Сложнее с записью хранящейся в AD. Так как учётные записи контроллеров критически важны для этой службы, то она защищает их от любых посягательств. Мы попробовали следующее:
- Самый простой способ — Reset компьютерной учётной записи через Active Directory Users and Computers (если вы делаете Reset, то пароль сбрасывается в значение по умолчанию, при создании нового компьютера — COMPUTERNAME$). Операция выдала ошибку доступа.
- nltest. Этот инструмент позволяет управлять свойствами secure channel (та же пара логин-пароль) для компьютеров в Active Directory. Вообще говоря, он позволяет сбросить значение пароля на обеих сторонах. Ошибка обнаружения домена I_NetLogonControl failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
- dsmod. Утилита для работы с компьютерной учётной записью в самой Active Directory бузе. Ошибка Internal Error.
- admod. Еще одна утилита для работы с объектами в AD. Ошибка Unwilling to perform.
- ktpass. Интересный инструмент, позволяющий генерировать keytab файлы (своего рода оффлайн Kerberos token). Одной из особенностей этой утилиты является возможность сменить пароль учётной записи, для которой вы создаете keytab файл. Снова ошибка доступа.
Последней надеждой было достать текущий пароль контроллера из Active Directory. После этого можно было бы установить такое же локальное значение пароля. Есть много инструментов для извлечения этой информации (например: Mimikatz DC sync). Однако, даже имея доступ администратора, извлечь пароль в открытом виде можно только если ДО его последней смены была включена настройка Store passwords using reversible encryption. В нашем случае, она была выключена. Так как пароль принадлежал компьютерной учётной записи, то не было никаких шансов подобрать его по словарю имея на руках NTLM hash.
Подводя итог
Неприятно это признавать, но я так и не придумал, как в этой ситуации исправить положение. Заказчик был вынужден передподнимать домен в праздники (спешки, в принципе, не было — с локальной зоной DNS, пользователи даже не заметили, что что-то не так, так что он мог спокойно подготовиться к этой операции). Не получилось даже воспользоваться инструментами миграции — для переноса паролей они требовали наличия доверительных отношений между старым и новым доменами, но для установления этих отношения нужен живой контроллер домена. Понятно, что человек сам себе злобный буратино и сделал не так всё, что только было можно, но всё-таки мне было обидно.
Надеюсь, вам понравилась эта история с немного грустным финалом. В качестве послесловия, несколько напоминаний начинающим администраторам Active Directory:
- Использовать один единственный контроллер домена можно только если у вас есть ОЧЕНЬ серьезные на то причины (как правило, отсутствие денег на еще одну лицензию Windows Server). Вы получаете единую точку отказа, проблемы с которой полностью выводят из строя вашу инфраструктуру.
- Независимо от того, сколько у вас контроллеров, но особенно если он всего один, ВСЕГДА делайте резервные копии. Носители информации сейчас стоят так дешево, что не может быть никаких причин на этом экономить.
- Не ставьте приложения на контроллер домена без крайней необходимости. Это совсем не тот сервер на который можно что-то поставить «заодно».
- Еще раз, повторюсь — никогда не начинайте процедуру in-place upgrade не имея резервной копии сервера. Эта процедура сама по себе несёт больше рисков, чем миграция, так что незачем подставлять себя еще больше, лишаясь ещё и возможности отката изменений.
P.S. Если вы хотите получить тестовую среду с такой же проблемой, то всё что вам нужно, это поднять Windows Server 2003 контроллер домена, скачать утилиту machinepwd, ссылку на которую я дал выше, отключить на контроллере сетевое подключение, остановить службу KDC и, с помощь machinepwd, задать новый компьютерный пароль.
P.P.S. Если вы знаете способ в такой ситуации починить связь между контроллером и доменом, то поделитесь им, пожалуйста с аудиторией. Ваш подвиг не будет забыт!
UPDATE: В результате дискуссии в комментариях выяснилось, что я был не прав — ручная смена пароля компьютера через MachinePWD это не полная эмулция того, что случилось. В случае смены пароля через эту утилиту, контроллер можно оживитьпросто остановкой KDC и запуском netdom resetpwd без шаманства. К сожалению, я не смог найти у себя оригинальный образ сервера для продолжения экспериментов. Получилось очень обидно.