Domänenvertrauen nach einem Monat offline fehlgeschlagen? Erst prüfen

Ein Laptop ist sechs Wochen außerhalb des VPN, kommt zurück, und der Benutzer kann sich nicht mit einem Domänenkonto anmelden. Die Fehlermeldung nennt eine Vertrauensstellung, also setzt jemand das Computerkonto zurück oder zwingt den Benutzer auf volles Tunneling, und das Problem scheint zu verschwinden. Keine der beiden Aktionen belegte, was defekt war. Ein Windows-Mitglied kann weit über das übliche Intervall für das Maschinenkennwort hinaus offline bleiben, ohne automatisch das Vertrauen zu verlieren, daher besteht die erste Aufgabe darin, einen Erreichbarkeitsfehler von einer echten Abweichung des Geheimnisses zu trennen.

Der Fehler sieht nach Vertrauen aus, doch drei Zustände ähneln sich

Ein Benutzer kann sich mit zwischengespeicherten Domäneninformationen anmelden, die Arbeitsstation kann keinen Domänencontroller finden, oder das Mitglied und die Domäne können sich über das Computerkonto tatsächlich uneinig sein. Nur der dritte Fall ist eine gebrochene Vertrauensstellung im strengen Sinn.

Der Zustand der AD-Replikation ist eine vierte Beobachtung und betrifft diese Arbeitsstation überhaupt nicht. Er beschreibt die Übereinstimmung zwischen Domänencontrollern, und ein gesundes Replikations-Dashboard belegt nicht, dass das lokale Geheimnis dieser Maschine zu ihrem Computerkonto passt.

Der vertraute Standardwert von 30 Tagen ist eine Änderungsrichtlinie, keine Frist für den Offline-Ablauf. Microsofts Erläuterung des Kennworts für das Maschinenkonto beschreibt einen koordinierten Änderungsprozess, und eine Organisation kann ein anderes Intervall konfigurieren.

Ein VPN-Symbol belegt nichts über den sicheren Kanal

Die Konnektivität muss gut genug sein, um Domänendienste zu erreichen, bevor irgendein Test etwas bedeutet. Das heißt der vorgesehene DNS-Resolver der Domäne, ein auffindbarer Controller, erreichbare Authentifizierungsdienste und eine Uhr, die für Kerberos nah genug ist.

Volles Tunneling kann hier ein völlig gültiges Design sein. Der Wechsel zu Split-Tunneling ist keine Voraussetzung für eine gesunde Domänenbeziehung, und ihn als eine zu behandeln macht aus einer Diagnose eine Architekturänderung. Prüfen Sie, welchen Controller die Arbeitsstation tatsächlich wählt, und bewahren Sie diesen Namen zusammen mit dem Fehler auf.

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

Notieren Sie den DNS-Server, den aufgelösten Controller und den genauen Fehlertext. Ein VPN-Client, der verbunden meldet, sagt Ihnen, dass der Tunnel existiert, nicht dass der Domänenpfad funktioniert. Ein Controller, der auf dem Kerberos-Port antwortet, aber nicht auf dem Verzeichnisdienst-Port, ist ein Firewall-Befund, kein Vertrauensbefund.

Testen Sie das Mitglied, bevor Sie es reparieren

Auf einem autorisierten Windows-Domänenmitglied ist Test-ComputerSecureChannel -Verbose eine reine Leseprüfung des Kanals zwischen der Maschine und der Domäne. Führen Sie sie im Kontext der Maschine aus, die Sie untersuchen, nicht von einem Domänencontroller, der eine andere Rolle und andere Wiederherstellungsregeln hat. Halten Sie die Ausgabe und den Exit-Status fest statt des Wortes bestanden oder fehlgeschlagen. Fehlt das Cmdlet in diesem Build, ist das Modul ein separates Problem.

Das Ergebnis braucht weiterhin Kontext. Kann die Maschine den gewählten Controller nicht erreichen oder sich dort nicht authentifizieren, ist ein fehlgeschlagener Test kein unabhängiger Beweis dafür, dass ein Offline-Kennwort abgelaufen ist. Bewahren Sie den tatsächlichen Fehler und den verwendeten Controller auf und wiederholen Sie den Test, sobald der Pfad nachweislich in Ordnung ist.

Korrelieren Sie Netlogon-Ereignisse auf dem Mitglied und auf dem betroffenen Controller rund um den Vorfall. Bewahren Sie den Maschinennamen, die Quelladresse, den Zeitpunkt und jeden Nachweis einer Kontenänderung auf. Die erfolgreiche Anmeldung eines anderen Benutzers oder ein gesundes Controller-Dashboard kann den Austausch dieser Maschine nicht ersetzen.

Reparieren Sie nur die Beziehung, die Sie belegt haben

Sobald die Konnektivität stabil ist und ein Administrator bestätigt hat, dass eine Reparatur angebracht ist, ist der Modus -Repair des Cmdlets mit autorisierten Anmeldeinformationen ein unterstützter Vorgang für eine Mitglieds-Arbeitsstation. Er ändert die Beziehung und ist kein weiterer Lesetest.

Halten Sie vor der Änderung ein genehmigtes lokales Wiederherstellungskonto und einen Verwaltungspfad bereit. Domänencontroller haben eine andere Wiederherstellungsrolle und dürfen von diesem Verfahren nicht wie gewöhnliche Arbeitsstationen behandelt werden. Nutzen Sie den Wiederherstellungsablauf der Organisation, statt mehrere Zurücksetzungsprogramme nacheinander auszuführen und zu hoffen, dass eines davon das richtige ist.

Verifizieren Sie nach der Reparatur einen frischen Test des sicheren Kanals und den ursprünglichen Domänenvorgang. Bewahren Sie Benutzerprofile und Anwendungszustand, und machen Sie Entfernen-und-neu-Beitreten nicht zur ersten unerklärten Aktion.

Was zu prüfen ist, wenn der Fehler zurückkehrt

Kehrt der Fehler zurück, betrachten Sie Rollback, doppelte Identität und den Zeitpunkt von Kontenänderungen, statt dasselbe Konto erneut zurückzusetzen. Ein wiederhergestelltes Image, ein Snapshot, eine geklonte Maschinenidentität oder ein anderswo durchgeführtes Computerkonto-Reset verdienen alle eine Untersuchung.

Ein vorübergehend erfolgreiches Zurücksetzen ist ein nützlicher Wiederherstellungsbeleg, aber kein Beweis dafür, dass ein intermittierendes VPN die ursprüngliche Abweichung verursacht hat. Der nächste Vorfall ist der, der Ihnen sagt, ob die Ursache jemals beseitigt wurde.

Schreiben Sie den Controller, den DNS-Server und die Testausgabe ins Ticket. Dieser Datensatz unterscheidet einen echten Vertrauensfehler von einem Laptop, der die Domäne einfach nicht finden konnte.