Domeinvertrouwen na een maand offline verbroken? Controleer eerst

Een laptop staat zes weken buiten de VPN, komt terug, en de gebruiker kan niet inloggen met een domeinaccount. De fout noemt een vertrouwensrelatie, dus iemand stelt het computeraccount opnieuw in, of dwingt de gebruiker naar volledige tunneling, en het probleem lijkt te verdwijnen. Geen van beide acties bewees wat er kapot was. Een Windows-lid kan veel langer dan het gebruikelijke interval van het machinewachtwoord offline blijven zonder automatisch het vertrouwen te verliezen, dus de eerste taak is een bereikbaarheidsfout scheiden van een echte geheimafwijking.

De fout lijkt op vertrouwen, maar drie toestanden lijken op elkaar

Een gebruiker kan inloggen met gecachte domeingegevens, het werkstation kan geen domeincontroller vinden, of het lid en het domein kunnen het echt oneens zijn over het computeraccount. Alleen de derde is een verbroken vertrouwensrelatie in strikte zin.

De gezondheid van AD-replicatie is een vierde observatie, en die gaat helemaal niet over dit werkstation. Het beschrijft overeenstemming tussen domeincontrollers, en een gezond replicatiedashboard bewijst niet dat het lokale geheim van deze machine bij zijn computeraccount past.

De bekende standaard van 30 dagen is een wijzigingsbeleid, geen offline-vervaldatum. Microsofts uitleg over het wachtwoord van het machineaccount beschrijft een gecoördineerd wijzigingsproces, en een organisatie kan een ander interval configureren.

Een VPN-pictogram bewijst niets over het beveiligde kanaal

De connectiviteit moet goed genoeg zijn om domeinservices te bereiken voordat een test iets betekent. Dat betekent de bedoelde DNS-resolver van het domein, een vindbare controller, bereikbare verificatieservices en een klok die dicht genoeg bij Kerberos ligt.

Volledige tunneling kan hier een volkomen geldig ontwerp zijn. Overstappen op split-tunneling is geen voorwaarde voor een gezonde domeinrelatie, en het als zodanig behandelen maakt van een diagnose een architectuurwijziging. Controleer welke controller het werkstation werkelijk kiest, en bewaar die naam bij de fout.

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

Noteer de DNS-server, de opgeloste controller en de exacte fouttekst. Een VPN-client die meldt dat hij verbonden is, vertelt u dat de tunnel bestaat, niet dat het domeinpad werkt. Een controller die antwoordt op de Kerberos-poort maar niet op de adresboekpoort is een firewallbevinding, geen vertrouwensbevinding.

Test het lid voordat u het repareert

Op een geautoriseerd Windows-domeinlid is Test-ComputerSecureChannel -Verbose een alleen-lezen controle van het kanaal tussen de machine en het domein. Voer die uit in de machinecontext die u onderzoekt, niet vanaf een domeincontroller, die een andere rol en andere herstelregels heeft. Leg de uitvoer en de exitstatus vast in plaats van het woord geslaagd of mislukt. Als de cmdlet in die build ontbreekt, is de module een apart probleem.

Het resultaat heeft nog steeds context nodig. Als de machine de gekozen controller niet kan bereiken of zich daar niet kan verifiëren, is een mislukte test geen onafhankelijk bewijs dat een offline wachtwoord is verlopen. Bewaar de werkelijke fout en de gebruikte controller, en herhaal de test zodra het pad bekend goed is.

Correleer Netlogon-gebeurtenissen op het lid en op de betrokken controller rond het incident. Bewaar de machinenaam, het bronadres, de tijd en elk bewijs van accountwijziging. Een geslaagde aanmelding van een andere gebruiker, of een gezond controllerdashboard, kan de uitwisseling van deze machine niet vervangen.

Repareer alleen de relatie die u hebt bewezen

Zodra de connectiviteit stabiel is en een beheerder heeft bevestigd dat een reparatie passend is, is de -Repair-modus van de cmdlet met geautoriseerde referenties één ondersteunde bewerking voor een lidwerkstation. Hij wijzigt de relatie, en het is geen nieuwe alleen-lezen test.

Houd een goedgekeurd lokaal herstelaccount en een beheerpad beschikbaar vóór de wijziging. Domeincontrollers hebben een andere herstelrol en mogen door deze procedure niet als gewone werkstations worden behandeld. Gebruik de herstelworkflow van de organisatie in plaats van meerdere resetprogramma's achter elkaar uit te voeren en te hopen dat een ervan de juiste is.

Verifieer na de reparatie een nieuwe test van het beveiligde kanaal en de oorspronkelijke domeinbewerking. Behoud gebruikersprofielen en de toestand van toepassingen, en maak van verwijderen-en-opnieuw-koppelen niet de eerste onverklaarde actie.

Wat u moet controleren als de fout terugkomt

Als de fout terugkomt, kijk dan naar terugdraaien, dubbele identiteit en het moment van accountwijzigingen in plaats van hetzelfde account opnieuw opnieuw in te stellen. Een hersteld image, een momentopname, een gekloonde machine-identiteit of een elders uitgevoerde computeraccount-reset verdienen allemaal onderzoek.

Een tijdelijk geslaagde reset is nuttig herstelbewijs, maar het is geen bewijs dat een onderbroken VPN de oorspronkelijke afwijking veroorzaakte. De volgende keer dat het gebeurt, vertelt u of de oorzaak ooit is weggenomen.

Schrijf de controller, de DNS-server en de testuitvoer in het ticket. Dat record onderscheidt een echt vertrouwensprobleem van een laptop die het domein simpelweg niet kon vinden.