Delen via

Problemen met onvoldoende toegangsrechten oplossen

  • Artikel

Probleem

Het inrichten van binnenkomende gebruikers voor Active Directory werkt zoals verwacht voor de meeste gebruikers. Voor sommige gebruikers wordt in de inrichtingslogboeken echter de volgende fout weergegeven:

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.

In de inrichtingslogboeken wordt de foutcode weergegeven: HybridSynchronizationActiveDirectoryInsufficientAccessRights.

Oorzaak

Het GMSA-account provAgentgMSA$ van de inrichtingsagent heeft standaard lees-/schrijfmachtigingen voor alle gebruikersobjecten in het domein. Er zijn twee mogelijke oorzaken die kunnen leiden tot de bovenstaande fout.

  • Oorzaak-1: Het gebruikersobject maakt deel uit van een organisatie-eenheid die geen machtigingen op domeinniveau over neemt.
  • Oorzaak-2: Het gebruikersobject behoort tot een beveiligde Active Directory-groep. Gebruikersobjecten worden standaard beheerd door machtigingen die zijn gekoppeld aan een speciale container met de naam AdminSDHolder. Dit verklaart waarom het provAgentgMSA$ account deze accounts die behoren tot beveiligde Active Directory-groepen niet kan bijwerken. U kunt proberen het account schrijftoegang tot gebruikersaccounts te overschrijven en expliciet op te geven provAgentgMSA$ , maar dat werkt niet. Om bevoegde gebruikersaccounts te beveiligen tegen misbruik van gedelegeerde machtigingen, is er een achtergrondproces met de naam SDProp dat elke 60 minuten wordt uitgevoerd en ervoor zorgt dat gebruikers die tot een beveiligde groep behoren, altijd worden beheerd door machtigingen die zijn gedefinieerd in de AdminSDHolder container. Zelfs de methode voor het toevoegen van het provAgentgMSA$ account aan de groep Domein Beheer werkt niet.

Oplossing

Controleer eerst wat het probleem veroorzaakt. Controleren of Oorzaak-1 de oorzaak van het probleem is:

  1. Open de Active Directory-beheerconsole.
  2. Selecteer de organisatie-eenheid die is gekoppeld aan de gebruiker.
  3. Klik met de rechtermuisknop en navigeer naar Eigenschappen -> Beveiliging -> Geavanceerd. Als de knop Overname inschakelen wordt weergegeven, wordt bevestigd dat Oorzaak-1 de bron van het probleem is.
  4. Klik op Overname inschakelen, zodat machtigingen op domeinniveau van toepassing zijn op deze organisatie-eenheid.

    Notitie

    Vergeet niet om de hele hiërarchie van domeinniveau omlaag te controleren naar de organisatie-eenheid met de betreffende accounts. Alle bovenliggende OE's/containers moeten overname hebben ingeschakeld, zodat de machtigingen die op domeinniveau worden toegepast, trapsgewijs naar het uiteindelijke object kunnen worden gefaseerd.

Als Oorzaak-1 niet de bron van het probleem is, is mogelijk Oorzaak-2 de bron van het probleem. Er zijn twee mogelijke oplossingsopties.

Optie 1: De betrokken gebruiker verwijderen uit beveiligde AD-groep Om de lijst met gebruikers te vinden die onder deze AdminSDHolder machtiging vallen, kan Cx de volgende opdracht aanroepen:

Get-AdObject -filter {AdminCount -gt 0}

Naslagartikelen:

  • Hier volgt een voorbeeld van een PowerShell-script dat kan worden gebruikt om de vlag Beheer Count te wissen en overname opnieuw in te schakelen voor betrokken gebruikers.
  • Gebruik de stappen die in dit artikel worden beschreven: zwevende accounts zoeken om zwevende accounts te vinden (accounts die geen deel uitmaken van een beveiligde groep, maar die nog steeds Beheer Count-vlag zijn ingesteld op 1)

Optie 1 werkt mogelijk niet altijd

Er is een proces met de naam The Security Descriptor Propagation (SDPROP) proces dat elk uur wordt uitgevoerd op de domeincontroller met de FSMO-rol van de PDC-emulator. Dit proces stelt het AdminCount kenmerk in op 1. De belangrijkste functie van SDPROP is het beveiligen van active Directory-accounts met hoge bevoegdheden, zodat ze niet kunnen worden verwijderd of rechten kunnen worden gewijzigd, per ongeluk of opzettelijk, door gebruikers of processen met minder bevoegdheden. Er is een proces met de naam The Security Descriptor Propagation (SDPROP) proces dat elk uur wordt uitgevoerd op de domeincontroller met de FSMO-rol van de PDC-emulator. Dit proces stelt het AdminCount kenmerk in op 1. De belangrijkste functie van SDPROP is het beveiligen van zeer bevoegde Active Directory-accounts. Het SDPROP-proces zorgt ervoor dat accounts niet kunnen worden verwijderd of rechten per ongeluk of opzettelijk kunnen worden gewijzigd door gebruikers of processen met minder bevoegdheden.

Naslagartikelen waarin de reden in detail wordt uitgelegd:

Optie 2: de standaardmachtigingen van de container Beheer SDHolder wijzigen

Als optie 1 niet haalbaar is en niet werkt zoals verwacht, vraagt u Cx om contact op te nemen met hun AD-beheerder en beveiligingsbeheerders als ze de standaardmachtigingen van de AdminSDHolder container mogen wijzigen. In dit artikel wordt het belang van de AdminSDHolder container uitgelegd. Zodra Cx interne goedkeuring krijgt om de AdminSDHolder containermachtigingen bij te werken, zijn er twee manieren om de machtigingen bij te werken.

  • Gebruik ADSIEdit zoals beschreven in dit artikel.
  • Met behulp van DSACLS opdrachtregelscript. Hier volgt een voorbeeldscript dat kan worden gebruikt als uitgangspunt en Cx kan het aanpassen aan hun vereisten.

$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

Als de Cx meer hulp nodig heeft bij het oplossen van problemen met on-premises AD-machtigingen, neemt u contact op met het ondersteuningsteam van Windows Server. Dit artikel over Beheer SDHolder-problemen met Microsoft Entra Verbinding maken bevat meer voorbeelden van DSACLS-gebruik.

Optie 3: Volledig beheer toewijzen aan provAgentgMSA-account

Wijs machtigingen voor volledig beheer toe aan het provAgentGMSA account. We raden deze stap aan als er problemen zijn met het verplaatsen van een gebruikersobject van de ene container-OE naar de andere wanneer het gebruikersobject niet tot een beveiligde gebruikersgroep behoort.

In dit scenario vraagt u Cx om de volgende stappen uit te voeren en de verplaatsingsbewerking opnieuw te testen.

  1. Meld u als beheerder aan bij de AD-domeincontroller.
  2. Open de PowerShell-opdrachtregel met run als beheerder.
  3. Voer bij de PowerShell-prompt de volgende DSACLS-opdracht uit waarmee algemeen alle/volledige controle wordt verleend aan het GMSA-account van de inrichtingsagent. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Vervang het door uw dc=contoso,dc=com hoofdknooppunt of de juiste OE-container. Als u een aangepaste GMSA gebruikt, werkt u de DN-waarde voor provAgentgMSA.

Optie 4: Sla het GMSA-account over en gebruik handmatig gemaakte serviceaccount Deze optie mag alleen worden gebruikt als tijdelijke tijdelijke oplossing om de blokkering op te heffen totdat het probleem met de GMSA-machtiging wordt onderzocht en opgelost. Onze aanbeveling is om het GMSA-account te gebruiken. U kunt de registeroptie instellen om de GMSA-configuratie over te slaan en de Microsoft Entra Verbinding maken inrichtingsagent opnieuw te configureren voor het gebruik van een handmatig gemaakt serviceaccount met de juiste machtigingen.

Volgende stappen