Ще раз про користь резервних копій або історія про мою невдачу

Завжди приємно згадати як вдалося вирішити яку-небудь нетривіальну задачу. Але буває і навпаки. Завдання було начебто зрозуміла, але вирішити її не вдалося. Нижче я розповім сумну історію з моєї практики. Сумна вона тому, що я досі не знаю, як вирішити ту проблему. Історія вкотре нагадає як важливо приділяти належну увагу резервного копіювання та ретельного обмірковування своїх дій. Ну а якщо хтось з читачів розповість мені, що можна було зробити, щоб досягти кращого результату, то це буде просто чудово.

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. Якщо ви знаєте спосіб в такій ситуації полагодити зв'язок між контролером і доменом, то поділіться ним, будь ласка, з аудиторією. Ваш подвиг не буде забутий!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.