Dela via

Program som använder NetUserGetInfo och liknande API:er förlitar sig på läsåtkomst till vissa AD-objekt

  • Artikel

I den här artikeln beskrivs ett problem där program som använder API:er på nednivå för klassen NetUser eller NetGroup gillar NetUserGetInfo eller NetGroupGetInfo misslyckas med felet ÅTKOMST NEKAD.

Ursprungligt KB-nummer: 2281774

Sammanfattning

Du har ett program som använder API:er på nednivå för klassen NetUser eller NetGroup som NetUserGetInfo, NetUserSetInfo, NetUserEnum, NetGroupGetInfo, NetGroupSetInfo, NetGroupEnum, NetLocalGroupGetInfo, NetLocalGroupSetInfooch NetLocalGroupEnum. I det här schemat används ÄVEN NETUser-klass-API:er för att hantera datorkonto.

Samma API:er används när du anropar ADSI WINNT-providern.

Dessa API:er kan misslyckas med ÅTKOMST NEKAD även om det anropande kontot har tillräcklig behörighet för målkontona. Anledningen till detta är att API-implementeringen på klientsidan inte har en 1:1-relation med RPC-API:er (Security Account Manager) (SAM). Klientsidan utför ytterligare kontroller och förberedelser för dessa anrop som kräver ytterligare behörigheter i Active Directory.

Ett program som använder dessa API:er är klustertjänsten, och i klustertjänstloggen visas:

00000a78.000021b8::2010/06/15-00:00:47.911 WARN [RES] Nätverksnamn <cluster-resource1>: Det gick inte att avgöra om datorkontot cluster-resource1 redan är inaktiverat. status 5

Ett annat symptom på den här effekten kan vara överdrivna granskningsposter i säkerhetshändelseloggen för dina domänkontrollanter för dessa API-anrop och objekten som anges nedan, om granskning av lyckad eller misslyckad åtkomst för det anropande kontot är aktiverad.

Mer information

Implementeringen av API:erna använder flera RPC-anrop riktade till domänkontrollanten för att konfigurera sessionen och verifiera domänen. Den kommer åt följande objekt med läsbehörighet:

  • Domänrotobjekt: Den söker upp domänkontrollantens primära domän och öppnar domänen för läsning, vilket i sin tur öppnar AD-objektet för domänen, till exempel DC=contoso,dc=com.

  • Inbyggd container: Det här är rotobjektet för den inbyggda domänen. Den öppnas när anroparen vill verifiera dess existens. Anroparen behöver därför läsbehörighet till containern CN=Builtin,DC=contoso,dc=com.

  • SAM-serverobjekt: Det här objektet lagrar allmänna behörigheter om allmän SAM-kontoåtkomst och uppräkning. Den används endast för vissa anrop. Objektnamnet är cn=server,cn=system,DC=contoso,dc=com.

I de flesta Active Directory-domäner beviljas behörigheter till dessa objekt baserat på medlemskapet i allmänna grupper som autentiserade användare, Alla eller gruppen Kompatibel åtkomst före Windows 2000. Ändringen för att utlösa problemet kan ha varit att användaren togs bort från den senaste gruppen (kanske tillsammans med Alla, och/eller behörigheterna för de objekt som visas har tagits bort i ett drag för att härda Active Directory-behörigheterna.

Metoderna för att lösa problemet är att antingen bevilja nödvändiga läsbehörigheter eller ändra programmet så att det använder LDAP i stället för de äldre API:erna eller ADSI WINNT-providern. LDAP kommer inte att röra objekten ovan och det stöder även de detaljerade behörigheter som du kan ha angett för målobjektet.

Överdriven granskning

När du har aktiverat granskning för dessa objekt visas upp till tre granskningsposter för objekten ovan för att både öppna och stänga objekten, plus den faktiska målobjektåtkomsten. Om händelserna loggas för mycket är det klokt att ta bort posterna i gransknings-ACL så att dessa allmänna åtkomsttyper inte loggas längre. Problemet är att domänrotobjektet och den inbyggda containern ärver till många underordnade objekt.

För att lösa detta måste du bryta arvet i den inbyggda containern och omdefiniera de ACL:er som ärver för att endast gälla för det här objektet. Du måste också röra vid ACL:erna på domänrotobjektet så att problemets SACEs inte längre gäller för domänrotobjektet. De exakta stegen beror på de faktiska SACL-inställningarna som gäller i din miljö.