Share via

Ueberpruefung wann das Computer Passwort lokal und im Active Directory zuletzt geaendert wurde

  • Article

Hallo, hier wieder einmal Rol mit einem Vorgehen zur Überprüfung, wann ein Computer Passwort lokal und im Active Directory zuletzt geändert würde.
Auslöser für eine solche Untersuchung ist häufig der Umstand, daß Clients aus der Domäne gefallen sind, und kein gültiges Passwort mehr haben, mit dem sie sich erfolgreich im AD authentifizieren können.
Mit dem folgenden Vorgehen können wir vergleichen, wann der Netlogon Dienst zuletzt das lokale Passwort geändert hat, und wann es im AD zuletzt geändert wurde.

1 ) Lokale Computer-Passwort Änderung

Den lokalen Computer Passwort Hash ändert Netlogon in der Registry unter HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC. Die angegraute KB Referenz hierzu ist 199071 “Recovering from Minor LSA Corruption”; https://support.microsoft.com/default.aspx?scid=kb;EN-US;199071
Der Registry Hive SECURITY ist jedoch per Default selbst den lokalen Administrator nicht zugänglich. Die Permissions sollten auch nicht geändert werden, hier behelfen wir uns mit dem Sysinternals Tool PSEXEC.EXE und führen REGEDIT.EXE im Systemkontext interaktiv aus (Parameter -s und -i):

psexec.exe -s -i regedit.exe

Im Registry Editor gehen wir dann zum Key HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC\CurrVal

image

Über das rechte Kontext Menü Exportieren wir nun diesen Key über “Export Registry File” als TXT Datei:

image

image

Beim Export als TXT Datei bekommen wir nun den Zeitpunkt der letzten Änderung, in der Ausgabedatei sec_currval.txt:

Key Name: HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC\CurrVal Class Name: <NO CLASS>
Last Write Time: 9/12/2011 - 8:47 AM Value 0
Name: <NO NAME>
Type: REG_NONE

Netlogon hat also am 12.09.2011 um 8:47 Uhr das lokale Computer Passwort zuletzt gesetzt.

 

2) Computer-Passwortänderung im Active Directory

Im zweiten Schritt sehen wir uns nun die Änderung des Computer Passwortes im Active Directory an. Dazu zwei kleine Tricks, die uns das Leben vereinfachen und mit denen wir den DC Namen und den Computer DN im AD einfach erhalten. Die brauchen wir dann im Anschluß für die REPADMIN Syntax.

Den DC Namen erhalten wir z.B. mit “NLTEST /SC_QUERY:<Domain>”

nltest /sc_query:Contoso
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\MyDC01.contoso.com Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

Den Computer DN bekommen wir ganz einfach über “SETSPN /L <Computername>”

setspn -l MyClient01
Registered ServicePrincipalNames for CN=MyClient01,OU=Workstations,OU=Machines,DC=contoso,DC=com:
RestrictedKrbHost/MyClient01.contoso.com
HOST/MyClient01.contoso.com
RestrictedKrbHost/MyClient01
HOST/MyClient01

oder mittels Powershell und “get-adcomputer <Computername>”, wenn das Active Directory-Modul für Powershell installiert ist.

Im Anschluß verwenden wir dann die gewonnenen Parameter für “REPADMIN /SHOWOBJMETA <DC Name> <Computer DN>” :

repadmin /showobjmeta MyDC01 “CN=MyClient01,OU=Workstations,OU=Machines,DC=contoso,DC=com” 34 entries.
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
89284568 MySite\MyDC01 89284568 2009-12-17 16:35:05 1 objectClass
89327088 MySite\MyDC01 89327088 2009-12-17 17:26:42 2 cn
89284568 MySite\MyDC01 89284568 2009-12-17 16:35:05 1 instanceType
89284568 MySite\MyDC01 89284568 2009-12-17 16:35:05 1 whenCreated
89327091 MySite\MyDC01 89327091 2009-12-17 17:26:43 1 displayName
89284568 MySite\MyDC01 89284568 2009-12-17 16:35:05 1 nTSecurityDescriptor
89327088 MySite\MyDC01 89327088 2009-12-17 17:26:42 2 name
89284568 MySite\MyDC01 89284568 2009-12-17 16:35:05 1 userAccountControl
89284569 MySite\MyDC01 89284569 2009-12-17 16:35:05 1 codePage
89284569 MySite\MyDC01 89284569 2009-12-17 16:35:05 1 countryCode
833501409 MySite\MyDC02 841590822 2011-09-12 08:47:51 25 dBCSPwd
89284568 MySite\MyDC01 89284568 2009-12-17 16:35:05 1 localPolicyFlags
89284569 MySite\MyDC01 89284569 2009-12-17 16:35:05 1 logonHours
833501409 MySite\MyDC02 841590822 2011-09-12 08:47:51 25 unicodePwd
833501409 MySite\MyDC02 841590822 2011-09-12 08:47:51 25 ntPwdHistory
833501409 MySite\MyDC02 841590822 2011-09-12 08:47:51 25 pwdLastSet …

Der Eintrag “2011-09-12 08:47:51 25 pwdLastSet” zeigt nun, daß auch im Active Directory am 12.09.2011 um 8:47 Uhr das Computer Passwort im AD zuletzt gesetzt worden ist, und zwar am DC MyDC02. Das paßt also zur Ausgabe aus der Registry.

 

Bei Fehlersituationen habe wir hier zwei Fehlerbilder mit den entsprechenden möglichen Ursachen:

a) Das lokale Computer Passwort ist neuer als das im AD

  • Wenn es abhängig vom DC ist, den wir mit Repadmin ansprechen, kann es sich um Replication Delay handeln oder generell um Replikationsprobleme
  • Wenn das AD konsistent eine ältere Änderung anzeigt, wurde der AD Stand evtl durch einen AD Restore zurückgesetzt
  • Der Client setzt das neue Passwort lokal, kann aber dann doch keinen DC erreichen um es im AD abzugleichen
  • Der Client kontaktiert einen RODC ist aber in der Password Replication Policy nicht eingetragen, siehe auch https://blogs.technet.com/b/deds/archive/2011/02/08/rodc-in-dmz.aspx
  • Für Win7 ist das SP1 Hotfix 979495 empfohlen: 979495 “A secure channel is broken after you change the computer password on a Windows 7 or Windows Server 2008 R2-based client computer”; https://support.microsoft.com/default.aspx?scid=kb;EN-US;979495

b) Das lokale Computer Passwort ist älter als das im AD

  • Der Computer selbst wurde durch einen Restore zurückgesetzt, und damit auch der Registry SECURITY Hive. Das kann auch automatisch durch Systemrecovery passieren, wenn z.B. das System abstürzt. Indikatoren sind dann Events wie die folgenden eines Win7 Clients:

Log Name: System
Source: Microsoft-Windows-Kernel-Power
Event ID: 41
Level: Critical
User: SYSTEM
Computer: MyCrashedWin7Client.contoso.com
Description: The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.

Das Folge-Event ist dann entsprechend:

Log Name: System
Source: NETLOGON
Event ID: 3210
Level: Error
User: N/A
Computer: MyCrashedWin7Client.contoso.com
Description: This computer could not authenticate with \\MyDC01.contoso.com a Windows domain controller for domain CONTOSO, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

In der Situation muß man den Computer dann in die Domäne Re-Joinen.

Weitere nützliche Informationen zum Computerpasswort und dessen Änderungsprozess finden sich im Blog unserer US Kollegen:
”Machine Account Password Process - Ask the Directory Services Team ...”; https://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

Ich hoffe dies hilft etwas, um solche Probleme besser eingrenzen zu können.
Damit gutes Gelingen und viele Grüße aus dem herbstlich sonnigen Wiesn-Zentrum München.
Euer Rol

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Vielen Dank, habe lange nach einer solchen Lösung gesucht und jetzt gefunden! Danke!

  • Anonymous
    October 04, 2011
    Hi, danke erstmal für die Infos. IMO geht es noch einfacher via PS an die gewünschte AD-Info ranzukommen: "Get-ADComputer <Name Computerkonto> -Properties * | ft Name, PasswordLastSet" spuckt direkt den gewünschten Wert aus; und da das Attribut repliziert wird, ist es auch unrelevant auf welchem DC die Passwort-Änderung passiert ist!? Viele Grüße Stephan