Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird beschrieben, wie Sie ein Problem identifizieren und beheben, bei dem die Ressourcendomäne nach der Installation von Windows-Updates vom Januar 2022 geändert wird.
Gilt für: Configuration Manager (Current Branch)
Symptome
Nachdem Sie Januar 2022 oder höher kumulative Windows-Updates auf einem Configuration Manager-Standortserver installiert haben, wird möglicherweise der Domänenname geändert, der Benutzern, Gruppen oder Geräten zugeordnet ist. Dieses Problem tritt auf, wenn sich der NetBIOS-Domänenname (auch als Vor-Windows 2000-Domänenname bezeichnet) vom ersten Element des vollqualifizierten Domänennamens (FQDN) unterscheidet.
Beispielsweise befindet sich eine Ressource in einer Domäne mit dem NetBIOS-Domänennamen AAA
, aber mit dem FQDN BBB.contoso.com
. Die Ressource wird als AAA\User1
oder AAA\Computer1
. Nach der Installation von Windows-Updates vom Januar 2022 und der Ermittlung kann der Ressourcenname in oder BBB\Computer1
geändert BBB\User1
werden.
Der Domänenname der Ressource kann zwischen AAA
und BBB
, die Geräte zu Sammlungen entfernt oder hinzugefügt, die Abfrageregeln basierend auf einer Domänenmitgliedschaft enthalten.
Notiz
Direkte Mitgliedschaftsregeln sind nicht betroffen.
Ursache
Im Januar 2022 haben Windows-Updates einen NTLM-Fallback eingeführt, der die NTLM-Authentifizierung blockieren kann , wenn die Kerberos-Authentifizierung nicht erfolgreich ist, wodurch das Verhalten in configuration Manager current branch geändert wird.
Lösung
Dieses Problem wurde in Configuration Manager current branch, Version 2203, behoben.
Wenn das Problem nach dem Upgrade auf Version 2203 und höher weiterhin auftritt, stellen Sie sicher, dass Sie die Anforderungen für die Einrichtung der Kerberos-Verbindung vom Standortserver zu den Domänencontrollern der Zieldomäne erfüllen. Zum Beispiel:
TCP-Datenverkehr an Port 88 (Kerberos) ist zulässig.
TCP- und UDP-Datenverkehr am Port 389 (LDAP und CLDAP) ist zulässig.
Der Standortserver kann SRV-Einträge (Service Location Location) für Kerberos-Dienste auflösen. Zum Beispiel:
_kerberos._tcp.contoso.com _kerberos._udp.contoso.com _kerberos._tcp.dc._msdcs.contoso.com
Problemumgehung
Um dieses Problem zu umgehen, ändern Sie Sammlungsregeln so, dass sie sowohl den NetBIOS-Domänennamen als auch den DNS-Domänennamen enthalten. Zum Beispiel:
select * from SMS_R_System where SMS_R_System.SystemGroupName in ("AAA\\Group1","BBB\\Group1")
Identifizieren des Problems
Hier sind die Schritte zum Überprüfen von Protokollen und Zur Identifizierung des Problems:
Erhöhen Sie die Größe der ADSgDis.log-Datei auf 100 MB (MB) oder mehr, um eine vollständige Active Directory-Gruppenermittlung zu berücksichtigen. Ändern Sie unter dem folgenden Registrierungsschlüssel den
MaxFileSize
Registrierungswert in104857600
(der Standardwert ist2621440
).HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_AD_SECURITY_GROUP_DISCOVERY_AGENT
Aktivieren Sie die ausführliche Protokollierung für die ADSgDis.log Datei. Ändern Sie unter dem folgenden Registrierungsschlüssel den
Verbose Logs
Registrierungswert in1
(der Standardwert ist0
).HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_AD_SECURITY_GROUP_DISCOVERY_AGENT
Führen Sie eine vollständige Active Directory-Gruppenermittlung aus, und stellen Sie sicher, dass die folgende Meldung nach Abschluss in der ADSgDis.log Datei protokolliert wird.
INFO: Succeeded running full sync stored procedure
Filtern Sie nach der Thread-ID, die die obige Nachricht protokolliert hat, und suchen Sie die folgende Nachricht in den gefilterten Protokollen.
VERBOSE : Could not get Domain Name using DSCrackNames, will parse ADs Path to get it
Überprüfen Sie die folgenden Zeilen. Sie finden eine Gruppe und sein Mitglied aus verschiedenen Domänen.
INFO: DDR was written for group 'contoso\ParentGroup' - C:\ConfigMgr\inboxes\auth\ddm.box\userddrsonly\asg1607o.DDR at <Date Time>.~ VERBOSE: group has 1 members~ ... VERBOSE: Domain controller name for the SID is: \\DC.fourthcoffee.local VERBOSE: full ADs path of member: LDAP://DC.fourthcoffee.local/CN=ChildGroup,CN=Users,DC=fourthcoffee,DC=local~ ... VERBOSE: Could not get Domain Name using DSCrackNames, will parse ADs Path to get it VERBOSE: ParentGroup: "contoso\ParentGroup" ChildGroup: "fourthcoffee\ChildGroup"
Überprüfen Sie die Windows-Systemereignisprotokolle der zeitkorrelierten Ereignis-ID 40970 wie folgt. Sie finden den Domänencontroller des Dienstprinzipalnamens (Service Principal Name, SPN), und der Bereich stammt aus verschiedenen Domänen. Dieses Ereignis kann nicht auftreten, wenn der Kerberos-Authentifizierungsversuch zwischengespeichert wird.
The Security System has detected a downgrade attempt when contacting the 3-part SPN LDAP/DC.contoso.local/fourthcoffee.LOCAL with error code "The SAM database on the Windows Server does not have a computer account for this workstation trust relationship. (0xc000018b)". Authentication was denied.
Wenn ja, haben Sie das Problem erfolgreich identifiziert.
Weitere Informationen
Dieses Problem kann auch auftreten, wenn die Option "Objekte in Active Directory-Gruppen entdecken" in den System- oder User Discovery-Bereichseinstellungen aktiviert ist. In diesem Fall sind hier die Schritte zum Überprüfen von Protokollen und Zur Identifizierung des Problems aufgeführt. Sie können die Option für die Ermittlungsbereiche, in denen Sie Gruppen mit Mitgliedern aus anderen Domänen haben, vorübergehend deaktivieren.
Erhöhen Sie die Größe der ADSysDis.log - oder ADUsrDis.log-Datei auf 100 MB (MB) oder mehr, um ein vollständiges Active Directory-System oder eine vollständige Benutzerermittlung zu berücksichtigen. Ändern Sie unter einem der folgenden Registrierungsschlüssel den
MaxFileSize
Registrierungswert in104857600
(der Standardwert ist2621440
).HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_AD_SYSTEM_DISCOVERY_AGENT
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_AD_USER_DISCOVERY_AGENT
Aktivieren Sie die ausführliche Protokollierung für die datei ADSysDis.log oder ADUsrDis.log . Ändern Sie unter einem der folgenden Registrierungsschlüssel den
Verbose Logs
Registrierungswert in1
(der Standardwert ist0
).HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_AD_SYSTEM_DISCOVERY_AGENT
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_AD_USER_DISCOVERY_AGENT
Führen Sie ein vollständiges Active Directory-System oder eine vollständige Benutzerermittlung aus, und stellen Sie sicher, dass die folgende Meldung nach Abschluss in der ADSysDis.log - oder ADUsrDis.log-Datei protokolliert ist.
INFO: CADSource::fullSync returning 0x00000000~
Filtern Sie nach der Thread-ID, die die obige Nachricht protokolliert hat, und suchen Sie die folgende Nachricht in den gefilterten Protokollen.
VERBOSE : Could not get Domain Name using DSCrackNames, will parse ADs Path to get it
Überprüfen Sie die folgenden Zeilen. Sie finden eine Gruppe und sein Mitglied aus verschiedenen Domänen.
INFO: Processing discovered group object with ADsPath = 'LDAP://DC1.CONTOSO.COM/CN=GROUP1,OU=OU,DC=CONTOSO,DC=COM'~ VERBOSE: group not found in discovered group list~ VERBOSE: Bound to group.~ VERBOSE: group has 3 members~ ... VERBOSE: full ADs path of member: LDAP://DC2.fourthcoffee.com/CN=Machine1,OU=US,DC=fourthcoffee,DC=com~ ... VERBOSE: Could not get Domain Name using DsCrackNames, will parse ADs Path to get it VERBOSE: domain = 'FourthCoffee' full domain name = 'fourthcoffee.com' INFO: DDR was written for system 'Machine1' - C:\ConfigMgr\inboxes\auth\ddm.box\adsqznjr.DDR at <Date Time>.~
Wenn ja, haben Sie das Problem erfolgreich identifiziert.