Възстановяване и възстановяване на повреден локален домейн контролер

Когато домейн контролер се повреди или бъде възстановен неправилно, страхът е огромен: Влизанията се провалят, GPO-тата спират да се прилагат и репликацията се прекъсва почти без никакви улики.Добрата новина е, че има ясни процедури за възстановяване на физически или виртуален домейн контролер, при условие че се спазват приетите методи за архивиране и възстановяване.

В съвременните среди на Windows Server, възстановяването на домейн контролер изисква добро разбиране на концепции като състояние на системата, авторитетно/неавторитетно възстановяване, SYSVOL, DFSR/FRS и USN възстановяване на предишни версииАко тези проблеми се решат прибързано или с несъвместими инструменти за изображения, резултатът може да бъде гора, пълна с тихи несъответствия, които са много трудни за диагностициране.

Защо е изключително важно правилно да се защити и възстанови домейн контролер

Active Directory е сърцето на удостоверяването и оторизацията в домейн на WindowsТой съхранява потребители, компютри, групи, доверителни взаимоотношения, групови политики, сертификати и други критични елементи. Тази информация се намира предимно в базата данни. Ntds.dit, свързаните лог файлове и папка SYSVOL, наред с други компоненти, които съставляват така нареченото „състояние на системата“.

Състоянието на системата включва, наред с други неща, Регистрационни файлове и данни на Active Directory, системният регистър на Windows, системният том, SYSVOL, базата данни със сертификати (ако съществува CA), метабазата на IIS, файловете за зареждане и защитените компоненти на операционната системаСледователно, всяка сериозна стратегия за осигуряване на непрекъснатост на бизнеса трябва да включва редовни резервни копия на системното състояние на всеки център за данни.

Когато възникне действително повреждане на базата данни на Active Directory, сериозна повреда при репликация или проблем с разрешения включени SYSVOLДомейн контролерът може да спре обработката на заявки, да не успее да стартира услугите на Active Directory или да предизвика каскадни грешки в цялата гора. В тези случаи, Бързото и правилно възстановяване прави разликата между сериозен инцидент и продължително бедствие..

Преди да се опитате да възстановите базата данни, е изключително важно да направите разлика между истински проблем с базата данни и по-обикновени повреди. Много често, Причината се крие в DNS, промени в мрежата, защитни стени или маршрути, модифицирани с инструменти като команда netshЕто защо е препоръчително първо да изключите тези фактори, преди да докоснете базата данни на AD.

Основни инструменти за диагностика и контрол на репликацията

В случай на симптоми на повреда или неуспехи при репликация, първата разумна стъпка е да се провери състоянието на средата, използвайки вградени инструменти. DCDiag, Repadmin, ReplMon (в по-стари версии) и Преглед на събития Те са вашите най-добри съюзници, преди да обмислите агресивни реставрации.

Con DCDiag Извършва се обща проверка на всички домейн контролери, като се идентифицират проблеми с репликацията, DNS, AD DS услугите и др. Репадмин Позволява ви да преглеждате състоянието на репликация, партньорите за репликация, водните знаци на USN и да откривате постоянни обекти. В по-стари версии на Windows, ReplMon Той предлагаше графичен изглед на грешките при репликация в домейна.

В допълнение към тези инструменти е важно да прегледате програмата за преглед на събития за „Directory Services“ и „DFS Replication“. Събития като 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. Във всички случаи те трябва да спазват AD API, за да осигурят съгласуваност на базата данни и нейните реплики след възстановяване.

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 моментна снимка на виртуален домейн контролер, като приложите допълнителните стъпки, за да маркирате базата данни като възстановена от резервно копие (База данни, възстановена от резервно копие = 1) и да се уверите, че е генериран нов InvocationID.

Ако има ясно съмнение за връщане към USN (например след възстановяване на виртуална машина от моментна снимка без спазване на най-добрите практики) и се появи събитие 2095, най-разумният начин на действие обикновено е да Извадете този контролер на доменното място от употреба и не се опитвайте да го „поправите“ на място., освен ако не е възможно да се върнете към резервно копие на поддържаното системно състояние, направено преди връщането към предишното състояние.

Принудително понижаване и почистване на метаданни

Когато домейн контролерът е толкова повреден, че не може да бъде понижен нормално или е бил неправилно възстановен и искате да предотвратите разпространението на проблеми, можете да прибегнете до принудително понижаване.

В по-старите версии тази операция се извършваше с dcpromo /forceremoval, Какво Премахнете ролята на AD DS, без да се опитвате да репликирате промените в останалата част от гората.В съвременните среди съветникът се е променил, но концепцията е същата: да се премахне проблемният домейн контролер от топологията на AD, без той да участва в по-нататъшна репликация.

След принудително понижаване на версията е задължително да се изпълни команда от работещ контролер на домейна. почистване на метаданни с помощта на инструмента NtdsutilТози процес премахва всички препратки към изтрития контролер на домейн (обекти на NTDS настройки, DNS препратки и др.) от базата данни на AD, така че не остават „призрачни“ остатъци, които да объркват репликацията.

Ако повреденият контролер е имал FSMO роли (PDC емулатор, RID Master, Schema Master и др.), ще е необходимо да прехвърля или заема тези роли към друг домейн контролер преди или след понижаването, в зависимост от ситуацията. По-късно операционната система може да бъде преинсталирана на този сървър и той може да бъде повишен обратно до чист домейн контролер.

Неавторитетно срещу авторитетно възстановяване в Active Directory

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

В един неавторитетно възстановяванеDC се връща в предишна точка, но след като стартира, Другите домейн контролери се считат за референтниС други думи, след стартиране, възстановеният домейн контролер изисква входяща репликация и актуализира базата си данни с всички липсващи промени от другите домейни. Тази опция е идеална, когато Има и други здрави контролери и искаме възстановеният да ги настигне..

В един авторитарна реставрацияВъпреки това, изрично е посочено, че Възстановените данни са това, което трябва да преобладава. в сравнение с това, което имат другите домейнови контролери. Това означава, че след възстановяването възстановените обекти ще имат по-висок номер на версията, за да се наложи репликирането им от този домейн контролер към останалата част от домейна. Това е подходящият избор, когато Случайно сме изтрили обекти или организационни единици (OU) или искаме да върнем съдържанието на SYSVOL и GPO в предишно състояние и да го репликираме..

Важен детайл е, че авторитетното възстановяване не е задължително да бъде за цялата база данни. С помощта на помощната програма Ntdsutil Отделни обекти, поддървета (напр. OU) или целият домейн могат да бъдат маркирани като авторитетни. Това предлага значителна гъвкавост, например, извличане само на потребител, група, OU или поддървото dc=mycompany,dc=local.

Обща процедура за възстановяване на системното състояние на контролер на доменното пространство

Основната схема за възстановяване на системното състояние на домейн контролер (независимо дали е физически или виртуален) със съвместими инструменти винаги е подобна: Стартирайте в режим на възстановяване на директорийни услуги (DSRM), възстановете с помощта на инструмента за архивиране и рестартирайте.

В обобщение, типичните стъпки за виртуален домейн контролер биха били:

1. Стартирайте виртуалната машина в диспечера за зареждане на Windows (обикновено чрез натискане на F5/F8 по време на стартиране). Ако виртуалната машина се управлява от хипервизор, може да се наложи да поставите машината на пауза, за да се запише натискането на клавиша.
2. В разширените опции за зареждане изберете Режим на възстановяване на директорийни услуги (Режим на възстановяване на директорийни услуги). Този режим стартира сървъра без да монтира базата данни на Active Directory по функционален начин.
3. Влезте с администраторския акаунт на DSRM дефинирано по време на първоначалното популяризиране на контролера на домейна (не със стандартен акаунт на администратор на домейн).
4. Стартирайте инструмента за архивиране използван (Windows Server Backup, NAKIVO или друг съвместим) и изберете да възстановите състоянието на системата до желаната точка на архивиране.
5. Завършете съветника за възстановяване и Рестартирайте DC в нормален режимПри неавторитивно възстановяване, сървърът ще инициира репликация, за да настигне другите домейнови контролери.

Когато говорим за продукти за архивиране на трети страни, като например Архивиране и репликация на NAKIVOНеговият „приложен-зависим“ режим е способен да разпознае, че машината, която се възстановява, е контролер на домена и автоматично коригиране на процеса, за да се запази консистентността на ADВ повечето сценарии с множество контролери е достатъчно пълно възстановяване в неавторитивен режим.

Авторитетно възстановяване с Ntdsutil

Ако искате промените на възстановения домейн контролер да имат приоритет пред останалите, трябва да добавите допълнителна стъпка след неавторитивното възстановяване: използвайте Ntdsutil, за да маркирате обекти като авторитетни.

Опростеният поток би бил:

1. Възстановете състоянието на системата по стандартния начин и оставете сървъра все още включен DSRM режим (Не рестартирайте в нормален режим все още).
2. Отворете a команден ред с повишени привилегии и бягай ntdsutil.
3. Активирайте AD екземпляра с активиране на екземпляр ntds.
4. Влизане в контекста на авторитетното възстановяване с авторитетно възстановяване.
5. Използвайте команди като restore object <DN_objeto> o restore subtree <DN_subarbol>, където DN е отличителното име на обекта или поддървото, което ще бъде възстановено авторитетно.
6. Потвърдете транзакцията и след като я завършите, Рестартирайте DC в нормален режим така че маркираните обекти да се репликират с приоритет към останалата част от домейна.

Този вид реставрация изисква голямо внимание. Ако целият домейн е възстановен авторитетно и резервното копие е староСъществува риск от загуба на легитимни промени, направени след архивирането (например създаване на потребител, промяна на парола или промяна на група). Поради това е обичайна практика авторитетните възстановявания да се ограничават само до строго необходимите обекти или дървета.

Възстановяване и възстановяване на SYSVOL (FRS срещу DFSR)

SYSVOL е ключов компонент на домейн контролера: Той съхранява скриптове за стартиране, групови правила, шаблони за сигурност и други важни споделени ресурси.Грешка в разрешенията ви, повреда на файлове или проблеми с репликацията могат да направят GPO неизползваеми или да причинят нестабилно поведение в клиентите.

В зависимост от версията на Windows Server и състоянието на миграция, SYSVOL може да бъде репликиран от FRS (Услуга за репликация на файлове) или за DFSR (Репликация на разпределена файлова система)Процедурата за пълномощно възстановяване на SYSVOL варира в зависимост от това кой от двата се използва.

За да определите това, можете да проверите ключа в системния регистър. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateАко този подключ съществува и стойността му е 3 (ИЗТРИТ), се използва DFSR. Ако не съществува или стойността му е различна, имаме работа със среда, която все още използва FRS.

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

Ако SYSVOL се репликира от DFSR, процесът е малко по-сложен: той включва използването на ADSIРедактиране за промяна на обекти (атрибути) на абонамент за SYSVOL msDFSR-Enabled y msDFSR-Опции) на авторитетния домейн контролер и на останалите, принудително репликация на AD, изпълнение dfsrdiag полад и потвърдете в дневника на събитията появата на събития 4114, 4602, 4614 и 4604 които удостоверяват, че SYSVOL е инициализиран и репликиран правилно.

Възстановяване на виртуални домейн контролери от VHD

Във виртуализирани среди е много често срещано да има VHD/VHDX файлове на домейн контролериАко нямате резервно копие на системното състояние, но имате работещ „стар“ VHD, можете да монтирате нов контролер на домейна от този диск, въпреки че трябва да го направите много внимателно, за да избегнете връщане към USN.

Препоръката е Не стартирайте тази виртуална машина директно в нормален режимВместо това, трябва да стартирате от предишния VHD диск в DSRMОтворете редактора на системния регистър и отидете до HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersТам е препоръчително да проверите стойността Брой предишни DSA реставрации (ако съществува) и най-вече създайте нова DWORD (32-битова) стойност, наречена Базата данни е възстановена от резервно копие със стойност 1.

Чрез избиране на тази стойност, Active Directory получава съобщение, че базата данни е възстановена от резервно копие, което принуждава генериране на нов InvocationID при зареждане в нормален режимПо този начин другите домейнови контролери го интерпретират като нов екземпляр и правилно коригират своите водни знаци за репликация, предотвратявайки връщането на USN.

След рестартиране на контролера на домена в нормален режим, препоръчително е да проверите програмата за преглед на събития, по-специално лога на Директорийни услуги, търсейки събитие 1109Това събитие потвърждава, че атрибутът InvocationID на сървъра се е променил и показва старите и новите стойности, както и най-високия USN номер към момента на архивиране. Освен това, стойността на Брой предишни DSA реставрации Трябваше да се увеличи с едно.

Ако тези събития не се появят или броят им не се увеличи, трябва да проверите версиите на операционната система и сервизните пакети, тъй като Някои поведения за възстановяване зависят от специфични кръпкиВъв всеки случай, винаги е препоръчително да работите върху копие на оригиналния VHD, като запазите непокътната версия, в случай че процесът се наложи да се повтори.

Практически сценарии и допълнителни препоръки

На практика проблеми с корупция или неправилно възстановяване често се появяват в ежедневни сценарии: Ръчни промени в разрешенията в SYSVOL, опити за актуализиране на ADMX/ADML шаблони, промени в GPO, които не се репликирати т.н. Сравнително лесно е да се причинят несъответствия, ако споделените папки се променят ръчно, например SYSVOL\Policies без да се зачита репликацията.

В случай на основен домейн контролер с прекъсната репликация (както AD данни, така и SYSVOL) и съобщения за наблюдение от типа „Базата данни е възстановена с помощта на неподдържана процедура. Възможна причина: връщане към предишни версии на USN.„разумното нещо, което трябва да направите, е:

• Проверете с dcdiag y repadmin степента на грешките и дали има „постоянни обекти“.
• Проверете събитие 2095 и стойността му DSA не може да се записва в Регистъра.
• Преценете дали е възможно Премахнете този DC и го сглобете отново. (Ако има три или повече други здрави контролери на доменните линии, това обикновено е най-добрият вариант).
• Ако това е единственият DC или критик, повдигнете въпрос възстановяване на състоянието на системата от съвместим архив, в идеалния случай скорошен и в рамките на периода на надгробните плочи.

В домейни с множество контролери е силно препоръчително контролерите на домейни да бъдат възможно най-„чисти“: без допълнителни роли или локални потребителски данниПо този начин, ако някой се повреди или се повреди, нов може да бъде форматиран и актуализиран въз основа на друг контролер на домейн или чрез IFM, което значително намалява сложността на възстановяването.

Освен това е важно да се помнят ограничения като например Копията на системното състояние са валидни само през периода на надгробните знаци (60, 90, 180 дни в зависимост от конфигурацията), за да се избегне съживяването на изтрити обекти, и че NTLM машинните ключове се променят на всеки 7 дни. При много стари възстановявания може да се наложи да нулиране на екипните акаунти проблеми от „Потребители и компютри на Active Directory“ или дори премахването им и повторното им присъединяване към домейна.

Наличие на процедури за редовно архивиране на състоянието на системата, Ясно документирайте FSMO ролите, глобалния каталог и топологията на репликация.А тестването на стъпките за възстановяване в лабораторна среда е инвестиция във време, която спестява много главоболия, когато дойде денят, в който домейн контролер се повреди или някой приложи моментна снимка, без да се замисли.