Да ли је поверење домена пало после месец дана офлајн? Прво проверите

Лаптоп остаје шест недеља ван VPN-а, враћа се, и корисник не може да се пријави доменским налогом. Грешка помиње однос поверења, па неко ресетује налог рачунара или присиљава корисника на пуно тунелирање, и проблем као да нестаје. Ниједна радња није доказала шта је било покварено. Члан Windows-а може остати офлајн знатно дуже од уобичајеног интервала лозинке машине, а да аутоматски не изгуби поверење, па је први посао одвојити неуспех доступности од стварне неусклађености тајне.

Грешка изгледа као поверење, али три стања се сличе

Корисник може да се пријави кешираним подацима домена, радна станица можда не може да пронађе контролер домена, или се члан и домен заиста не слажу око налога машине. Само је треће покварен однос поверења у строгом смислу.

Здравље AD репликације је четврто запажање и уопште се не односи на ову радну станицу. Оно описује сагласност између контролера домена, а здрав надзорник репликације не доказује да локална тајна ове машине одговара њеном налогу рачунара.

Познати задати рок од 30 дана је политика промене, а не рок истека офлајн. Објашњење Microsoft-а о лозинки налога машине описује координисани процес промене, а организација може конфигурисати другачији интервал.

Икона VPN-а ништа не доказује о безбедном каналу

Повезаност мора бити довољно добра да досегне услуге домена пре него што било који тест нешто значи. То значи предвиђени DNS разрешивач домена, пронађен контролер, доступне услуге провере идентитета и сат довољно близу за Kerberos.

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

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Забележите DNS сервер, разрешени контролер и тачан текст грешке. VPN клијент који јавља да је повезан говори вам да тунел постоји, а не да пут до домена ради. Контролер који одговара на порту Kerberos али не на порту именика налаз је заштитног зида, а не налаз поверења.

Тестирајте члана пре него што га поправите

На овлашћеном Windows члану домена, Test-ComputerSecureChannel -Verbose је провера канала између машине и домена само за читање. Покрените је у контексту машине коју истражујете, не са контролера домена, који има другачију улогу и другачија правила опоравка. Забележите излаз и излазни статус уместо речи прошао или пао. Ако cmdlet недостаје у том build-у, модул је одвојен проблем.

Резултат и даље тражи контекст. Ако машина не може да досегне или се аутентификује на изабраном контролеру, неуспешан тест није независан доказ да је офлајн лозинка истекла. Сачувајте стварну грешку и коришћени контролер и поновите тест кад пут буде познато добар.

Повежите Netlogon догађаје на члану и на релевантном контролеру око инцидента. Сачувајте име машине, изворну адресу, време и сваки доказ промене налога. Успешна пријава другог корисника или здрав надзорник контролера не могу заменити размену ове машине.

Поправите само однос који сте доказали

Кад је повезаност стабилна и администратор потврди да је поправка примерена, -Repair режим овог cmdlet-а са овлашћеним акредитивима једна је подржана операција за радну станицу члана. Он мења однос и није још један тест само за читање.

Пре промене држите доступним одобрени локални налог за опоравак и пут управљања. Контролери домена имају другачију улогу опоравка и овај поступак не сме да их третира као обичне радне станице. Користите организациони ток опоравка уместо покретања неколико алата за ресет узастопно и наде да је један од њих прави.

После поправке проверите нови тест безбедног канала и изворну операцију домена. Сачувајте корисничке профиле и стање апликација, и нека уклањање и поновно придруживање не буде прва необјашњена радња.

Шта проверити кад се квар врати

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

Привремено успешан ресет корисен је доказ опоравка, али није доказ да је испрекидан VPN проузроковао изворну неусклађеност. Следећа појава је та која вам каже да ли је узрок икада уклоњен.

Упишите контролер, DNS сервер и излаз теста у тикет. Тај запис је оно што разликује стварни неуспех поверења од лаптопа који једноставно није могао да пронађе домен.