Domeinvertroue het ná ’n maand vanlyn gefaal? Kyk eers hier

’n Skootrekenaar is ses weke van die VPN af, kom terug, en die gebruiker kan nie met ’n domeinrekening aanmeld nie. Die fout noem ’n vertrouensverhouding, so iemand stel die rekenaarrekening terug, of dwing die gebruiker na volle tonneling, en die probleem lyk of dit weggaan. Nie een van die twee aksies het bewys wat fout was nie. ’n Windows-lid kan ver anderkant die gewone masjienwagwoordinterval vanlyn bly sonder om outomaties vertroue te verloor, so die eerste taak is om ’n bereikbaarheidsfout van ’n werklike geheimverskil te skei.

Die fout lyk soos vertroue, maar drie toestande lyk dieselfde

’n Gebruiker kan met gekaste domeininligting aanmeld, die werkstasie kan nie ’n domeinbeheerder vind nie, of die lid en die domein kan werklik oor die rekenaarrekening verskil. Net die derde is ’n gebreekte vertrouensverhouding in die streng sin.

AD-replikasiegesondheid is ’n vierde waarneming, en dit gaan glad nie oor hierdie werkstasie nie. Dit beskryf ooreenkoms tussen domeinbeheerders, en ’n gesonde replikasiepaneel bewys nie dat hierdie masjien se plaaslike geheim by sy rekenaarrekening pas nie.

Die bekende verstek van 30 dae is ’n veranderingsbeleid, nie ’n vanlyn-vervaldatum nie. Microsoft se verduideliking van die masjienrekeningwagwoord beskryf ’n gekoördineerde veranderingsproses, en ’n organisasie kan ’n ander interval instel.

’n VPN-ikoon bewys niks oor die veilige kanaal nie

Konnekteerbaarheid moet goed genoeg wees om domeindienste te bereik voordat enige toets iets beteken. Dit beteken die beoogde domein-DNS-oplosser, ’n beheerder wat gevind kan word, bereikbare verifikasiedienste en ’n horlosie wat naby genoeg vir Kerberos is.

Volle tonneling kan hier ’n heeltemal geldige ontwerp wees. Om na verdeelde tonneling oor te skakel is nie ’n voorvereiste vir ’n gesonde domeinverhouding nie, en om dit as een te behandel maak ’n diagnose in ’n argitektuurverandering. Kyk watter beheerder die werkstasie werklik kies, en hou daardie naam by die fout.

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

Teken die DNS-bediener, die beheerder wat opgelos is en die presiese foutteks aan. ’n VPN-kliënt wat sê hy is gekonnekteer, sê die tonnel bestaan, nie dat die domeinpad werk nie. ’n Beheerder wat op die Kerberos-poort antwoord maar nie op die gidsport nie, is ’n brandmuurbevinding, nie ’n vertrouensbevinding nie.

Toets die lid voordat jy dit herstel

Op ’n gemagtigde Windows-domeinlid is Test-ComputerSecureChannel -Verbose ’n leesalleen-toets van die kanaal tussen die masjien en die domein. Voer dit uit in die masjienkonteks wat jy ondersoek, nie van ’n domeinbeheerder nie, wat ’n ander rol en ander herstelreëls het. Teken die uitset en die uitgangstatus aan eerder as die woord slaag of misluk. As die cmdlet op daardie bou ontbreek, is die module ’n aparte probleem.

Die resultaat het steeds konteks nodig. As die masjien nie die gekose beheerder kan bereik of daarby kan verifieer nie, is ’n mislukte toets nie onafhanklike bewys dat ’n vanlyn wagwoord verval het nie. Hou die werklike fout en die beheerder wat gebruik is, en herhaal die toets sodra die pad bekend goed is.

Korreleer Netlogon-gebeurtenisse op die lid en op die betrokke beheerder rondom die voorval. Bewaar die masjiennaam, die bronadres, die tyd en enige bewys van rekeningverandering. ’n Ander gebruiker se suksesvolle aanmelding, of ’n gesonde beheerderpaneel, kan nie hierdie masjien se uitruiling vervang nie.

Herstel net die verhouding wat jy bewys het

Sodra konnekteerbaarheid stabiel is en ’n administrateur bevestig het dat ’n herstel gepas is, is die cmdlet se -Repair-modus met gemagtigde geloofsbriewe een ondersteunde bewerking vir lidwerkstasies. Dit verander die verhouding, en dit is nie nog ’n leesalleen-toets nie.

Hou ’n goedgekeurde plaaslike herstelrekening en ’n bestuurspad beskikbaar voor die verandering. Domeinbeheerders het ’n ander herstelrol en moet nie deur hierdie prosedure as gewone werkstasies behandel word nie. Gebruik die organisasie se herstelwerkvloei eerder as om verskeie herstelgereedskap in volgorde te hardloop en te hoop een daarvan is die regte een.

Verifieer ná die herstel ’n nuwe veilige-kanaaltoets en die oorspronklike domeinbewerking. Bewaar gebruikersprofiele en toestand van toepassings, en moenie verwyder-en-hertoetree die eerste onverklaarde aksie maak nie.

Wat om na te gaan wanneer die fout terugkeer

As die fout terugkom, kyk na terugrol, duplikaatidentiteit en die tydsberekening van rekeningveranderinge eerder as om dieselfde rekening weer terug te stel. ’n Herstelde beeld, ’n momentopname, ’n gekloonde masjienidentiteit of ’n rekenaarrekening-terugstelling wat elders gedoen is, verdien almal ondersoek.

’n Tydelike suksesvolle terugstelling is nuttige herstelbewys, maar dit is nie bewys dat ’n onderbroke VPN die oorspronklike verskil veroorsaak het nie. Die volgende gebeurtenis is die een wat jou sê of die oorsaak ooit verwyder is.

Skryf die beheerder, die DNS-bediener en die toetsuitset in die kaartjie. Daardie rekord is wat ’n werklike vertrouensfout onderskei van ’n skootrekenaar wat eenvoudig nie die domein kon vind nie.