Відновлення пошкодженого локального контролера домену

Коли контролер домену пошкоджується або його неправильно відновлюють, це викликає величезні проблеми: Вхід не вдається, об'єкти групової політики перестають застосовуватися, а реплікація переривається майже без жодних підказок.Гарна новина полягає в тому, що існують чіткі процедури відновлення фізичного або віртуального контролера домену за умови дотримання прийнятих методів резервного копіювання та відновлення.

У сучасних середовищах Windows Server відновлення контролера домену вимагає гарного розуміння таких концепцій, як стан системи, авторитетне/неавторитетне відновлення, відкати SYSVOL, DFSR/FRS та USNЯкщо ці проблеми вирішувати поспішно або за допомогою несумісних інструментів візуалізації, результатом може стати ліс, повний прихованих невідповідностей, які дуже важко діагностувати.

Чому важливо належним чином захистити та відновити контролер домену

Active Directory – це серце автентифікації та авторизації в домені Windows.Він зберігає користувачів, комп'ютери, групи, довірчі відносини, групові політики, сертифікати та інші критично важливі елементи. Ця інформація знаходиться переважно в базі даних. Ntds.dit, пов'язані файли журналів та папка SYSVOL, серед інших компонентів, що складають так званий «стан системи».

Стан системи включає, серед іншого, Файли журналів та дані Active Directory, реєстр Windows, системний том, SYSVOL, база даних сертифікатів (якщо існує центр сертифікації), метабаза IIS, файли завантаження та захищені компоненти операційної системиТому будь-яка серйозна стратегія забезпечення безперервності бізнесу повинна включати регулярне резервне копіювання стану системи кожного центру обробки даних.

Коли відбувається фактичне пошкодження бази даних Active Directory, серйозний збій реплікації або проблема з дозволи ввімкнено SYSVOLКонтролер домену може припинити обробку запитів, не запустити служби Active Directory або викликати каскадні помилки по всьому лісу. У цих випадках... Швидке та належне відновлення є вирішальним фактором між серйозним інцидентом та тривалою катастрофою..

Перш ніж намагатися відновити базу даних, важливо розрізняти справжню проблему з базою даних та більш буденні збої. Дуже часто, Причина криється в DNS, змінах у мережі, брандмауерах або маршрутах, змінених за допомогою таких інструментів, як команда netshТому бажано спочатку виключити ці фактори, перш ніж торкатися бази даних AD.

Базові засоби діагностики та контролю реплікації

У разі появи симптомів пошкодження або збоїв реплікації першим розумним кроком є ​​перевірка стану середовища за допомогою власних інструментів. DCDiag, Repadmin, ReplMon (у старіших версіях) та засіб перегляду подій Вони ваші найкращі союзники, перш ніж розглядати агресивні реставраційні процедури.

з DCDiag Виконується загальна перевірка всіх контролерів домену, з виявленням проблем з реплікацією, DNS, службами AD DS тощо. Репадмін Це дозволяє переглядати стан реплікації, партнерів реплікації, водяні знаки USN та виявляти постійні об'єкти. У старіших версіях Windows, ReplMon Він пропонував графічне представлення помилок реплікації в домені.

Окрім цих інструментів, важливо переглянути Переглядач подій на наявність розділів «Служби каталогів» та «Реплікація DFS». Такі події, як 467 та 1018, вказують на фактичне пошкодження бази даних., тоді як події 1113/1115/1114/1116 стосуються ввімкнення або вимкнення реплікації вводу/виводу.

Якщо підозрілий контролер домену потрібно тимчасово ізолювати, щоб запобігти поширенню пошкоджень, ми можемо Вимкнення вхідної та вихідної реплікації за допомогою Repadmin:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

А щоб відновити нормальну реплікацію, просто видаліть ці параметри:

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Підтримувані резервні копії стану системи на контролерах домену

Щоб мати можливість відновити контролер домену з гарантіями, важливо мати Резервні копії стану системи, виконані за допомогою інструментів, сумісних з Active DirectoryЦі інструменти використовують API резервного копіювання та відновлення Microsoft і службу тіньового копіювання томів (VSS) у підтримуваний спосіб.

Серед найпоширеніших рішень є Резервне копіювання Windows Server, сторонні рішення, інтегровані з VSS (такі як NAKIVO, Backup Exec та інші)або старіші утиліти, такі як Ntbackup у Windows 2000/2003. У всіх випадках вони повинні дотримуватися API AD, щоб забезпечити узгодженість бази даних та її реплік після відновлення.

Windows Server 2012 та пізніші версії мають важливе нове доповнення: Ідентифікатор покоління Hyper-V (GenID)Цей ідентифікатор дозволяє віртуальному контролеру домену виявити, що його диск було відкочено до попереднього моменту часу. Коли це відбувається, Служба AD DS генерує новий ідентифікатор виклику (InvocationID) та обробляє ситуацію так, ніби її було відновлено з успішного резервного копіювання.повідомляючи своїх партнерів з реплікації, тим самим забезпечуючи безпечне перезаписування без необхідності відкату USN.

Важливо поважати тривалість життя надгробкаЦе вказує на те, як довго можна використовувати резервну копію стану системи без ризику повторного введення об'єктів, видалених давно. Зазвичай у сучасних версіях це 180 днів, і рекомендується виконувати резервне копіювання принаймні кожні 90 днів, щоб забезпечити достатній запас міцності.

Несанкціоновані методи, що призводять до сторнування USN

Однією з найнебезпечніших причин мовчазних невідповідностей в Active Directory є Відкат USNТака ситуація виникає, коли вміст бази даних AD відкочується за допомогою непідтримуваного методу, без відновлення InvocationID або повідомлення партнерів з реплікації.

Типовий сценарій — завантаження контролера домену з образ диска або знімок віртуальної машини, зроблений ранішебез використання сумісного відновлення системи. Або скопіюйте файл Ntds.dit безпосередньо, скористайтеся програмами для створення образів, такими як Ghost, завантажтеся з пошкодженого дзеркала диска або повторно застосуйте знімок сховища на рівні масиву.

У цих випадках контролер домену продовжує використовувати той самий InvocationID, що й раніше, але його Місцевий лічильник USN працює у зворотному напрямкуІнші контролери домену пам'ятають про отримання змін аж до високого USN, тому, коли повернутий контролер домену намагається надіслати назад уже розпізнані USN, Їхні партнери вважають, що вони йдуть в ногу з часом і перестають приймати конкретні зміни.

В результаті цього певні модифікації (наприклад, створення користувача, зміна пароля, реєстрація пристрою, зміни членства в групах, нові записи DNSЦі помилки ніколи не реплікуються з відновленого контролера домену на решту мережі, але засоби моніторингу можуть не показувати явних помилок. Це надзвичайно небезпечний тихий збій.

Щоб виявити ці ситуації, драйвери Windows Server 2003 SP1 та пізніших версій реєструють Подія служб каталогів 2095 Коли виявляється, що віддалений контролер домену надсилає вже підтверджені USN без зміни InvocationID, система Він переміщує уражений контролер домену в карантин, призупиняє Netlogon і запобігає подальшим змінам. які не вдалося правильно відтворити.

Як додатковий судово-медичний доказ, це може для консультації в Реєстрі ключ HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters і значення DSA недоступний для записуЯкщо це значення встановлено (наприклад, 0x4), це вказує на те, що контролер домену був переведений у стан заборони запису шляхом виявлення реверсії USN. Ручна зміна цього значення для його "виправлення" абсолютно не підтримується. і залишає базу даних у постійно неузгодженому стані.

Загальні стратегії у разі пошкодження або повернення контролера домену до попередньої версії

Порядок дій у разі пошкодження або неправильного відновлення контролера домену залежить від кількох факторів: Кількість контролерів домену в домені/лісі, наявність дійсних копій стану системи, наявність інших ролей (FSMO, CA, глобальний каталог) та часовий масштаб проблеми..

Якщо в домені є інші справні контролери домену та Немає унікальних критичних даних про пошкоджений контролер домену.Найшвидший і найчистіший варіант зазвичай полягає у видаленні цього контролера домену та його перебудові. Однак, якщо це єдиний контролер домену або якщо на ньому розміщено конфіденційні ролі та дані, знадобиться більш ретельне відновлення (авторитетне чи неавторитетне).

Загалом, варіанти такі:

• Примусово понизити рівень пошкодженого контролера домену та видалити його з домену, а потім очищення метаданих та, якщо можливо, нове підвищення.
• Відновлення з дійсної резервної копії стану системи, незалежно від того, чи в авторитетному, чи в неавторитетному режимі.
• Перезбірка контролера домену з іншого за допомогою IFM (встановлення з носія), коли немає останньої копії, але є інші правильні контролери домену.
• Використання знімка віртуального жорсткого диска (VHD) віртуального контролера домену (DC), застосувавши додаткові кроки для позначення бази даних як відновленої з резервної копії (База даних відновлена ​​з резервної копії = 1) та переконавшись, що згенеровано новий InvocationID.

Якщо є явна підозра на відкат USN (наприклад, після відновлення віртуальної машини зі знімка без дотримання рекомендацій) і з'являється подія 2095, найрозумнішим варіантом дій зазвичай є Вимкніть цей контролер домену з експлуатації та не намагайтеся «виправити» його на місці., якщо тільки не можливо повернутися до резервної копії підтримуваного стану системи, створеної до відкату.

Примусове зниження статусу та очищення метаданих

Коли контролер домену настільки пошкоджений, що його неможливо понизити нормальним чином, або його було неправильно відновлено, і ви хочете запобігти поширенню проблем, ви можете вдатися до примусове пониження у посаді.

У старіших версіях ця операція виконувалася за допомогою dcpromo /forceremoval, що Видаліть роль AD DS, не намагаючись відтворити зміни на решту лісу.У сучасних середовищах майстер змінився, але концепція залишилася незмінною: видалити проблемний контролер домену з топології AD без його участі в подальшій реплікації.

Після примусового зниження версії обов'язково виконати команду з працездатного контролера домену. очищення метаданих за допомогою інструменту NtdsutilЦей процес видаляє всі посилання на видалений контролер домену (об'єкти налаштувань NTDS, посилання DNS тощо) з бази даних AD, щоб не залишається жодних "примарних" залишків, які б могли заплутати реплікацію.

Якщо деградований контролер мав ролі FSMO (емулятор PDC, головний RID, головний контролер схеми тощо), необхідно буде передає або захоплює ці ролі на інший контролер домену до або після зниження статусу, залежно від ситуації. Пізніше операційну систему можна перевстановити на цьому сервері, і його можна буде підвищити назад до чистого контролера домену.

Неавторитетне та авторитетне відновлення в Active Directory

Коли доступна дійсна копія стану системи, відновлення AD можна виконати двома способами: неавторитетний та авторитетнийРозуміння різниці є ключем до того, щоб не пропустити нещодавні зміни або не відтворити застарілі дані.

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

в авторитарна реставраціяОднак прямо зазначено, що Відновлені дані мають переважати. порівняно з тим, що мають інші контролери домену. Це означає, що після відновлення відновлені об'єкти матимуть вищий номер версії, щоб примусово реплікувати їх з цього контролера домену на решту домену. Це відповідний вибір, коли Ми випадково видалили об'єкти чи організаційні підрозділи, або ж хочемо повернути вміст SYSVOL та GPO до попереднього стану та реплікувати його..

Важливою деталлю є те, що примусове відновлення не обов'язково має бути для всієї бази даних. За допомогою утиліти Ntdsutil Окремі об'єкти, піддерева (наприклад, організаційний підрозділ) або весь домен можна позначити як авторитетні. Це забезпечує значну гнучкість, наприклад, для отримати лише користувача, групу, організаційний підрозділ або піддерево dc=mycompany,dc=local.

Загальна процедура відновлення стану системи на контролері домену

Базова схема відновлення системного стану контролера домену (фізичного чи віртуального) за допомогою сумісних інструментів завжди схожа: Завантажтеся в режим відновлення служб каталогів (DSRM), відновіть за допомогою засобу резервного копіювання та перезавантажте систему..

Коротко кажучи, типові кроки для віртуального контролера домену будуть такими:

1. Запустіть віртуальну машину в диспетчері завантаження Windows (зазвичай натисканням F5/F8 під час запуску). Якщо віртуальна машина керується гіпервізором, може знадобитися призупинити роботу машини, щоб зафіксувати натискання клавіші.
2. У розширених параметрах завантаження виберіть Режим відновлення служб каталогів (Режим відновлення служб каталогів). У цьому режимі сервер запускається без монтування бази даних Active Directory у функціональний спосіб.
3. Увійдіть, використовуючи обліковий запис адміністратора DSRM визначено під час початкового підвищення рівня контролера домену (не зі стандартним обліковим записом адміністратора домену).
4. Запустіть засіб резервного копіювання використану програму (архівування Windows Server, NAKIVO або іншу сумісну) та виберіть відновлення стану системи до потрібної точки резервного копіювання.
5. Завершіть роботу майстра відновлення та Перезапустіть контролер постійного струму в звичайному режиміПід час неавторитетного відновлення сервер ініціює реплікацію, щоб наздогнати інші контролери домену.

Коли ми говоримо про сторонні продукти резервного копіювання, такі як Резервне копіювання та реплікація NAKIVOЙого режим "підтримки програм" здатний розпізнати, що машина, яку відновлюють, є контролером домену, і автоматично налаштовувати процес для збереження узгодженості ADУ більшості випадків з кількома контролерами достатньо повного відновлення в неавторитивному режимі.

Авторитетне відновлення за допомогою Ntdsutil

Якщо ви хочете, щоб зміни на відновленому контролері домену мали пріоритет над рештою, вам потрібно додати додатковий крок після неавторитетного відновлення: використовувати Ntdsutil для позначення об'єктів як авторитетних.

Спрощений потік буде таким:

1. Відновіть стан системи стандартним способом і залиште сервер увімкненим Режим DSRM (Поки що не перезавантажуйте у звичайному режимі).
2. Відкрито командний рядок із підвищеними привілеями і біжи ntdsutil.
3. Активуйте екземпляр AD за допомогою активувати екземпляр ntds.
4. Входження в контекст авторитетного відновлення з авторитетне відновлення.
5. Використовуйте такі команди, як restore object <DN_objeto> o restore subtree <DN_subarbol>, де DN – це відмінне ім'я об'єкта або піддерева, яке потрібно відновити авторитетно.
6. Підтвердіть транзакцію та, після її завершення, Перезапустіть контролер постійного струму в звичайному режимі щоб позначені об'єкти реплікувалися з пріоритетом для решти домену.

Такий вид реставрації вимагає великої обережності. Якщо весь домен авторитетно відновлено, а резервна копія стараІснує ризик втратити законні зміни, внесені після резервного копіювання (наприклад, створення користувача, зміна пароля або модифікація групи). Тому поширеною практикою є обмеження авторитетного відновлення лише суворо необхідними об'єктами або деревами.

Відновлення SYSVOL (FRS проти DFSR)

SYSVOL є ключовим компонентом контролера домену: Він зберігає сценарії запуску, групові політики, шаблони безпеки та інші важливі спільні ресурси.Помилка у ваших правах доступу, пошкодження файлів або проблеми з реплікацією можуть зробити об'єкти групової політики непридатними для використання або спричинити нестабільну поведінку клієнтів.

Залежно від версії Windows Server та стану міграції, SYSVOL може бути реплікований FRS (Служба реплікації файлів) або для DFSR (Реплікація розподіленої файлової системи)Процедура примусового відновлення SYSVOL залежить від того, який з двох використовується.

Щоб визначити це, можна перевірити ключ у реєстрі. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Міграція Sysvols\LocalStateЯкщо цей підрозділ існує, а його значення дорівнює 3 (ВИДАЛЕНО), використовується DFSR. Якщо ж його немає або його значення відрізняється, ми маємо справу з середовищем, яке все ще використовує FRS.

У середовищах із FRS, примусове відновлення SYSVOL зазвичай передбачає коригування значення Бурфлаги en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process на певне значення (наприклад, 212 десяткове / 0xD4 шістнадцяткове), щоб вказати, що цей контролер домену є авторитетним джерелом.

Якщо SYSVOL реплікується за допомогою DFSR, процес дещо складніший: він включає використання ADSIРедагувати змінювати об'єкти підписки SYSVOL (атрибути msDFSR-Увімкнено y msDFSR-Параметри) на авторитетному контролері домену та на інших, примусово виконати реплікацію AD, виконати dfsrdiag pollad та підтвердіть у журналі подій появу події 4114, 4602, 4614 та 4604 що засвідчують, що SYSVOL було ініціалізовано та репліковано правильно.

Відновлення віртуальних контролерів домену з VHD

У віртуалізованих середовищах дуже поширене явище VHD/VHDX-файли контролерів доменуЯкщо у вас немає резервної копії стану системи, але є робочий "старий" віртуальний жорсткий диск, ви можете змонтувати новий контролер домену з цього диска, хоча робити це слід дуже обережно, щоб уникнути відкату USN.

Рекомендація така Не запускайте цю віртуальну машину безпосередньо у звичайному режиміЗамість цього, вам слід завантажитися з попереднього віртуального жорсткого диска в DSRMВідкрийте редактор реєстру та перейдіть до HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersТам бажано перевірити значення Кількість попередніх реставрацій DSA (якщо він існує) і, перш за все, створіть нове значення DWORD (32-бітне) під назвою База даних відновлена ​​з резервної копії зі значенням 1.

Вибравши це значення, Active Directory отримує повідомлення про те, що базу даних було відновлено з резервної копії, що примусово генерація нового InvocationID під час завантаження у звичайному режиміТаким чином, інші контролери домену інтерпретують його як новий екземпляр і правильно налаштовують свої водяні знаки реплікації, запобігаючи відкату USN.

Після перезапуску контролера домену у звичайному режимі рекомендується перевірити засіб перегляду подій, зокрема журнал Служби каталогів, шукаючи Подія 1109Ця подія підтверджує зміну атрибута InvocationID сервера та відображає старе та нове значення, а також найвищий USN на момент резервного копіювання. Крім того, значення Кількість попередніх реставрацій DSA Його слід було збільшити на одиницю.

Якщо ці події не відображаються або їх кількість не збільшується, слід перевірити версії операційної системи та пакети оновлень, оскільки Певні методи відновлення залежать від конкретних латокУ будь-якому випадку, завжди бажано працювати над копією оригінального VHD, зберігаючи недоторкану версію на випадок, якщо процес потрібно буде повторити.

Практичні сценарії та додаткові рекомендації

На практиці проблеми корупції або неправильного відновлення часто виникають у повсякденних ситуаціях: Ручні зміни дозволів у SYSVOL, спроби оновлення шаблонів ADMX/ADML, зміни об'єктів групової політики, які не реплікуютьсятощо. Досить легко спричинити невідповідності, якщо спільні папки змінюються вручну, наприклад SYSVOL\Policies без дотримання реплікації.

У разі пошкодження реплікації основного контролера домену (як даних AD, так і SYSVOL) та появи повідомлень моніторингу типу «Базу даних було відновлено за допомогою непідтримуваної процедури. Можлива причина: відкат USN.«розумно зробити таке:

• Перевірити з dcdiag y repadmin обсяг помилок та наявність «постійних об’єктів».
• Перевірте подію 2095 та її значення DSA недоступний для запису у Реєстрі.
• Оцініть, чи це можливо видаліть цей DC та перебудуйте його (Якщо є три або більше інших справних контролерів домену, це зазвичай найкращий варіант).
• Якщо це єдиний DC або критик, підніміть відновлення стану системи із сумісної резервної копії, в ідеалі нещодавньої та в межах періоду дії надгробного каменя.

У доменах з кількома контролерами наполегливо рекомендується, щоб контролери домену були максимально "чистими": без додаткових ролей або локальних даних користувачівТаким чином, якщо один виходить з ладу або пошкоджується, новий можна відформатувати та підвищити його статус на основі іншого контролера домену або через IFM, що значно зменшує складність відновлення.

Крім того, варто пам'ятати про такі обмеження, як Копії стану системи дійсні лише протягом періоду надгробків. (60, 90, 180 днів залежно від конфігурації), щоб уникнути відновлення видалених об'єктів, а також щоб ключі машини NTLM змінювалися кожні 7 днів. У дуже старих відновленнях може знадобитися скинути облікові записи команди проблеми з «Користувачі та комп’ютери Active Directory» або навіть їх видалення та повторне приєднання до домену.

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