Notebook je šest týdnů mimo VPN, vrátí se a uživatel se nemůže přihlásit doménovým účtem. Chyba zmiňuje vztah důvěry, takže někdo resetuje účet počítače nebo uživatele donutí na plné tunelování, a problém jako by zmizel. Ani jeden zásah nedokázal, co bylo rozbité. Člen Windows může zůstat offline výrazně déle než obvyklý interval hesla počítače, aniž by automaticky ztratil důvěru, takže prvním úkolem je oddělit selhání dostupnosti od skutečného nesouladu tajemství.

Chyba vypadá jako důvěra, ale tři stavy se podobají

Uživatel se může přihlásit pomocí uložených doménových informací, pracovní stanice nemusí najít řadič domény nebo se člen a doména mohou skutečně rozcházet v názoru na účet počítače. Jen třetí případ je rozbitý vztah důvěry v přísném smyslu.

Zdraví replikace AD je čtvrté pozorování a o této pracovní stanici vůbec nevypovídá. Popisuje shodu mezi řadiči domény a zdravý přehled replikace nedokazuje, že místní tajemství tohoto počítače odpovídá jeho účtu počítače.

Známá výchozí hodnota 30 dní je zásada změny, ne lhůta vypršení offline. Microsoftovo vysvětlení hesla účtu počítače popisuje koordinovaný proces změny a organizace může nastavit jiný interval.

Ikona VPN o zabezpečeném kanálu nic nedokazuje

Konektivita musí být dost dobrá, aby dosáhla doménových služeb, dřív než má jakýkoli test smysl. To znamená zamýšlený DNS resolver domény, nalezitelný řadič, dostupné ověřovací služby a hodiny dost blízko pro Kerberos.

Plné tunelování tu může být zcela platný návrh. Přechod na rozdělené tunelování není předpokladem zdravého vztahu s doménou a jeho pojetí jako předpokladu mění diagnózu ve změnu architektury. Ověřte, který řadič si pracovní stanice skutečně vybírá, a uchovejte ten název u chyby.

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

Zapište DNS server, přeložený řadič a přesný text chyby. Klient VPN, který hlásí připojení, říká, že tunel existuje, ne že cesta do domény funguje. Řadič, který odpovídá na portu Kerberos, ale ne na portu adresáře, je nález firewallu, ne nález důvěry.

Otestujte člena, než ho opravíte

Na autorizovaném členu domény Windows je Test-ComputerSecureChannel -Verbose kontrola kanálu mezi počítačem a doménou pouze pro čtení. Spouštějte ji v kontextu počítače, který zkoumáte, ne z řadiče domény, který má jinou roli a jiná pravidla obnovy. Zaznamenejte výstup a návratový stav místo slova prošlo nebo selhalo. Pokud na daném sestavení cmdlet chybí, modul je samostatný problém.

Výsledek stále potřebuje kontext. Pokud počítač nemůže dosáhnout zvoleného řadiče nebo se na něm ověřit, neúspěšný test není nezávislým důkazem, že offline heslo vypršelo. Uchovejte skutečnou chybu a použitý řadič a test zopakujte, až bude cesta prokazatelně dobrá.

Korelujte události Netlogon na členu a na příslušném řadiči kolem incidentu. Uchovejte název počítače, zdrojovou adresu, čas a jakýkoli důkaz změny účtu. Úspěšné přihlášení jiného uživatele nebo zdravý přehled řadiče nemůže nahradit výměnu tohoto počítače.

Opravte jen vztah, který jste dokázali

Jakmile je konektivita stabilní a správce potvrdí, že oprava je vhodná, režim -Repair tohoto cmdletu s autorizovanými přihlašovacími údaji je jedna podporovaná operace pro členskou pracovní stanici. Mění vztah a není to další test pouze pro čtení.

Před změnou mějte k dispozici schválený místní účet pro obnovu a cestu správy. Řadiče domény mají jinou roli obnovy a tento postup je nesmí brát jako běžné pracovní stanice. Použijte organizační postup obnovy, místo abyste spouštěli několik nástrojů pro reset za sebou a doufali, že jeden z nich je ten pravý.

Po opravě ověřte nový test zabezpečeného kanálu a původní doménovou operaci. Zachovejte uživatelské profily a stav aplikací a nenechte odebrání a opětovné připojení být první nevysvětlenou akcí.

Co zkontrolovat, když se selhání vrátí

Pokud se selhání vrátí, podívejte se na vrácení zpět, duplicitní identitu a načasování změn účtu, místo abyste stejný účet znovu resetovali. Obnovený obraz, snímek, klonovaná identita počítače nebo reset účtu počítače provedený jinde si všechny zaslouží vyšetření.

Dočasně úspěšný reset je užitečný důkaz obnovy, ale není důkazem, že původní nesoulad způsobil přerušovaný VPN. Právě příští výskyt vám řekne, zda byla příčina vůbec odstraněna.

Zapište řadič, DNS server a výstup testu do tiketu. Právě tento záznam odlišuje skutečné selhání důvěry od notebooku, který prostě nenašel doménu.

Související články