Итак, жил-был системный администратор и был у него 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. Если вы знаете способ в такой ситуации починить связь между контроллером и доменом, то поделитесь им, пожалуйста с аудиторией. Ваш подвиг не будет забыт!
Комментарии (69)
rockin
03.09.2016 19:04+8Честно говоря, у меня волосы дыбом встали. До такого состояния в свой практике я ничего не доводил…
Когда я был ещё очень юн и не умел, досталась мне во всевластие похожая «инфраструктура». Только с 2к сервером. Где предыдущий хацкер наставил зачем-то сервисов овер100500 на контроллер домена.
И решил я скиллы покачать, проапгредиться на 2003, а заодно и сервисы лишние убрать.
Что сделал — дабы не потерять AD, я всего лишь добавил второй контроллер (кой собрать можно натурально из г. и палок, там достаточно 256 метров оперативки и дохлейший проц), попробовал как туда-сюда можно менять хозяев схемы и прочего, как можно днс переносить, ну и только тогда я решился на апргрейд 2000->2003 старого сервера, оставив хозяином второй. Сервер успешно проапгрейдился, лес остался уровня 2к. Потом последовала обратная операция, хозяином стал старый сервер. Далее убрал вспомогательный сервер и апгрейдим лес до 2003.
Чтобы было понятно — это не тру вей, но я так скиллы набивал когда-то давно.
И, да, эти все операции производились в рабочее время, и офис не почувствовал никаких помех в работе.
Сейчас это вообще не актуально, т.к. виртуализация решает. Поставил контроллер в виртуалочку, да бекапь себе виртуалочку на соседний жёсткий, при желании — в облачко.Aivendil
03.09.2016 23:15+1Ну да. Логично. Собственно, когда он понял, что возникла проблема он ведь нашёл ресурсы на дополнительный сервер. Я не мог понять как он этого не сделал ДО этого. Ну и начать in-place upgrade не сделав элементарного бекапа это…
dklm
03.09.2016 19:08+1как-то решал я одну проблему с АД (2008R2), уже не помню что я за команду ввел(запустил утилиту), но команда была от 2000 домена, и привело это к проблеме с правами на каталог SYSVOL на всех контроллерах, короче домен помер. Мораль: наличие нескольких контроллеров может не спасти ваш домен от вас).
Дело было в воскресение, и я быстро восстановил домен контроллеры из резервных копий (3 шт).
Некоторые консерваторы могут закидать меня яйцами =) но все домен контроллеры я разворачивал виртуальными, и это позволило мне за час восстановить работу домена. В последствии я еще переустановил роль AD на всех все RODC контроллерах.
По поводу отсутствия денег:
1 — если поставить на весы 800 уе за лицензию и деятельность предприятия, что выиграет?
2 — бу сервера сейчас продают от 500 уе за 4 ядра 24гб памяти (ддр3)…Aivendil
03.09.2016 23:18+1Тут сильно зависит от директора. Ну вот не даёт он например денег на лицензию — не из своих же её покупать?
А вы правильно говорите — даже самые страшные косяки не так печалят, если есть резервная копия. И вот тут уже цена вопроса сейчас просто смешная. Два 500ГБ винчестера (для надежности) стоят 5к рублей. А резервных копий контроллера там можно на полгода ежедневных бекапов хранить.
Sergey-S-Kovalev
04.09.2016 16:59+2Разговор про полные копии АД:
Хранить резервные копии КД более месяца бессмысленно, пароли на учетную запись компьютеров меняются раз в 30 дней.
Поднимаете резервную копию КД месячной давности, и получаете проблему, что все ПК не имеют доверительных отношений с доменом :) перевводить всех то еще удовольствие.
Если КД больше одного, то КД должен знать (т.е. средство резервного копирования должно сообщать КД что оно было разбэкаплено) иначе выхватите USN Rollback. Начиная с Windows Server 2012 эту проблему победили, на предидущих же системах, требуется наличие обновления KB875495, а так же поддержка со стороны системы резервного копирования, если использовался не встроенный виндовый бэкап.
Итого не более недели.
Есть Exchange и/или Sharepoint? Тогда вам нужен одномоментный бэкап АД и ексчейнджа и шарепоинта. Нетривиальная задача, требующая недешевого железа и софта для своего работы.
Итого-итого — смысла в полном бэкапе более суток почти нет.
Однако если вести разговор об отдельных объектах, то можно и по полгода хранить.Aivendil
04.09.2016 17:09В моей фразе о возможности хранить хоть «полгода ежедневных бекапов» основной смысл был в том, что в нынешнюю эру дешевых носителей информации я не могу понять как можно совсем не делать резервных копий.
Полный бекап длительного срока хранения обычно используют когда на это есть юридические причины. Технически, действительно, не особо полезно.
V-core
05.09.2016 14:41Зачем тогда
работать на такое предприятиепредоставлять сервис который не в состоянии поддерживать?Aivendil
05.09.2016 16:33Ну вот, допустим, наняли студента начинающего. Он даже не понимает еще в чем риски такого решения. И не понимает что значит «не в состоянии поддерживать». А потом когда поймет, то идет к начальству за деньгами на лицензию, а ему их не дают. А так как он не является материально ответственным, то он и думает — «ну и фиг с вами». И продолжает работать за свою зарплату.
V-core
05.09.2016 18:10Ну значит виноваты те кто его вообще подпустил к домену.
Работать с единственным DC — это как ездить на одном колесе на велосипеде вместо двух положенных :) можно но не долго.Aivendil
05.09.2016 18:23Ну да. Но в данном случае вопрос «кто виноват?» меня не очень интересовал. А вот «что делать?» было любопытно.
sysmetic
03.09.2016 20:34Сразу после того, как in-place upgrade завершился с ошибками, не было варианта откатиться на последнюю точку восстановления, или загрузившись с загрузочного диска, запустить установщик старой WIndows Server 2003 в режиме сохранения установленной Windows?
AlexZaharow
03.09.2016 22:53Вы бы сделали перед «апгрейдом» резервную копию хотя бы системного диска? Это ж так глупо надеяться на «авось» в таком деле?
Aivendil
03.09.2016 23:20Заказчик пригласил нас на этапе «всё сломалось при in-place апгрейде, посмотрите почему не джойниться в домен новый сервер». А вот почему он перед in-place апгрейдом не сделал хотя бы одну резервную копию это, конечно загадка (я бы честно говоря её сделал еще перед подготовкой схемы к Widows Server 2008 контроллерам, там шансов на косяк меньше, но мало ли).
AlexZaharow
03.09.2016 23:55Извините, невнимательно прочитал вступление! Это ваше знакомство с ним так началось! Моя ошибка.
river-fall
03.09.2016 23:21Сначала пишете, что не знаете, как решить эту проблему, а в конце статьи сами же честно пишете, как её не создавать.
Сам микрософт говорит в своих статьях, что абсолютный минимум серверов AD DC — два, в моей практике было использовать три, разделенных географически и два из них были виртуализованные (win2012 прекрасно знает о том, что ее могут виртуализовать, поэтому там нет типичных проблем предыдущих редакций). Главное — выключить синхронизацию времени на виртуализованном DC (точнее, эмуляторе PDC) от гипервизора.
Ну, и бекапы, конечно. В моей практике использовались бекапы SysCtr Data Protection Manager, основная из его проблем — все его бекапы имеют нечитаемую извне структуру, т.е. базы DPM и его самого надо бекапить чем-то иным и в другое место.Aivendil
03.09.2016 23:22Всё честно. Я знаю как не создавать такую проблему и я не знаю как ей решить:)
Т.е. понятно, что до такого нельзя доводить, но мне до сих пор с профессиональной точки зрения любопытно — неужели ничего нельзя сделать?YourChief
03.09.2016 23:41Проблема, очевидно, в несовпадении хэшей паролей. Напрашивается решение или подобрать пароль с таким же хэшом, или поменять хэш и на проверяющей стороне.
Aivendil
03.09.2016 23:48Насколько я помню, поиск коллизии для этих хешей очень затратная задача. Грубо говоря, так можно было бы любой аккаунт в Active Directory взломать. Кто бы тогда вообще ее использовал? Все продукты, которые я находил, предлагали меняемое время поиска только при наличии входных данных (словарные пароли или точно известное число и тип символов), а компьютерный пароль генерируется системой. Т.е. он точно не словарный.
Но мне уже самому стало любопытно включить обратимое шифрование и посмотреть что там система, на самом деле, генерирует. Обязательно займусь на досуге.YourChief
03.09.2016 23:50В одном из комментариев выше я привёл Вам цифры: сколько времени нужно на взлом. Я не исключаю, что после осознания Вы смените профиль специализации :)
kalobyte
04.09.2016 01:56+3самое главное забыл — какие анальные кары последовали к тому админу?
он был на зарплате или сам по себе?dmitry_ch
05.09.2016 11:24Админ, конечно,
геройне очень умно подошел к делу, но — старшие-то товарищи?!
Напомню фразы из статьи:
...Active Directory домен. Так как инфраструктура была небольшой… то был в ней всего один контроллер домена с установленной на нём Windows Server 2003. Ресурсов сильно не хватало… на этом же сервере было установлено довольно большое количество приложений… резервных копий в этой компании никогда не делалось
решило техническое руководство, что пора переходить на более свежую версию Active Directory… Как перейти на более свежую версию Windows Server в своем домене, если у вас есть всего один контроллер, на котором стоит много дополнительного софта и для которого нет резервных копий? Конечно — in-place upgrade!
Ну прямо с самого начала понятно, куда все придет, и какой шанс просто не потерять ничего (напомню старую мудрость: «если все удастся, тебя даже не похвалят, а если не удастся, то виноват будешь именно ты»), но тех. рук-во «дало добро»! При этом зачем поднимать версию домена, и почему решено, изменение версии не потребует вложений в то же железо (точнее, их никто не планирует)?
beatcracker
04.09.2016 11:04+1Я бы попробовал сменить пароль контроллера домена напрямую в БД AD (NTDS.DIT) на заранее известный.
Сам не пробовал, но ссылки по теме:
http://www.passcape.com/windows_password_recovery_active_directory_explorer
https://www.dsinternals.com/en/dumping-ntds-dit-files-using-powershell/
https://github.com/MichaelGrafnetter/DSInternals
DikSoft
04.09.2016 12:49Я бы сделал с помощью Disk2vhd копию текущего DC, поднял бы на витруалке у себя копию и поиздевался со сбросом пароля доменного администратора, а также многократным dcdiag /fix, ntdsutil — sema data ana и т.п., т.е. все работы не на рабочей железке.
Aivendil
04.09.2016 14:24Я сделал копию текущего DC в виртуальную среду. Более того, как я сказал, я нашел способ воспроизвести такую проблему вообще в чистой лабе. Т.е. простор для любых экспериментов имелся и имеется.
Пароль администратора у меня был рабочий. Проблема была именно с компьютерным паролем контроллера домена.DikSoft
04.09.2016 16:57Опс. Не для всех это может быть очевидно. Про то, что все издевательства велись с виртуальной копией, наверное стоило упомянуть в статье?
Не упомянуты остались перезагрузки в «режим восстановления каталога» и попытки починиться через ntdsutil.
На сегодня развлечения продолжены, есть какие-то результаты?
Можете вывод >dcdiag /fix /verbose опубликовать для наглядности?Aivendil
05.09.2016 16:13+1Издевательства велись и над живой машинкой и над клоном. Да. стоило об этом сказать. Подумал что это подразумевается, раз я предлагаю способ как сделать такую же лабу себе любому желающему.
В режиме восстановления каталога вы получаете возможность поработать с размонтированной NTDS базой. ЧТо вы предложили бы с ней сделать? резервных копий, на которые можно было бы в этом режиме откатиться нет.
Я играюсь с этой виртуалкой уже полгода в расслабленном режиме (понятно, что заказчику уже без разницы, но самому любопытно). Результатов нет:) Но сейчас я довольно сильно занят на работе, так что скорее собираю идеи «на попробовать», когда будет время.
Dcdiag успешно проходит все тесты, кроме Eventlog (потому что там ошибки связанные с загрузкой DNS зоны из AD базы)
gotch
04.09.2016 14:39+1Вот тут товарищи говорят, что с netdom вас будет ждать успех, если вы будете запускать его от имени SYSTEM на DC.
https://blogs.technet.microsoft.com/reference_point/2012/12/03/secure-channel-broken-continuation-of-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/
Попробуйте — psexec -s -i или старый трюк с at.Aivendil
04.09.2016 14:48Эту статью я видел. Собственно, все эти способы я пробовал. Они сработают при наличии живого DC. Т.е. нужно выключить KDC на проблемном контроллере и netdom при сбросе пароля свяжется с этой службой на другом здоровом DC. Но здесь здорового DC не было.
Sergey-S-Kovalev
04.09.2016 16:40Статья отличный сборник советов как делать с КД не нужно. Собраны все касяки эксплуатации КД. Сделано все что бы было попроще убить КД %)
dmitry_ch
05.09.2016 08:19-1этот единственный контроллер, по совместительству являлся и единственным DNS сервером
Вот так делать не нужно, точно. ПО от MS дорого, машины под контроллеры выделать жаль, и все такое — но один контроллер, который же один и DNS сервер на всех…
решило техническое руководство, что пора переходить на более свежую версию Active Directory
Вероятно, техническое руководство взяло на себя ответственность за такой дизайн, при котором (как у вас и получилось) при первом же чихе вы сами себеотрезалиубили все?
Что помешало вам хотя бы поставить два сервера виртуализации, на них на каждом по виртуалке с контроллером, и эти виртуалки бекапить постоянно, чтобы потом, при необходимости, развернуть обе машины из бекапа? А уже потом ставить эксперименты? Если уже ваша компания созрела до домена, у и вас есть техническое руководство, потянуть вторую машину вы бы уж как-то могли…Aivendil
05.09.2016 11:02Видимо, вы не очень внимательно читали. Нас туда позвали попытаться помочь починить на этапе, когда не получалось ввести новый сервер в домен. У нас, конечно, волосы дыбом встали от такой ситуации.
phili_can
05.09.2016 12:28Еще как вариант, можно попробовать добавить контроллер домена под SAMBA и посмотреть что получится.
Aivendil
05.09.2016 12:29Не совсем понял что вы имеете ввиду? Контроллер нормально доступен по сети (доменными аккаунтами). Чем поможет добавление его под SAMBA?
phili_can
05.09.2016 12:50Не так давно был опыт перехода AD с Win на AltLinux. Было непривычно. Но! Самое главное из осознаного стало то, что где винда всячески препятствовал чего-то поменять или прочитать, то в среде SAMBA это была не проблема. Можно загнать SAMBA контроллер в домен, затем среплицировать базу AD в SAMBA и дальше уже шаманить с ней без ограничений со стороны винды, а затем перелить ее в виндовую машину… не знаю, поможет или нет, но есть в SAMBA механизм для хранения информации о пользователях и, возможно, о группах в разного рода форматы.
Aivendil
05.09.2016 13:05Можно попробовать, но имхо проблема возникнет на шаге «загнать SAMBA контроллер в домен», так как в текущем домене, по сути, нет контроллера с которого можно было бы провести первую репликацию на новый SAMBA контроллер.
Но, в принципе, попробовать можно.phili_can
05.09.2016 13:30Если я ничего не напутал, то рекомендую поизучать вот эту команду в SAMBA.
samba-tool domain exportkeytabAivendil
05.09.2016 13:42Изучал. Собственно, Windows аналог этой процедуры через команду ktpass упоминается в статье. SAMBA контроллер получится ввести в домен, как и Windows сервер, но при инициализации доменной репликации нужно установить шифрованное соединение для передачи AD данных.
Для нового Windows контроллера это точно не удается, по причине того, что вам не с кем его установить. У старого контроллера нет аккаунта в AD базе. Получается, что есть только одна сторона защищенного канала — принимающая, но нет передающей. И репликация фейлится.
Для Linux контроллера нужно попробовать, но, имхо, проблема будет такая же. Keytab файл на новой машине позволит создать принимающую сторону канала для репликации, но передающей-то, по прежнему, не будет.
phili_can
05.09.2016 13:51Кстати, вопрос на засыпку, а что если снова запустить in-place upgrade? Может оно завершит начатое дело?)
Aivendil
05.09.2016 15:27Пробовал. Не без шаманства, но можно заставить завершить. Оно завершает начатый апгрейд. Но, самом собой, компьютерный пароль, который уже затёрт оно не восстанавливает. Т.е. можно вместо сломанного Windows Server 2003 контроллера получить соманный Windows Server 2008 контроллер.
(IFM снапшот сделать не получится после прехода на Windows Server 2008. Тоже пробовал.)
gotch
05.09.2016 15:34+1Я отработал ваш сценарий в виртуалке. Получилось и сломать, и починить.
Больной DC — DC1
1. Переименовать в AD DC1 в DC11
2. Cоздать сервер в рабочей группе с именем DC1 (логин и пароль локального администратора идентичны AD). Прописать его в hosts на настоящем контроллере домена. На момент запуска netdom он должен работать.
3. Оставить на контроллере домена службу KDC
4. На контроллере домена выполнить netdom resetpwd /computer:DC11
5. Переименовать в AD обратно DC11 в DC1
6. Перезагрузить контроллер домена
7. PROFIT.
Попробуйте.gotch
05.09.2016 16:01+1Поправка:
2. Cоздать сервер в рабочей группе с именем DC11Aivendil
05.09.2016 16:38Сейчас попробую. Прописать в hosts с каким именем?
Т.е. у меня получаются:
DC11 (переименованный DC1) со старым адресом
DC11 (новый сервер в рабочей группе) с новым адресом
Какая запись нужна в Hosts на переименованном DC1?
Кстати, выше написал, что запуск netdom из под SYSTEM со включенной KDC мне тоже помог.gotch
05.09.2016 16:51Делал так —
Поддельный сервер DC11 192.168.1.2
Настоящий сервер — DC1 192.168.1.1 — на нем мы ничего с самой учетной записью и адресами не делаем, только правим имя в LDAP (AD). Для простоты, чтобы не заморачиваться с DNS, на DC1 в hosts пишем
192.168.1.2 dc11
192.168.1.2 dc11.test.local
Но честно говоря, каким-то грязным шаманством это отдает и я несколько начинаю сомневаться в сакральном смысле этой манипуляции.
Я протестировал несколько раз вашу ошибку на воспроизводимость, и пришел к неприятному выводу. Если сломать сервер по вашему сценарию — испортив локальный пароль утилитой MachinePWD, то действительно при загрузке сервер сыпет в SYSTEM ошибками «Указано неверное имя пользователя или другие неверные личные данные». При этом от SYSTEM прекращает запускаться тот же ADUC с той же ошибкой (обычно он работает, конечно же).
Но в таком виде он несколько раз уже вернулся в нормальный вид просто остановкой KDC и запуском netdom resetpwd без шаманства. Поэтому ваш сервер сломан более уникальным образом.
rtzra
05.09.2016 20:45Говорите, не менее 2 DC вам подавай? :-)
Мне пару месяцев назад досталось хозяйство: обычная десктоповая машинка, i3, 16 Гб памяти и 4 HDD. На ней крутился 2012 в ролях: контроллер домена, 1С в файловом варианте, терминальный сервер, сервер антивируса, пользовательские документы и куча всякого софта вроде криптопро и иже с ним. Судя по остаточным следам 2 или 3 раза на этом «сервере» резвились шифровальщики. Пользователи были крайне недовольны скоростью работы (ну еще бы). Пару раз в день этот «космолет» перезагружался (иногда, как я понял тупо кнопкой) чтобы вообще можно было что-то поделать.
При всем при этом в гараже валялось два сервера — один НР, второй Supermicro. «Но нафиг они нужны, они же ревут как ненормальные» — как вы понимаете, кондиционеров там тоже не было.
Впрочем, я думаю каждый способен привести не одну подобную историю.
whiplash
08.09.2016 17:45— был в ней всего один контроллер домена с установленной на нём Windows Server 2003.
— поэтому на этом же сервере было установлено довольно большое количество приложений.
— резервных копий в этой компании никогда не делалось.
— конечно — in-place upgrade!
У меня прям лицо фейспалмами покрылось.
Это даже не то, что стрелять себе в ногу. Это поставить на ногу канистру с бензином, привязать пехотную мину, поставить капкан, и уже потом — выстрелить.Aivendil
08.09.2016 23:42Да, я тоже был очень удивлён. Я нервничаю даже если небольшое изменение со сложными путями отката провожу. А тут, просто без пути назад начать апгрейд ДЦ… Это очень странно:)
YourChief
А Вы не пробовали брутфорсить NTLM-хэш на GPGPU? Шансы должны быть неплохие. Если у вас есть хэш, можете кинуть в личку.
mxms
Вот именно. Если пароль не слишком сложный то при нынешних процессорах он ломается за разумное время.
YourChief
Да даже если слишком сложный, есть шанс нахождения более простой коллизии. Точно не помню, но по-моему кроме прочего у NTLM была проблема, связанная с паролями длиннее 8 символов.
YourChief
А, нашёл, там же дикая дичь.
mxms
Да, я этим баловался ещё в году эдак 2000 :-)
xforce
LM и NTLM разные вещи. В NTLM такой дичи нет.
Aivendil
Честно говоря, я не знаю сколько символов ставит система в компьютерные пароли, но уверен, что больше 8. Надо включить обратимое шифрование и посмотреть.
YourChief
Ну, например, на Nvidia GTX970 хэши NTLM для паролей из всех печатаемых символов длиной до 7 знаков перебираются за 1 час (скорость хэширования 18GH/s). Вероятно, можно сузить диапазон символов, вряд ли там прямо все используются.
Если есть ещё и простой LM-хэш, то тогда вообще за 40 минут можно подобрать.
А может и с радужными таблицами повезти — есть несколько сервисов, которые позволяют проверить хэш по базе.
Aivendil
Думается мне что система вс-таки генерирует пароли длиннее 7 символов. А там ведь не линейный рост сложности задачи. Т.е. если в пароле будет хотя бы 14 знаков, то время перебора будет ого-го. Грубо говоря, если бы хеши в Active Directory так легко ломались, то все бы этим пользовались. И буквами качестве символов она тоже вряд ли ограничивается.
Но да, я уже решил, как появится время, включить обратимое шифрование и посмотреть что же там бывает в качестве пароля, чтобы посмотреть каковы шансы его пробрутить.
YourChief
Хэши в AD так легко ломаются и все этим опользовались уже не раз :)