Freigeben über

Problembehandlung eines Fehlers wegen unzureichender Zugriffsrechte

  • Artikel

Problem

Die eingehende Benutzerbereitstellung in Active Directory funktioniert für die meisten Benutzer*innen wie erwartet. Für einige Benutzer*innen wird jedoch in den Bereitstellungsprotokollen der folgende Fehler angezeigt:

ERROR: InsufficientAccessRights-SecErr: The user has insufficient access rights.. Access is denied. \nError Details: Problem 4003 - INSUFF_ACCESS_RIGHTS. 
OR

ERROR: 
"Message":"The user has insufficient access rights.",
"ResponseResultCode":"InsufficientAccessRights",
"ResponseErrorMessage":"00002098: SecErr: DSID-03150F94, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0",
The user has insufficient access rights.

Die Bereitstellungsprotokolle zeigen folgenden Fehlercode an: HybridSynchronizationActiveDirectoryInsufficientAccessRights.

Ursache

Das GMSA-Konto provAgentgMSA$ des Bereitstellungs-Agents verfügt standardmäßig über Lese-/Schreibberechtigungen für alle Benutzerobjekte in der Domäne. Zwei mögliche Ursachen können zu dem oben genannten Fehler führen.

  • Ursache 1: Das Benutzerobjekt ist Teil einer Organisationseinheit, die keine Berechtigungen auf Domänenebene erbt.
  • Ursache 2: Das Benutzerobjekt gehört zu einer geschützten Active Directory-Gruppe. Benutzerobjekte werden entwurfsbedingt durch Berechtigungen gesteuert, die einem speziellen Container namens AdminSDHolder zugeordnet sind. Dies erklärt, warum das provAgentgMSA$-Konto die Konten, die zu geschützten Active Directory-Gruppen gehören, nicht aktualisieren kann. Sie können versuchen, dies zu überschreiben und dem provAgentgMSA$-Konto explizit Schreibzugriff auf Benutzerkonten zu gewähren, doch dies wird nicht funktionieren. Um privilegierte Benutzerkonten vor einem Missbrauch delegierter Berechtigungen zu schützen, gibt es einen Hintergrundprozess namens SDProp, der alle 60 Minuten ausgeführt wird und sicherstellt, dass Benutzer*innen, die zu einer geschützten Gruppe gehören, immer von Berechtigungen verwaltet werden, die für den AdminSDHolder-Container definiert sind. Selbst der Ansatz, das provAgentgMSA$-Konto der Gruppe „Domänenadministrator“ hinzuzufügen, funktioniert nicht.

Lösung

Überprüfen Sie zunächst, wodurch das Problem verursacht wird. So überprüfen Sie, ob Ursache 1 die Problemursache darstellt:

  1. Öffnen Sie die Verwaltungskonsole Active Directory-Benutzer und -Computer.
  2. Wählen Sie die dem Benutzer zugeordnete Organisationseinheit aus.
  3. Drücken Sie die rechte Maustaste, und navigieren Sie zu Eigenschaften –> Sicherheit –> Erweitert. Wenn die Schaltfläche Vererbung aktivieren angezeigt wird, bestätigt dies, dass Cause-1 die Quelle des Problems ist.
  4. Klicken Sie auf Vererbung aktivieren, damit die Berechtigungen auf Domänenebene für diese Organisationseinheit gelten.

    Hinweis

    Denken Sie daran, die gesamte Hierarchie von der Domänenebene bis hinunter zur Organisationseinheit mit den betroffenen Konten zu überprüfen. Für alle übergeordneten Organisationseinheiten/Container muss die Vererbung aktiviert sein, damit die Berechtigungen, die auf Domänenebene gelten, an das endgültige Objekt vererbt werden.

Wenn Ursache 1 nicht die Problemursache ist, dann stellt möglicherweise Ursache 2 die Problemursache dar. Es gibt zwei mögliche Lösungsoptionen.

Option 1: Entfernen der betroffenen Benutzer aus der geschützten AD-Gruppe Um die Liste der Benutzer zu finden, für welche diese AdminSDHolder-Berechtigung gilt, kann Cx den folgenden Befehl aufrufen:

Get-AdObject -filter {AdminCount -gt 0}

Referenzartikel:

  • Hier sehen Sie ein PowerShell-Beispielskript, das verwendet werden kann, um das AdminCount-Flag zu löschen und die Vererbung für die betroffenen Benutzer*innen erneut zu aktivieren.
  • Führen Sie die in dem Artikel: Suchen verwaister Konten beschriebenen Schritte aus, um nach verwaisten Konten zu suchen (Konten, die nicht Teil einer geschützten Gruppe sind, bei denen aber weiterhin das AdminCount-Flag auf 1 festgelegt ist).

Option 1 funktioniert möglicherweise nicht immer

Es gibt einen Prozess namens „Security Descriptor Propagation“ (SDPROP), der stündlich auf dem Domänencontroller mit der FSMO-Rolle des PDC-Emulators ausgeführt wird. Dieser Prozess legt das AdminCount-Attribut auf 1 fest. Die Hauptfunktion von SDPROP besteht darin, Active Directory-Konten, die über umfassende Berechtigungen verfügen, zu schützen, indem sichergestellt wird, dass sie nicht von Benutzer*innen oder Prozessen mit weniger Berechtigungen gelöscht oder ihre Rechte versehentlich oder absichtlich geändert werden können. Es gibt einen Prozess namens „Security Descriptor Propagation“ (SDPROP), der stündlich auf dem Domänencontroller mit der FSMO-Rolle des PDC-Emulators ausgeführt wird. Dieser Prozess legt das AdminCount-Attribut auf 1 fest. Die Hauptfunktion von SDPROP besteht darin, hoch privilegierte Active Directory-Konten zu schützen. Der SDPROP-Prozess stellt sicher, dass Konten nicht gelöscht oder Rechte versehentlich oder absichtlich von Benutzern oder Prozessen mit weniger Berechtigungen geändert werden können.

Referenzartikel, in denen der Grund ausführlich erläutert wird:

Option 2: Ändern der Standardberechtigungen des AdminSDHolder-Containers

Wenn Option 1 nicht umsetzbar ist und nicht wie erwartet funktioniert, bitten Sie Cx, sich beim AD-Administrator und den Sicherheitsadministratoren zu erkundigen, ob sie die Standardberechtigungen des AdminSDHolder-Containers ändern dürfen. In diesem Artikel wird die Bedeutung des AdminSDHolder-Containers erläutert. Sobald Cx die interne Genehmigung zum Aktualisieren der AdminSDHolder-Containerberechtigungen erhalten hat, können die Berechtigungen auf zweierlei Weise aktualisiert werden.

  • Mit ADSIEdit, wie in diesem Artikel beschrieben.
  • Mit dem Befehlszeilenskript DSACLS. Hier sehen Sie ein Beispielskript, das als Ausgangspunkt dienen könnte. Cx kann es gemäß ihren Anforderungen anpassen.

$dcFQDN = "<FQDN Of The Nearest RWDC Of Domain>"
$domainDN = "<Domain Distinguished Name>"
$domainNBT = "<Domain NetBIOS Name>"
$dsaclsCMD = "DSACLS '\\$dcFQDN\CN=AdminSDHolder,CN=System,$domainDN' /G '$domainNBT\provAgentgMSA$:RPWP;<Attribute To Write To>'"
Invoke-
Expression $dsaclsCMD | Out-Null

Wenn Cx weitere Hilfe bei der Behandlung von Problemen mit lokalen AD-Berechtigungen benötigt, wenden Sie sich an das Windows Server-Supportteam. Dieser Artikel zu AdminSDHolder-Problemen mit Microsoft Entra Connect enthält weitere Beispiele zur DSACLS-Syntax.

Option 3: Zuweisen der vollständigen Kontrolle zum provAgentgMSA-Konto

Weisen Sie dem provAgentGMSA-Konto die Berechtigungen Vollzugriff zu. Wir empfehlen diesen Schritt, wenn es Probleme mit dem Verschieben eines Benutzerobjekts von einer Container-OE in eine andere gibt, wenn das Benutzerobjekt nicht zu einer geschützten Benutzergruppe gehören.

Bitten Sie Cx in diesem Szenario, die folgenden Schritte auszuführen, und probieren Sie den Verschiebungsvorgang erneut.

  1. Melden Sie sich als Administrator beim AD-Domänencontroller an.
  2. Öffnen der PowerShell-Befehlszeile mit run als Administrator.
  3. Führen Sie an der PowerShell-Eingabeaufforderung den folgenden DSACLS-Befehl aus, der dem GMSA-Konto des Bereitstellungs-Agents Allgemein Alle/Vollzugriff gewährt. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Ersetzen Sie dc=contoso,dc=com durch Ihren Stammknoten oder den entsprechenden OE-Container. Wenn Sie ein benutzerdefiniertes GMSA verwenden, aktualisieren Sie den DN-Wert für provAgentgMSA.

Option 4: Überspringen eines GMSA-Kontos und Verwenden eines manuell erstellten Dienstkontos Diese Option sollte nur als temporäre Problemumgehung verwendet werden, um die Blockierung aufzuheben, bis das GMSA-Berechtigungsproblem untersucht und behoben worden ist. Wir empfehlen, das GMSA-Konto zu verwenden. Sie können die Registrierungsoption festlegen, um die GMSA-Konfiguration zu überspringen und den Microsoft Entra Connect-Bereitstellungs-Agent neu zu konfigurieren, sodass ein manuell erstelltes Dienstkonto mit den richtigen Berechtigungen verwendet wird.

Nächste Schritte