Как стать автором
Обновить

Еще раз о пользе резервных копий или история о моей неудаче

Время на прочтение7 мин
Количество просмотров35K
Всего голосов 33: ↑28 и ↓5+23
Комментарии71

Комментарии 71

А Вы не пробовали брутфорсить NTLM-хэш на GPGPU? Шансы должны быть неплохие. Если у вас есть хэш, можете кинуть в личку.
Вот именно. Если пароль не слишком сложный то при нынешних процессорах он ломается за разумное время.
Да даже если слишком сложный, есть шанс нахождения более простой коллизии. Точно не помню, но по-моему кроме прочего у NTLM была проблема, связанная с паролями длиннее 8 символов.
Да, я этим баловался ещё в году эдак 2000 :-)
LM и NTLM разные вещи. В NTLM такой дичи нет.
Честно говоря, я не знаю сколько символов ставит система в компьютерные пароли, но уверен, что больше 8. Надо включить обратимое шифрование и посмотреть.
Ну, например, на Nvidia GTX970 хэши NTLM для паролей из всех печатаемых символов длиной до 7 знаков перебираются за 1 час (скорость хэширования 18GH/s). Вероятно, можно сузить диапазон символов, вряд ли там прямо все используются.

Если есть ещё и простой LM-хэш, то тогда вообще за 40 минут можно подобрать.

А может и с радужными таблицами повезти — есть несколько сервисов, которые позволяют проверить хэш по базе.
Думается мне что система вс-таки генерирует пароли длиннее 7 символов. А там ведь не линейный рост сложности задачи. Т.е. если в пароле будет хотя бы 14 знаков, то время перебора будет ого-го. Грубо говоря, если бы хеши в Active Directory так легко ломались, то все бы этим пользовались. И буквами качестве символов она тоже вряд ли ограничивается.

Но да, я уже решил, как появится время, включить обратимое шифрование и посмотреть что же там бывает в качестве пароля, чтобы посмотреть каковы шансы его пробрутить.
  1. Если в пароле будет 14 знаков, то это в общем случае не является гарантией того, что не существует более короткой коллизии.
  2. Если где-либо сохранён хэш LM, то его можно ломать порциями по 7 символов.


Грубо говоря, если бы хеши в Active Directory так легко ломались, то все бы этим пользовались.

Хэши в AD так легко ломаются и все этим опользовались уже не раз :)
НЛО прилетело и опубликовало эту надпись здесь
Ну да. Логично. Собственно, когда он понял, что возникла проблема он ведь нашёл ресурсы на дополнительный сервер. Я не мог понять как он этого не сделал ДО этого. Ну и начать in-place upgrade не сделав элементарного бекапа это…
как-то решал я одну проблему с АД (2008R2), уже не помню что я за команду ввел(запустил утилиту), но команда была от 2000 домена, и привело это к проблеме с правами на каталог SYSVOL на всех контроллерах, короче домен помер. Мораль: наличие нескольких контроллеров может не спасти ваш домен от вас).

Дело было в воскресение, и я быстро восстановил домен контроллеры из резервных копий (3 шт).
Некоторые консерваторы могут закидать меня яйцами =) но все домен контроллеры я разворачивал виртуальными, и это позволило мне за час восстановить работу домена. В последствии я еще переустановил роль AD на всех все RODC контроллерах.

По поводу отсутствия денег:
1 — если поставить на весы 800 уе за лицензию и деятельность предприятия, что выиграет?
2 — бу сервера сейчас продают от 500 уе за 4 ядра 24гб памяти (ддр3)…
Тут сильно зависит от директора. Ну вот не даёт он например денег на лицензию — не из своих же её покупать?

А вы правильно говорите — даже самые страшные косяки не так печалят, если есть резервная копия. И вот тут уже цена вопроса сейчас просто смешная. Два 500ГБ винчестера (для надежности) стоят 5к рублей. А резервных копий контроллера там можно на полгода ежедневных бекапов хранить.
Разговор про полные копии АД:

Хранить резервные копии КД более месяца бессмысленно, пароли на учетную запись компьютеров меняются раз в 30 дней.
Поднимаете резервную копию КД месячной давности, и получаете проблему, что все ПК не имеют доверительных отношений с доменом :) перевводить всех то еще удовольствие.

Если КД больше одного, то КД должен знать (т.е. средство резервного копирования должно сообщать КД что оно было разбэкаплено) иначе выхватите USN Rollback. Начиная с Windows Server 2012 эту проблему победили, на предидущих же системах, требуется наличие обновления KB875495, а так же поддержка со стороны системы резервного копирования, если использовался не встроенный виндовый бэкап.

Итого не более недели.

Есть Exchange и/или Sharepoint? Тогда вам нужен одномоментный бэкап АД и ексчейнджа и шарепоинта. Нетривиальная задача, требующая недешевого железа и софта для своего работы.

Итого-итого — смысла в полном бэкапе более суток почти нет.

Однако если вести разговор об отдельных объектах, то можно и по полгода хранить.
В моей фразе о возможности хранить хоть «полгода ежедневных бекапов» основной смысл был в том, что в нынешнюю эру дешевых носителей информации я не могу понять как можно совсем не делать резервных копий.

Полный бекап длительного срока хранения обычно используют когда на это есть юридические причины. Технически, действительно, не особо полезно.
Зачем тогда работать на такое предприятие предоставлять сервис который не в состоянии поддерживать?
Ну вот, допустим, наняли студента начинающего. Он даже не понимает еще в чем риски такого решения. И не понимает что значит «не в состоянии поддерживать». А потом когда поймет, то идет к начальству за деньгами на лицензию, а ему их не дают. А так как он не является материально ответственным, то он и думает — «ну и фиг с вами». И продолжает работать за свою зарплату.
Ну значит виноваты те кто его вообще подпустил к домену.
Работать с единственным DC — это как ездить на одном колесе на велосипеде вместо двух положенных :) можно но не долго.
Ну да. Но в данном случае вопрос «кто виноват?» меня не очень интересовал. А вот «что делать?» было любопытно.
а сколько людей в конторе, там вообще домен нужен?
~150 человек. Полтора десятка серваков.
однозначно можно было поднять роль хоть одного до второго DC
Нужно! И сделать бекап перед апгрейдом. Но, как известно, админы делятся на тех кто уже делает бекапы и тех кто еще не делает (с).
=) готов поспорить что серваки не нагружены и больше половины физических серваков можно убрать )
Сразу после того, как in-place upgrade завершился с ошибками, не было варианта откатиться на последнюю точку восстановления, или загрузившись с загрузочного диска, запустить установщик старой WIndows Server 2003 в режиме сохранения установленной Windows?
Нет. Точек восстановления системы не было.
Вы бы сделали перед «апгрейдом» резервную копию хотя бы системного диска? Это ж так глупо надеяться на «авось» в таком деле?
Заказчик пригласил нас на этапе «всё сломалось при in-place апгрейде, посмотрите почему не джойниться в домен новый сервер». А вот почему он перед in-place апгрейдом не сделал хотя бы одну резервную копию это, конечно загадка (я бы честно говоря её сделал еще перед подготовкой схемы к Widows Server 2008 контроллерам, там шансов на косяк меньше, но мало ли).
Извините, невнимательно прочитал вступление! Это ваше знакомство с ним так началось! Моя ошибка.
Сначала пишете, что не знаете, как решить эту проблему, а в конце статьи сами же честно пишете, как её не создавать.

Сам микрософт говорит в своих статьях, что абсолютный минимум серверов AD DC — два, в моей практике было использовать три, разделенных географически и два из них были виртуализованные (win2012 прекрасно знает о том, что ее могут виртуализовать, поэтому там нет типичных проблем предыдущих редакций). Главное — выключить синхронизацию времени на виртуализованном DC (точнее, эмуляторе PDC) от гипервизора.

Ну, и бекапы, конечно. В моей практике использовались бекапы SysCtr Data Protection Manager, основная из его проблем — все его бекапы имеют нечитаемую извне структуру, т.е. базы DPM и его самого надо бекапить чем-то иным и в другое место.
Всё честно. Я знаю как не создавать такую проблему и я не знаю как ей решить:)

Т.е. понятно, что до такого нельзя доводить, но мне до сих пор с профессиональной точки зрения любопытно — неужели ничего нельзя сделать?
Проблема, очевидно, в несовпадении хэшей паролей. Напрашивается решение или подобрать пароль с таким же хэшом, или поменять хэш и на проверяющей стороне.
Насколько я помню, поиск коллизии для этих хешей очень затратная задача. Грубо говоря, так можно было бы любой аккаунт в Active Directory взломать. Кто бы тогда вообще ее использовал? Все продукты, которые я находил, предлагали меняемое время поиска только при наличии входных данных (словарные пароли или точно известное число и тип символов), а компьютерный пароль генерируется системой. Т.е. он точно не словарный.

Но мне уже самому стало любопытно включить обратимое шифрование и посмотреть что там система, на самом деле, генерирует. Обязательно займусь на досуге.
В одном из комментариев выше я привёл Вам цифры: сколько времени нужно на взлом. Я не исключаю, что после осознания Вы смените профиль специализации :)
самое главное забыл — какие анальные кары последовали к тому админу?
он был на зарплате или сам по себе?
Админ, конечно, герой не очень умно подошел к делу, но — старшие-то товарищи?!

Напомню фразы из статьи:
...Active Directory домен. Так как инфраструктура была небольшой… то был в ней всего один контроллер домена с установленной на нём Windows Server 2003. Ресурсов сильно не хватало… на этом же сервере было установлено довольно большое количество приложений… резервных копий в этой компании никогда не делалось

решило техническое руководство, что пора переходить на более свежую версию Active Directory… Как перейти на более свежую версию Windows Server в своем домене, если у вас есть всего один контроллер, на котором стоит много дополнительного софта и для которого нет резервных копий? Конечно — in-place upgrade!


Ну прямо с самого начала понятно, куда все придет, и какой шанс просто не потерять ничего (напомню старую мудрость: «если все удастся, тебя даже не похвалят, а если не удастся, то виноват будешь именно ты»), но тех. рук-во «дало добро»! При этом зачем поднимать версию домена, и почему решено, изменение версии не потребует вложений в то же железо (точнее, их никто не планирует)?
Я бы попробовал сменить пароль контроллера домена напрямую в БД 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
Я бы сделал с помощью Disk2vhd копию текущего DC, поднял бы на витруалке у себя копию и поиздевался со сбросом пароля доменного администратора, а также многократным dcdiag /fix, ntdsutil — sema data ana и т.п., т.е. все работы не на рабочей железке.
Я сделал копию текущего DC в виртуальную среду. Более того, как я сказал, я нашел способ воспроизвести такую проблему вообще в чистой лабе. Т.е. простор для любых экспериментов имелся и имеется.

Пароль администратора у меня был рабочий. Проблема была именно с компьютерным паролем контроллера домена.
Опс. Не для всех это может быть очевидно. Про то, что все издевательства велись с виртуальной копией, наверное стоило упомянуть в статье?
Не упомянуты остались перезагрузки в «режим восстановления каталога» и попытки починиться через ntdsutil.

На сегодня развлечения продолжены, есть какие-то результаты?

Можете вывод >dcdiag /fix /verbose опубликовать для наглядности?
Издевательства велись и над живой машинкой и над клоном. Да. стоило об этом сказать. Подумал что это подразумевается, раз я предлагаю способ как сделать такую же лабу себе любому желающему.

В режиме восстановления каталога вы получаете возможность поработать с размонтированной NTDS базой. ЧТо вы предложили бы с ней сделать? резервных копий, на которые можно было бы в этом режиме откатиться нет.

Я играюсь с этой виртуалкой уже полгода в расслабленном режиме (понятно, что заказчику уже без разницы, но самому любопытно). Результатов нет:) Но сейчас я довольно сильно занят на работе, так что скорее собираю идеи «на попробовать», когда будет время.

Dcdiag успешно проходит все тесты, кроме Eventlog (потому что там ошибки связанные с загрузкой DNS зоны из AD базы)
Вот тут товарищи говорят, что с 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.
Эту статью я видел. Собственно, все эти способы я пробовал. Они сработают при наличии живого DC. Т.е. нужно выключить KDC на проблемном контроллере и netdom при сбросе пароля свяжется с этой службой на другом здоровом DC. Но здесь здорового DC не было.
Что произойдет, если не останавливать KDC, а сделать netdom resetpwd из под SYSTEM на DC?
Хм. Смешно, но помогло. Как полезно описать ситуацию на Хабре:)
С черным ящиком — играем без правил. )

Стоит добавить решение в статью.

Статья отличный сборник советов как делать с КД не нужно. Собраны все касяки эксплуатации КД. Сделано все что бы было попроще убить КД %)
этот единственный контроллер, по совместительству являлся и единственным DNS сервером

Вот так делать не нужно, точно. ПО от MS дорого, машины под контроллеры выделать жаль, и все такое — но один контроллер, который же один и DNS сервер на всех…

решило техническое руководство, что пора переходить на более свежую версию Active Directory

Вероятно, техническое руководство взяло на себя ответственность за такой дизайн, при котором (как у вас и получилось) при первом же чихе вы сами себе отрезали убили все?

Что помешало вам хотя бы поставить два сервера виртуализации, на них на каждом по виртуалке с контроллером, и эти виртуалки бекапить постоянно, чтобы потом, при необходимости, развернуть обе машины из бекапа? А уже потом ставить эксперименты? Если уже ваша компания созрела до домена, у и вас есть техническое руководство, потянуть вторую машину вы бы уж как-то могли…
Видимо, вы не очень внимательно читали. Нас туда позвали попытаться помочь починить на этапе, когда не получалось ввести новый сервер в домен. У нас, конечно, волосы дыбом встали от такой ситуации.
НЛО прилетело и опубликовало эту надпись здесь
Еще как вариант, можно попробовать добавить контроллер домена под SAMBA и посмотреть что получится.
Не совсем понял что вы имеете ввиду? Контроллер нормально доступен по сети (доменными аккаунтами). Чем поможет добавление его под SAMBA?
Не так давно был опыт перехода AD с Win на AltLinux. Было непривычно. Но! Самое главное из осознаного стало то, что где винда всячески препятствовал чего-то поменять или прочитать, то в среде SAMBA это была не проблема. Можно загнать SAMBA контроллер в домен, затем среплицировать базу AD в SAMBA и дальше уже шаманить с ней без ограничений со стороны винды, а затем перелить ее в виндовую машину… не знаю, поможет или нет, но есть в SAMBA механизм для хранения информации о пользователях и, возможно, о группах в разного рода форматы.
Можно попробовать, но имхо проблема возникнет на шаге «загнать SAMBA контроллер в домен», так как в текущем домене, по сути, нет контроллера с которого можно было бы провести первую репликацию на новый SAMBA контроллер.

Но, в принципе, попробовать можно.
Если я ничего не напутал, то рекомендую поизучать вот эту команду в SAMBA.
samba-tool domain exportkeytab
Изучал. Собственно, Windows аналог этой процедуры через команду ktpass упоминается в статье. SAMBA контроллер получится ввести в домен, как и Windows сервер, но при инициализации доменной репликации нужно установить шифрованное соединение для передачи AD данных.

Для нового Windows контроллера это точно не удается, по причине того, что вам не с кем его установить. У старого контроллера нет аккаунта в AD базе. Получается, что есть только одна сторона защищенного канала — принимающая, но нет передающей. И репликация фейлится.

Для Linux контроллера нужно попробовать, но, имхо, проблема будет такая же. Keytab файл на новой машине позволит создать принимающую сторону канала для репликации, но передающей-то, по прежнему, не будет.
Кстати, вопрос на засыпку, а что если снова запустить in-place upgrade? Может оно завершит начатое дело?)
Пробовал. Не без шаманства, но можно заставить завершить. Оно завершает начатый апгрейд. Но, самом собой, компьютерный пароль, который уже затёрт оно не восстанавливает. Т.е. можно вместо сломанного Windows Server 2003 контроллера получить соманный Windows Server 2008 контроллер.

(IFM снапшот сделать не получится после прехода на Windows Server 2008. Тоже пробовал.)
Я отработал ваш сценарий в виртуалке. Получилось и сломать, и починить.
Больной 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.

Попробуйте.
Поправка:
2. Cоздать сервер в рабочей группе с именем DC11
Сейчас попробую. Прописать в hosts с каким именем?

Т.е. у меня получаются:
DC11 (переименованный DC1) со старым адресом
DC11 (новый сервер в рабочей группе) с новым адресом

Какая запись нужна в Hosts на переименованном DC1?

Кстати, выше написал, что запуск netdom из под SYSTEM со включенной KDC мне тоже помог.
Делал так —
Поддельный сервер 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 без шаманства. Поэтому ваш сервер сломан более уникальным образом.
Грусть. Пойду искать где у меня его оригинальный образ.
Не зря участвовал в дискуссии. У коллег сломался единственный DC «в связи с утратой доверия».
Сразу netdom починился, без всякой романтики.
Жизнь приносит удивительные совпадения!:)
Говорите, не менее 2 DC вам подавай? :-)
Мне пару месяцев назад досталось хозяйство: обычная десктоповая машинка, i3, 16 Гб памяти и 4 HDD. На ней крутился 2012 в ролях: контроллер домена, 1С в файловом варианте, терминальный сервер, сервер антивируса, пользовательские документы и куча всякого софта вроде криптопро и иже с ним. Судя по остаточным следам 2 или 3 раза на этом «сервере» резвились шифровальщики. Пользователи были крайне недовольны скоростью работы (ну еще бы). Пару раз в день этот «космолет» перезагружался (иногда, как я понял тупо кнопкой) чтобы вообще можно было что-то поделать.
При всем при этом в гараже валялось два сервера — один НР, второй Supermicro. «Но нафиг они нужны, они же ревут как ненормальные» — как вы понимаете, кондиционеров там тоже не было.
Впрочем, я думаю каждый способен привести не одну подобную историю.
— был в ней всего один контроллер домена с установленной на нём Windows Server 2003.
— поэтому на этом же сервере было установлено довольно большое количество приложений.
— резервных копий в этой компании никогда не делалось.
— конечно — in-place upgrade!

У меня прям лицо фейспалмами покрылось.
Это даже не то, что стрелять себе в ногу. Это поставить на ногу канистру с бензином, привязать пехотную мину, поставить капкан, и уже потом — выстрелить.
Да, я тоже был очень удивлён. Я нервничаю даже если небольшое изменение со сложными путями отката провожу. А тут, просто без пути назад начать апгрейд ДЦ… Это очень странно:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации