Was hinter der Meldung steckt

Jeder Rechner, der einer Active-Directory-Domäne angehört, besitzt ein Computerkonto. Wie ein Benutzerkonto hat es ein Passwort – nur wechselt der Rechner dieses Kennwort selbstständig, spätestens alle 30 Tage. Die lokale Kopie verwahrt das Local Security Authority-Subsystem (LSA), die Domänenkopie liegt im Active Directory.

Laufen beide Kopien auseinander, authentisiert sich der Rechner nicht mehr am Domänencontroller. Dann scheitern Domänenanmeldungen, Gruppenrichtlinien und Zugriffe auf Freigaben wie \\DC01-01\C$ – unabhängig davon, ob das Benutzerpasswort stimmt.

Typische Fehlermeldungen und Ereignisse

  • „Die Vertrauensstellung zwischen dieser Arbeitsstation und dem primären Domänencontroller konnte nicht hergestellt werden.“
  • „Der Computer oder das Benutzerkonto konnte nicht gefunden werden“ – bei der Anmeldung oder bei gpupdate /force
  • Netlogon-Ereignisse 5722 und 5723 im Systemprotokoll des Domänencontrollers
  • Kerberos-Client-Ereignis 4 mit KRB_AP_ERR_MODIFIED auf dem Client – typisch für doppelte Rechner-SIDs

Die häufigsten Auslöser

  • Ein Domänencontroller oder Client wurde aus einem Snapshot oder Backup zurückgespielt; eine Seite behält das alte Passwort.
  • Das Computerkonto wurde gelöscht, deaktiviert, umbenannt oder in eine OU verschoben, in der der Rechner kein Schreibrecht auf das eigene Konto hat.
  • Geklonte VMs ohne Sysprep: zwei Maschinen mit identischer SID aktualisieren abwechselnd dasselbe Computerkonto.
  • Netlogon-Dienst gestoppt, Zeitversatz über fünf Minuten oder ein Client-DNS, der die SRV-Einträge der Domäne nicht mehr auflöst.

Diagnose in vier Schritten

Schritt 1: Secure Channel prüfen

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:contoso.com
netdom verify PC01 /domain:contoso.com

Test-ComputerSecureChannel liefert True oder False und ist für Domänenmitglieder gedacht. Auf Domain Controllern erzeugt das Cmdlet laut Microsoft falschpositive Ergebnisse; dort arbeiten Admins mit nltest oder netdom.

Schritt 2: Protokolle lesen

Ereignisanzeige → System, Quelle „Netlogon“, auf Client und Domänencontroller. Das Betriebsprotokoll Microsoft-Windows-GroupPolicy/Operational zeigt jede Verarbeitungsinstanz samt ActivityID, mit der sich fehlgeschlagene Läufe exakt isolieren lassen.

Schritt 3: Computerkonto im AD ansehen

Get-ADComputer -Identity PC01 -Properties lastLogonDate,pwdLastSet,enabled |
  Select-Object Name,Enabled,LastLogonDate,pwdLastSet

pwdLastSet markiert den letzten Passwortwechsel, lastLogonDate die letzte erfolgreiche Anmeldung. Fehlt das Objekt oder steht Enabled auf False, ist die Ursache benannt.

Schritt 4: Infrastruktur ausschließen

w32tm /query /status
nslookup -type=srv _ldap._tcp.dc._msdcs.contoso.com
dcdiag /test:MachineAccount /test:VerifyReplications
repadmin /showrepl

Lösung: reparieren statt neu beitreten

Weg A – Reparatur per PowerShell

$cred = Get-Credential CONTOSO\Administrator
Test-ComputerSecureChannel -Repair -Credential $cred -Verbose

Der Schalter -Repair entfernt den bestehenden Channel und baut ihn über den Netlogon-Dienst neu auf. Ausführen darf es ein Mitglied der lokalen Administratorengruppe, die angegebenen Credentials müssen Schreibrecht auf das Computerkonto besitzen.

Weg B – Netdom auf Arbeitsstationen und Member-Servern

netdom reset PC01 /UserD:CONTOSO\Administrator /PasswordD:*
netdom resetpwd /s:DC01.contoso.com /ud:CONTOSO\Administrator /pd:*

netdom reset setzt die gesicherte Verbindung einer Arbeitsstation oder eines Member-Servers zurück. netdom resetpwd erneuert das Computerkonto-Passwort eines Domänencontrollers und ist nach einer DC-Wiederherstellung der richtige Griff. /reboot startet den Rechner nach Abschluss automatisch – Standardverzögerung 20 Sekunden.

Weg C – Computerkonto instand setzen

Enable-ADComputer -Identity PC01
Move-ADComputer -Identity PC01 -TargetPath "OU=Workstations,DC=contoso,DC=com"

Wurde das Konto gelöscht, hilft nur Neuanlegen und erneuter Beitritt (Remove-Computer, dann Add-Computer -DomainName contoso.com -Credential $cred -Restart). Standardmäßig darf jeder authentifizierte Benutzer zehn Rechner einbinden – der Attributwert ms-DS-MachineAccountQuota steht auf 10. In gehärteten Umgebungen ist er auf 0 gesetzt, dann sind delegierte Rechte nötig.

Sonderfall geklonte VMs

Vergleichen Sie die SID des Rechners mit der des AD-Objekts: whoami /user auf der Maschine, Get-ADComputer -Identity PC01 -Properties objectSid im Domänencontroller-Modul. Stimmen zwei Rechner überein, liegt es an der Vorlage. Vor jedem Snapshot wird generalisiert: sysprep /generalize /oobe /shutdown. Bestehende Vorlagen unter Proxmox VE bereiten Admins mit virt-sysprep aus dem libguestfs-Paket nach.

Vorbeugung im Betrieb

  • Keine Snapshots von Domänencontrollern – für DCs ausschließlich Backup-Verfahren mit anwendungskonsistenten Sicherungen.
  • Die Sicherheitsoption „Domain member: Disable machine account password changes“ nicht aktivieren; der automatische Wechsel ist der Normalfall.
  • Netlogon 5722 und 5723 ins Monitoring aufnehmen, bevor mehrere Nutzer eines Standorts betroffen sind.
  • Der Standardtest eignet sich als geplanter Task: if (-not (Test-ComputerSecureChannel)) { Write-EventLog ... }

Häufige Fragen

Ich komme nicht mehr an den Rechner – klappt die Reparatur trotzdem?

Ja. Windows speichert die letzten Domänenanmeldungen lokal; mit einem bekannten Domänenkonto melden Sie sich an, obwohl der Secure Channel defekt ist.

Muss der Rechner dafür neu gestartet werden?

Nach Test-ComputerSecureChannel -Repair in der Regel nicht. Alte Tickets mit klist purge löschen, dann ab- und wieder anmelden.

Der Fehler kommt nach wenigen Tagen wieder – woran liegt das?

Meist an doppelten SIDs durch Klons oder an der Replikation zweier Domänencontroller, die unterschiedliche Passwortstände austauschen.

Quellen

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.

Tags

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert