Nem megfelelő hozzáférési jogosultságokkal kapcsolatos hibák elhárítása

Probléma

Az Active Directory-ba történő bejövő felhasználó kiépítés a legtöbb felhasználónál a várt módon működik. Egyes felhasználók esetében azonban a kiépítési naplók a következő hibát jelenítik meg:

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.

A kiépítési naplók a következő hibakódot jelenítik meg: HybridSynchronizationActiveDirectoryInsufficientAccessRights.

Oka

A kiépítési ügynök GMSA-fiókja provAgentgMSA$ alapértelmezés szerint olvasási/írási engedéllyel rendelkezik a tartomány összes felhasználói objektumához. Két lehetséges ok vezethet a korábban megadott hibához.

  • 1. ok: A felhasználói objektum egy szervezeti egység része, amely nem örökli a tartományszintű engedélyeket.
  • 2. ok: A felhasználói objektum védett Active Directory-csoporthoz tartozik. A felhasználói objektumokat kialakításuk szerint egy speciális, úgynevezett AdminSDHoldertárolóhoz társított engedélyek szabályozzák. Ez megmagyarázza, hogy a provAgentgMSA$ fiók miért nem tudja frissíteni a védett Active Directory-csoportokhoz tartozó fiókokat. Megpróbálhatja felülbírálni és explicit módon megadni a fiók írási provAgentgMSA$ hozzáférését a felhasználói fiókokhoz, de ez nem fog működni. Annak érdekében, hogy a kiemelt felhasználói fiókok védettek legyenek a delegált engedélyekkel való visszaéléstől, van egy SDProp nevű háttérfolyamat, amely 60 percenként fut, és biztosítja, hogy a védett csoporthoz tartozó felhasználókat mindig a AdminSDHolder tárolóban meghatározott engedélyek felügyeljék. Még a fiók tartományi rendszergazdai csoporthoz való hozzáadásának provAgentgMSA$ módszere sem fog működni.

Rezolúció

Először ellenőrizze, hogy mi okozza a problémát. Annak ellenőrzése, hogy az 1. ok-e a probléma forrása:

  1. Nyissa meg az Active Directory – Felhasználók és számítógépek felügyeleti konzolt.
  2. Válassza ki a felhasználóhoz társított szervezeti egységet.
  3. Kattintson a jobb gombbal, és lépjen a Tulajdonságok –> Biztonság –> Speciális elemre. Ha megjelenik az Öröklés engedélyezése gomb, az megerősíti, hogy az 1. ok a probléma forrása.
  4. Válassza az Öröklés engedélyezése lehetőséget , hogy a tartományszintű engedélyek alkalmazhatók legyenek erre a szervezeti egységre.

    Megjegyzés:

    Ne felejtse el ellenőrizni a teljes hierarchiát a tartományszinttől egészen az érintett fiókokat tartalmazó szervezeti egységig. Minden szülő-szervezeti egységnek/tárolónak engedélyeznie kell az öröklést, hogy a tartomány szintjén alkalmazott engedélyek átöröklődjenek a végső objektumra.

Ha az 1. ok nem a probléma forrása, akkor lehetséges, hogy a 2. ok a probléma forrása. Két lehetséges megoldási lehetőség közül választhat.

1. lehetőség: Az érintett felhasználó eltávolítása a védett AD-csoportból Az engedély AdminSDHolder által szabályozott felhasználók listájának megkereséséhez a Cx a következő parancsot hívhatja meg:

Get-AdObject -filter {AdminCount -gt 0}

Referenciacikkek:

  • Íme egy példa PowerShell-szkript , amellyel törölheti az AdminCount jelzőt, és újra engedélyezheti az öröklést az érintett felhasználókon.
  • A cikkben dokumentált lépéseket követve – Árva fiókok keresése árva fiókok kereséséhez (azok a fiókok, amelyek nem tartoznak védett csoporthoz, de az AdminCount jelölő értéke továbbra is 1)

Előfordulhat, hogy az 1. lehetőség nem mindig működik

Van egy biztonsági leíró propagálási (SDPROP) folyamat, amely óránként fut a PDC emulátor FSMO-szerepkörrel rendelkező tartományvezérlőn. Ez a folyamat állítja be az AdminCount attribútumot 1 értékre. Az SDPROP fő funkciója a magas jogosultságú Active Directory-fiókok védelme. Biztosítja, hogy ezek a fiókok ne törölhetők, és ne módosíthassák a jogosultságaikat véletlenül vagy szándékosan a kevésbé jogosultsággal rendelkező felhasználók vagy folyamatok. Van egy biztonsági leíró propagálási (SDPROP) folyamat, amely óránként fut a PDC emulátor FSMO-szerepkörrel rendelkező tartományvezérlőn. Ez a folyamat állítja be az AdminCount attribútumot 1 értékre. Az SDPROP fő funkciója a magas jogosultságú Active Directory-fiókok védelme. Az SDPROP-folyamat biztosítja, hogy a fiókok ne törölhetők, ne legyenek jogosultságaik véletlenül vagy szándékosan módosítva a felhasználók vagy a kevésbé jogosultsággal rendelkező folyamatok által.

Hivatkozási cikkek, amelyek részletesen ismertetik az okot:

2. lehetőség: Az AdminSDHolder tároló alapértelmezett engedélyeinek módosítása

Ha az 1. lehetőség nem megvalósítható, és nem a várt módon működik, kérje meg a Cx-et, hogy kérdezze meg az AD rendszergazdáját és a biztonsági rendszergazdát, hogy módosíthatja-e a AdminSDHolder tároló alapértelmezett engedélyeit. Ez a cikk ismerteti a tároló fontosságát AdminSDHolder . Miután a Cx belső jóváhagyást kap a AdminSDHolder tárolóengedélyek frissítéséhez, kétféleképpen frissítheti az engedélyeket.

  • A(z) ADSIEdit használata, ahogy ebben a cikkben le van írva.
  • DSACLS parancssori szkript használata. Íme egy példaszkript, amely kiindulási pontként használható, és a Cx a követelményeknek megfelelően módosíthatja azt.

$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

Ha a Cxnek további segítségre van szüksége a helyszíni AD-engedélyek hibaelhárításához, forduljon a Windows Server támogatási csapatához. Ez a cikk a Microsoft Entra Connect AdminSDHolder-problémáiról további példákat mutat be a DSACLS használatára kapcsolatban.

3. lehetőség: Teljes hozzáférés hozzárendelése a provAgentgMSA-fiókhoz

Teljes hozzáférésű engedélyek hozzárendelése a provAgentGMSA fiókhoz. Ezt a lépést akkor javasoljuk, ha problémák lépnek fel a felhasználói objektumok egyik tároló szervezeti egységből a másikba való áthelyezésével kapcsolatban, ha a felhasználói objektum nem védett felhasználói csoporthoz tartozik.

Ebben a forgatókönyvben kérje meg a Cxet, hogy végezze el az alábbi lépéseket, és tesztelje újra az áthelyezési műveletet.

  1. Jelentkezzen be rendszergazdaként az AD tartományvezérlőbe.
  2. Nyissa meg a PowerShell parancssorát run rendszergazdaként.
  3. A PowerShell-parancssorban futtassa a következő DSACLS-parancsot , amely általános all/full control szolgáltatást biztosít a kiépítési ügynök GMSA-fiókjának. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Cserélje le a dc=contoso,dc=com elemet a gyökércsomópontra vagy a megfelelő OU-konténerre. Ha egyéni GMSA-t használ, frissítse a DN értékét provAgentgMSA.

4. lehetőség: A GMSA-fiók kihagyása és a manuálisan létrehozott szolgáltatásfiók használata Ez a lehetőség csak ideiglenes megoldásként használható a letiltás feloldásához, amíg a GMSA engedélyproblémáját ki nem vizsgálja és meg nem oldja. Javasoljuk, hogy használja a GMSA-fiókot. A beállításjegyzék beállításával kihagyhatja a GMSA-konfigurációt , és újrakonfigurálhatja a Microsoft Entra Connect kiépítési ügynököt, hogy a megfelelő engedélyekkel rendelkező, manuálisan létrehozott szolgáltatásfiókot használjon.

Következő lépések

  • Last updated on