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

    Всегда приятно вспомнить как удалось решить какую-нибудь нетривиальную задачу. Но бывает и наоборот. Задача была вроде понятна, но вот решить её не удалось. Ниже я расскажу грустную историю из моей практики. Грустная она потому, что я, до сих пор, не знаю, как решить ту проблему. История, в очередной раз, напомнит как важно уделять должное внимание резервному копированию и тщательному обдумыванию своих действий. Ну а если кто-то из читателей расскажет мне, что можно было сделать, чтобы добиться лучшего результата, то это будет просто замечательно.

    image

    Итак, жил-был системный администратор и был у него 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 без шаманства. К сожалению, я не смог найти у себя оригинальный образ сервера для продолжения экспериментов. Получилось очень обидно.
    Поделиться публикацией
    Ой, у вас баннер убежал!

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                (IFM снапшот сделать не получится после прехода на Windows Server 2008. Тоже пробовал.)
                                              • +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.

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

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

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

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

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

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое