Dela via

Felsöka fel med otillräckliga åtkomsträttigheter

Problematik

Inkommande användaretablering till Active Directory fungerar som förväntat för de flesta användare. Men för vissa användare visar etableringsloggarna följande fel:

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.

Etableringsloggarna visar felkoden: HybridSynchronizationActiveDirectoryInsufficientAccessRights.

Orsak

GMSA-kontot provAgentgMSA$ för konfigurationsagenten har som standard läs-/skrivbehörighet till alla användarobjekt i domänen. Det finns två möjliga orsaker som kan leda till det tidigare angivna felet.

  • Orsak-1: Användarobjektet är en del av en organisationsenhet som inte ärver behörigheter på domännivå.
  • Orsak-2: Användarobjektet tillhör en skyddad Active Directory-grupp. Avsiktligt styrs användarobjekt av behörigheter som är associerade med en särskild container med namnet AdminSDHolder. Detta förklarar varför provAgentgMSA$ kontot inte kan uppdatera dessa konton som tillhör skyddade Active Directory-grupper. Du kan försöka åsidosätta detta och ge kontot uttryckligen skrivbehörighet till användarkonton, men det kommer inte att fungera. För att skydda privilegierade användarkonton från missbruk av delegerade behörigheter finns det en bakgrundsprocess som kallas SDProp som körs var 60:e minut och ser till att användare som tillhör en skyddad grupp alltid hanteras av behörigheter som definierats i containern AdminSDHolder . Inte ens metoden att lägga till provAgentgMSA$ kontot i gruppen Domänadministratör fungerar.

Lösning / Beslut

Bekräfta först vad som orsakar problemet. Så här kontrollerar du om orsak 1 är orsaken till problemet:

  1. Öppna Hanteringskonsolen för Active Directory-användare och datorer.
  2. Välj den organisationsenhet som är associerad med användaren.
  3. Högerklicka och navigera till Egenskaper –> Säkerhet –> Avancerat. Om knappen Aktivera arv visas bekräftar den att Orsak-1 är orsaken till problemet.
  4. Välj Aktivera arv så att behörigheter på domännivå gäller för den här organisationsenheten.

    Anmärkning

    Kom ihåg att kontrollera hela hierarkin från domännivå ned till den organisationsenhet som innehåller de berörda kontona. Alla överordnade organisationsenheter/containrar måste ha behörighetsarv aktiverat så att de behörigheter som är tillämpade på domännivå kan flöda ner till det slutliga objektet.

Om Orsak-1 inte är orsaken till problemet är potentiellt Orsak-2 orsaken till problemet. Det finns två möjliga lösningsalternativ.

Alternativ 1: Ta bort berörd användare från skyddad AD-grupp För att hitta listan över användare som styrs av den här AdminSDHolder behörigheten kan Cx anropa följande kommando:

Get-AdObject -filter {AdminCount -gt 0}

Referensartiklar:

  • Här är ett exempel på ett PowerShell-skript som kan användas för att rensa administratörskontoflaggan och återaktivera arv för berörda användare.
  • Använd stegen som beskrivs i den här artikeln – Hitta överblivna konton för att hitta överblivna konton (konton som inte ingår i en skyddad grupp, men som fortfarande har flaggan AdminCount inställd på 1)

Alternativ 1 kanske inte alltid fungerar

Det finns en process som kallas SDPROP-processen (Security Descriptor Propagation) som körs varje timme på domänkontrollanten som innehar PDC-emulatorns FSMO-roll. Det är den här processen som anger attributet AdminCount till 1. Huvudfunktionen i SDPROP är att skydda active directory-konton med hög behörighet. Det säkerställer att dessa konton inte kan tas bort eller att deras rättigheter ändras, antingen oavsiktligt eller avsiktligt, av användare eller processer med mindre behörighet. Det finns en process som kallas SDPROP-processen (Security Descriptor Propagation) som körs varje timme på domänkontrollanten som innehar PDC-emulatorns FSMO-roll. Det är den här processen som anger attributet AdminCount till 1. Huvudfunktionen i SDPROP är att skydda active directory-konton med hög behörighet. SDPROP-processen säkerställer att konton inte kan tas bort eller har rättigheter som oavsiktligt eller avsiktligt ändras av användare eller processer med mindre behörighet.

Referensartiklar som förklarar orsaken i detalj:

Alternativ 2: Ändra standardbehörigheterna för containern AdminSDHolder

Om alternativ 1 inte är genomförbart och inte fungerar som förväntat ber du Cx att kontakta ad-administratören och säkerhetsadministratörerna om de får ändra standardbehörigheterna för containern AdminSDHolder . Den här artikeln förklarar containerns AdminSDHolder betydelse. När Cx får internt godkännande för att uppdatera AdminSDHolder containerbehörigheterna finns det två sätt att uppdatera behörigheterna.

  • Använd ADSIEdit enligt beskrivningen i den här artikeln.
  • Använda DSACLS kommandoradsskript. Här är ett exempelskript som kan användas som utgångspunkt och Cx kan justera det enligt deras krav.

$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

Om Cx behöver mer hjälp med att felsöka lokala AD-behörigheter kan du kontakta Windows Server-supportteamet. Den här artikeln om AdminSDHolder-problem med Microsoft Entra Connect innehåller fler exempel på DSACLS-användning.

Alternativ 3: Tilldela fullständig kontroll till provAgentgMSA-kontot

Tilldela fullständig behörighet till provAgentGMSA kontot. Vi rekommenderar det här steget om det finns problem med att flytta ett användarobjekt från en container-OU till en annan när användarobjektet inte tillhör en skyddad användargrupp.

I det här scenariot ber du Cx att utföra följande steg och testa flyttåtgärden igen.

  1. Logga in på AD-domänkontrollanten som administratör.
  2. Öppna PowerShell-kommandoraden med run som administratör.
  3. I PowerShell-prompten kör du följande DSACLS-kommando som beviljar allmän all/fullständig kontroll till etableringsagentens GMSA-konto. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Ersätt dc=contoso,dc=com med din rotnod eller lämplig OU-container. Om du använder en anpassad GMSA uppdaterar du DN-värdet för provAgentgMSA.

Alternativ 4: Hoppa över GMSA-konto och använd manuellt skapat tjänstkonto Det här alternativet bör endast användas som en tillfällig lösning för att avblockera tills GMSA-behörighetsproblemet har undersökts och lösts. Vår rekommendation är att använda GMSA-kontot. Du kan ange registeralternativet för att hoppa över GMSA-konfigurationen och konfigurera om Microsoft Entra Connect-etableringsagenten för att använda ett manuellt skapat tjänstkonto med rätt behörigheter.

Nästa steg

  • Last updated on