Freigeben über

Fehler bei unzureichenden Zugriffsrechten beheben

Thema

Die eingehende Benutzerbereitstellung in Active Directory funktioniert für die meisten Benutzer erwartungsgemäß. Bei einigen Benutzern werden in den Bereitstellungsprotokollen jedoch die folgenden 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. Es gibt zwei mögliche Ursachen, die zu dem zuvor angegebenen Fehler führen können.

  • Ursache-1: Das Benutzerobjekt ist Teil einer OE, die keine Berechtigungen auf Domänenebene erbt.
  • Ursache 2: Das Benutzerobjekt gehört zu einer geschützten Active Directory-Gruppe. Von der Konzeption her werden Benutzerobjekte durch Berechtigungen gesteuert, die einem speziellen Container zugeordnet sind, der AdminSDHolder genannt wird. Dies erklärt, warum das provAgentgMSA$ Konto diese Konten, die zu geschützten Active Directory-Gruppen gehören, nicht aktualisieren kann. Möglicherweise versuchen Sie, dem provAgentgMSA$-Konto explizit Schreibzugriff auf Benutzerkonten zu gewähren, aber das funktioniert nicht. 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, die zu einer geschützten Gruppe gehören, immer durch berechtigungen verwaltet werden, die für den AdminSDHolder Container definiert sind. Selbst der Ansatz zum Hinzufügen des provAgentgMSA$ Kontos zur Gruppe "Domänenadministrator" funktioniert nicht.

Beschluss

Überprüfen Sie zuerst, was das Problem verursacht. So überprüfen Sie, ob Ursache-1 die Quelle des Problems ist:

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

    Hinweis

    Denken Sie daran, die gesamte Hierarchie von der Domänenebene bis zur Organisationseinheit, die die betroffenen Konten enthält, zu überprüfen. Alle übergeordneten OUs/Container müssen die Vererbung aktiviert haben, sodass die auf Domänenebene angewendeten Berechtigungen bis zum endgültigen Objekt weitervererbt werden können.

Wenn "Ursache-1" nicht die Quelle des Problems ist, dann ist möglicherweise "Ursache-2" die Quelle des Problems. Es gibt zwei mögliche Auflösungsoptionen.

Option 1: Entfernen betroffener Benutzer aus geschützter AD-Gruppe Um die Liste der Benutzer zu finden, die dieser AdminSDHolder Berechtigung unterliegen, kann Cx den folgenden Befehl aufrufen:

Get-AdObject -filter {AdminCount -gt 0}

Referenzartikel:

  • Hier ist ein Beispiel für ein PowerShell-Skript , das verwendet werden kann, um das AdminCount-Flag zu löschen und die Vererbung für betroffene Benutzer erneut zu aktivieren.
  • Führen Sie die in diesem Artikel beschriebenen Schritte aus : "Verwaiste Konten suchen", um verwaiste Konten zu finden (Konten, die nicht Teil einer geschützten Gruppe sind, aber dennoch das Flag "AdminCount" auf "1" festgelegt haben)

Option 1 funktioniert möglicherweise nicht immer

Es gibt einen Prozess namens "Security Descriptor Propagation" (SDPROP), der jede Stunde auf dem Domänencontroller ausgeführt wird, der die Rolle des PDC-Emulator-FSMO innehat. Dieser Prozess legt das AdminCount Attribut auf 1 fest. Die Hauptfunktion von SDPROP besteht darin, hoch privilegierte Active Directory-Konten zu schützen. Es stellt sicher, dass diese Konten nicht gelöscht werden können oder ihre Rechte entweder versehentlich oder absichtlich von Benutzern oder Prozessen mit weniger Berechtigungen geändert werden können. Es gibt einen Prozess namens "Security Descriptor Propagation" (SDPROP), der jede Stunde auf dem Domänencontroller ausgeführt wird, der die Rolle des PDC-Emulator-FSMO innehat. 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, die den Grund im Detail erläutern:

Option 2: Ändern der Standardberechtigungen des AdminSDHolder-Containers

Wenn Option 1 nicht machbar ist und nicht wie erwartet funktioniert, bitten Sie Cx, sich mit ihrem AD-Administrator und sicherheitsadministratoren zu erkundigen, ob sie die Standardberechtigungen des AdminSDHolder Containers ändern dürfen. In diesem Artikel wird die Wichtigkeit des AdminSDHolder Containers erläutert. Sobald Cx die interne Genehmigung zum Aktualisieren der AdminSDHolder Containerberechtigungen erhält, gibt es zwei Möglichkeiten, die Berechtigungen zu aktualisieren.

  • Mit ADSIEdit, wie in diesem Artikel beschrieben.
  • Verwenden Sie das DSACLS Befehlszeilenskript. Im Folgenden finden Sie ein Beispielskript, das als Ausgangspunkt verwendet werden kann, und Cx kann es entsprechend 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 der Cx weitere Hilfe zur Problembehandlung lokaler 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 für die DSACLS-Verwendung.

Option 3: Zuweisen des Vollzugriffs zum provAgentgMSA-Konto

Weisen Sie dem provAgentGMSA Konto Vollzugriffsberechtigungen zu. Dieser Schritt wird empfohlen, wenn Probleme beim Verschieben eines Benutzerobjekts aus einer Container-ORGANISATIONSeinheit in eine andere auftreten, wenn das Benutzerobjekt nicht zu einer geschützten Benutzergruppe gehört.

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

  1. Melden Sie sich als Administrator bei 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 Bereitstellungsagents allgemeine vollständige Kontrolle 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 eine benutzerdefinierte GMSA verwenden, aktualisieren Sie den DN-Wert für provAgentgMSA.

Option 4: Überspringen Des 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 wird. Unsere Empfehlung ist die Verwendung des GMSA-Kontos. Sie können die Registrierungsoption festlegen, um die GMSA-Konfiguration zu überspringen und den Microsoft Entra Connect-Bereitstellungs-Agent neu zu konfigurieren, um ein manuell erstelltes Dienstkonto mit den richtigen Berechtigungen zu verwenden.

Nächste Schritte