Ich habe also eine Windows Active Directory-Domäne mit zwei Domänencontrollern DC1und DC2, die beide unter Windows Server 2008 R2 laufen. DC1ist der primäre DC, der alle FSMO-Rollen enthält. Es funktionierte wie erwartet, bis wir eines Tages aus irgendeinem Grund für einige (lausige) Anwendungen die Möglichkeit hatten, bestimmten Benutzern die Möglichkeit zu geben, Uhrzeit und Datum auf ihren Computern zu ändern. Wir haben ein Gruppenrichtlinienobjekt für die bestimmten Benutzer ( OU1und OU2) eingerichtet, das es ihnen ermöglicht, die Systemzeit zu ändern:
Computer Configurations
-> Windows Settings
-> Security Settings
-> Local Policies
-> User Rights Assignment
-> Change the system time
Und Gruppen hinzugefügt, denen ich dieses Recht zuweisen möchte. Nachdem ich diese Einstellungen jedoch am vorgenommen hatte DC1, führte ich ein aus gpupdateund es wurde ein Fehler zurückgegeben:
C:\Users\myuser>gpupdate
Updating Policy...
User Policy update has completed successfully.
Computer policy could not be updated successfully. The following errors were encountered:
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed).
Look in the details tab for error code and description.
To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.
Ich habe die Ereignisanzeige geprüft und sie hat einen Fehler angezeigt: Ereignis-ID 1006, Fehlercode 49, Fehlerbeschreibung: Ungültige Anmeldeinformationen.
Dieser Artikellegt nahe, dass dieser Fehler dadurch verursacht wird, dass einige Systemdienste als Benutzerkonto ausgeführt werden, dessen Anmeldeinformationen geändert wurden. Nach der Überprüfung der Dienste stellte sich heraus, dass keiner davon als Benutzer ausgeführt wird (alle werden als lokales System, lokaler Dienst oder Netzwerkdienst ausgeführt und erscheinen in den Protokollen als SYSTEM-Benutzer).
Die Richtlinie wurde nicht auf die Benutzer angewendet und wir mussten in einigen dringenden Fällen manuell umgangen werden. Der Betrieb gpupdateauf DC2führt zu keinen Fehlern, also dachten wir als letzten Ausweg darüber nach, FSMO-Rollen auf zu übertragen DC2und es zu entfernen DC1und neu zu formatieren (oder was auch immer verzweifelte Administratoren heutzutage tun :D). Gerade haben wir die Rollen übertragen und der Betrieb gpupdate(und gpupdate /force) führt immer noch zu demselben Fehler in , DC1läuft aber reibungslos in DC2. Die Richtlinie wurde jedoch nicht angewendet. Was ist das Problem und wo liegen wir falsch? Und wie können wir das beheben?
PS: Ich habe auch den DNS doppelt geprüft und den Best Practice Analyzer für Active Directory-Rollen verwendet, aber er hat mir nur ein paar Warnungen bezüglich fehlender Sicherungen und einen Fehler bezüglich der Einstellung der Zeitsynchronisierung angezeigt.
AKTUALISIEREN: Jemand hat eine Antwort gepostet (die kurz darauf gelöscht wurde), dass er/sie das gleiche Problem hatte und ob wir eine Lösung gefunden haben. Nein, haben wir nicht, wir haben nur die miese App ersetzt, die diese Gruppenrichtlinie benötigte.
Antwort1
Löschen Sie die zwischengespeicherten Anmeldeinformationen auf dem Computer.
rundll32.exe keymgr.dll,KRShowKeyMgr
Domänenanmeldeinformationen löschen
- psexec herunterladen
Führen Sie cmd als System aus
c:\PSTools>psexec -i -s cmd.exe PsExec v2.2 - Execute processes remotely Copyright (C) 2001-2016 Mark Russinovich Sysinternals - www.sysinternals.com Microsoft Windows [Version 10.0.14393] (c) 2016 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoami nt authority\system
Wenn Sie die Windows-Registrierung mit Berechtigungen auf Systemebene starten und zu „HKEY_LOCAL_MACHINE\SECURITY\CACHE“ navigieren, finden Sie insgesamt 10 Einträge, beginnend bei NL1 bis NL10. Diese binären Einträge enthalten zwischengespeicherte Benutzeranmeldeinformationen auf Domänenebene. Standardmäßig erlaubt Windows die Zwischenspeicherung von insgesamt 10 Anmeldeinformationen. Wenn alle 10 Einträge voll sind, werden alle neuen zwischenzuspeichernden Anmeldeinformationen durch das Wertdatum im ältesten NL-Eintrag überschrieben. Um zu wissen, wie viele freie Einträge übrig sind, zählen Sie einfach die Anzahl der Einträge, deren binäre Wertdaten voll mit „0“ sind.