Враћање и опоравак оштећеног локалног контролера домена

Када се контролер домена оштети или се неправилно врати у функцију, страх је огроман: Пријављивања не успевају, GPO-и престају да се примењују, а репликација се прекида готово без икаквих назнака.Добра вест је да постоје јасне процедуре за опоравак физичког или виртуелног контролера домена, под условом да се поштују прихваћене методе прављења резервних копија и враћања.

У модерним Windows Server окружењима, враћање контролера домена захтева добро разумевање концепата као што су статус система, ауторитативно/неауторитивно враћање, враћање на претходне вредности (SYSVOL), DFSR/FRS и USNАко се ови проблеми реше брзоплето или некомпатибилним алатима за снимање, резултат може бити шума пуна тихих недоследности које је веома тешко дијагностиковати.

Зашто је кључно правилно заштитити и опоравити контролер домена

Активни директоријум је срж аутентификације и ауторизације у Windows доменуЧува кориснике, рачунаре, групе, односе поверења, групне политике, сертификате и друге критичне елементе. Ове информације се првенствено налазе у бази података. Нтдс.дит, повезане датотеке дневника и фасцикла СИСВОЛ, између осталих компоненти које чине такозвано „стање система“.

Статус система обухвата, између осталог, Датотеке и подаци дневника Active Directory-ја, Windows регистар, системски волумен, SYSVOL, база података сертификата (ако постоји CA), IIS метабаза, датотеке за покретање и заштићене компоненте оперативног системаСтога, свака озбиљна стратегија континуитета пословања мора да укључује редовне резервне копије стања система сваког дата центра.

Када дође до стварног оштећења базе података Active Directory-ја, озбиљног квара репликације или проблема са дозволе укључене СИСВОЛКонтролер домена може престати са обрадом упита, не успети да покрене услуге Active Directory или покренути каскадне грешке у целој шуми. У тим случајевима, Брз и правилан опоравак прави разлику између озбиљног инцидента и дуготрајне катастрофе..

Пре него што покушате враћање података, кључно је разликовати прави проблем са базом података од обичнијих кварова. Врло често, Узрок лежи у DNS-у, променама мреже, заштитним зидовима или рутама модификованим алатима као што су нетсх цоммандСтога је препоручљиво прво искључити ове факторе пре него што се додирне AD база података.

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

У случају симптома корупције или кварова репликације, први разуман корак је провера стања окружења коришћењем изворних алата. DCDiag, Repadmin, ReplMon (у старијим верзијама) и прегледач догађаја Они су ваши најбољи савезници пре него што размислите о агресивним рестаурацијама.

са ДЦДијаг Врши се општа провера свих контролера домена, идентификујући проблеме са репликацијом, 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-јемОви алати користе Microsoft-ове API-је за прављење резервних копија и враћање и услугу Volume Shadow Copy Service (VSS) на подржан начин.

Међу најчешћим решењима су Резервне копије Windows Server-а, решења трећих страна интегрисана са VSS-ом (као што су NAKIVO, Backup Exec и други)или старије услужне програме као што су Нтбацкуп у оперативном систему 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 топологије без његовог учешћа у даљој репликацији.

Након присилног враћања на старију верзију, обавезно је извршити команду са исправног контролера домена. чишћење метаподатака помоћу алата НтдсутилОвај процес уклања све референце на обрисани контролер домена (објекте подешавања NTDS, DNS референце итд.) из AD базе података, тако да нема остатака „духова“ који би могли да збуне репликацију.

Ако је деградирани контролер имао FSMO улоге (PDC емулатор, RID мастер, мастер шеме итд.), биће потребно пребацује или преузима те улоге на други контролер домена пре или после деградације, у зависности од ситуације. Касније, оперативни систем се може поново инсталирати на том серверу и он се може вратити на чист контролер домена.

Неауторитативно наспрам ауторитативног враћања у Active Directory

Када је доступна валидна копија стања система, опоравак AD-а може се обавити на два начина: неауторитативни и ауторитативниРазумевање разлике је кључно да се не пропусте недавне промене или да се не реплицирају застарели подаци.

Ин а неауторитативна рестаурацијаДЦ се враћа на претходну тачку, али када се покрене, Остали контролери домена се сматрају референцомДругим речима, након покретања, обновљени контролер домена захтева долазну репликацију и ажурира своју базу података свим недостајућим променама са осталих контролера домена. Ова опција је идеална када Постоје и други здрави контролори, и желимо да их онај који је обновљен сустигне..

Ин а ауторитарна рестаурацијаМеђутим, експлицитно је наведено да Враћени подаци су оно што би требало да превлада. преко онога што имају други контролери домена. То значи да ће, након враћања, опорављени објекти имати виши број верзије како би се приморали да буду реплицирани са тог контролера домена на остатак домена. То је одговарајући избор када Случајно смо обрисали објекте или организацијске јединице (OU) или желимо да вратимо садржај SYSVOL-а и GPO-а у претходно стање и да га реплицирамо..

Важан детаљ је да ауторитативна рестаурација не мора нужно бити за целу базу података. Уз помоћ услужног програма Нтдсутил Појединачни објекти, подстабла (нпр. ОУ) или цео домен могу бити означени као ауторитативни. Ово нуди значајну флексибилност, на пример, преузми само корисника, групу, организацијску јединицу или подстабло dc=mycompany,dc=local.

Општи поступак за враћање статуса система у контролеру домена

Основна шема за враћање стања система контролера домена (било физичког или виртуелног) помоћу компатибилних алата је увек слична: Покрените систем у режим враћања услуга директоријума (DSRM), вратите систем помоћу алатке за резервне копије и поново покрените систем.

Укратко, типични кораци за виртуелни контролер домена би били:

1. Покрените виртуелну машину у Windows Boot Manager-у (обично притиском на F5/F8 током покретања). Ако виртуелном машином управља хипервизор, можда ће бити потребно паузирати машину да би се забележио притисак тастера.
2. У напредним опцијама покретања изаберите Режим враћања услуга директоријума (Режим враћања услуга директоријума). Овај режим покреће сервер без монтирања базе података Active Directory на функционалан начин.
3. Пријавите се са DSRM администраторским налогом дефинисано током оригиналне промоције контролера домена (не са стандардним налогом администратора домена).
4. Покрените алатку за прављење резервних копија коришћени (Windows Server Backup, NAKIVO или други компатибилни) и изаберите враћање стања система на жељену тачку резервне копије.
5. Завршите чаробњака за рестаурацију и Поново покрените ДЦ у нормалном режимуУ неауторитативном враћању, сервер ће покренути репликацију како би сустигао остале контролере домената.

Када говоримо о производима за прављење резервних копија трећих страна, као што су НАКИВО Бацкуп & РеплицатионЊегов „апликацијски свестан“ режим је у стању да препозна да је машина која се опоравља контролер домена и аутоматски прилагоди процес како би се сачувала конзистентност AD-аУ већини сценарија са више контролера, довољан је потпуни опоравак у неауторитативном режиму.

Ауторитативно враћање у нормалу помоћу Ntdsutil-а

Ако желите да промене на враћеном контролеру домена имају предност над осталима, потребно је да додате додатни корак након неауторитативног враћања: Користите Ntdsutil да бисте означили објекте као ауторитативне.

Поједностављени ток би био:

1. Вратите стање система на стандардни начин и оставите сервер и даље укључен DSRM режим (Немојте још поново покретати систем у нормалном режиму).
2. Отворите а командна линија са повишеним привилегијама и бежи ntdsutil.
3. Активирајте AD инстанцу са активирај инстанцу нтдс.
4. Улазак у контекст ауторитативне рестаурације са ауторитативно враћање.
5. Користите команде попут restore object <DN_objeto> o restore subtree <DN_subarbol>, где је DN препознатљиво име објекта или подстабла које треба ауторитативно рестаурирати.
6. Потврдите трансакцију и, када је завршена, Поново покрените ДЦ у нормалном режиму тако да се означени објекти реплицирају са приоритетом на остатак домена.

Ова врста рестаурације захтева велику пажњу. Ако је цео домен ауторитативно враћен, а резервна копија је стараПостоји ризик од губитка легитимних промена направљених након прављења резервне копије (на пример, креирање корисника, промене лозинки или измене група). Стога је уобичајена пракса да се ауторитативне рестаурације ограниче само на строго неопходне објекте или стабла.

Рестаурација и опоравак 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 хексадецимално) да би се назначило да је овај контролер домена ауторитативни извор.

Ако DFSR реплицира SYSVOL, процес је нешто сложенији: укључује коришћење АДСИЕдит да бисте изменили објекте претплате SYSVOL (атрибуте) msDFSR-Омогућено y msDFSR-Опције) на ауторитативном контролеру домена и на осталима, присилити репликацију AD-а, извршити dfsrdiag полад и потврдите у дневнику догађаја појаву догађаји 4114, 4602, 4614 и 4604 који потврђују да је SYSVOL правилно иницијализован и реплициран.

Опоравак виртуелних контролера домена са VHD-а

У виртуелизованим окружењима је веома уобичајено да се VHD/VHDX датотеке контролера доменаАко немате резервну копију стања система, али имате функционалан „стари“ VHD, можете монтирати нови контролер домена са тог диска, мада то морате учинити веома пажљиво како бисте избегли враћање USN-а.

Препорука је Не покрећите ту виртуелну машину директно у нормалном режимуУместо тога, требало би да се покренете са претходног VHD-а у ДСРМОтворите уређивач регистра и идите на 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-а на претходно стање„, разумно је урадити следеће:

• Проверите са дцдиаг y репадмин обим грешака и да ли постоје „перзистентни објекти“.
• Проверите догађај 2095 и вредност DSA није могуће писати у Регистру.
• Процените да ли је могуће Уклоните тај ДЦ и поново га изградите (Ако постоје три или више других здравих контролера домената, ово је обично најбоља опција).
• Ако је то једини водитељ догађаја или критичар, покрените питање обнављање стања система из компатибилне резервне копије, идеално скорашње и унутар периода заштите од надгробних споменика.

У доменима са више контролера, топло се препоручује да контролери домена буду што је могуће „чистији“: без додатних улога или локалних корисничких податакаНа овај начин, ако један откаже или се оштети, нови се може форматирати и унапредити на основу другог контролера домена или путем IFM-а, што значајно смањује сложеност опоравка.

Поред тога, вреди запамтити ограничења као што су Копије стања система важе само током периода надгробних ознака (60, 90, 180 дана у зависности од конфигурације) да би се избегло оживљавање обрисаних објеката и да се NTLM машински кључеви мењају сваких 7 дана. Код веома старих враћања, можда ће бити потребно ресетуј тимске налоге проблеми са „Active Directory Users and Computers“ или чак њихово уклањање и поновно придруживање домену.

Имање процедура за редовно прављење резервних копија стања система, Јасно документујте FSMO улоге, глобални каталог и топологију репликацијеА тестирање корака рестаурације у лабораторијском окружењу је временска инвестиција која штеди много главобоља када дође дан да се контролер домена оштети или неко примени снимак без размишљања.