Delen via

Toepassingen die NetUserGetInfo en vergelijkbare API's gebruiken, zijn afhankelijk van leestoegang tot bepaalde AD-objecten

  • Artikel

In dit artikel wordt een probleem besproken waarbij toepassingen die gebruikmaken van downlevel API's van de Klasse NetUser of NetGroup, zoals NetUserGetInfo of NetGroupGetInfo mislukt met de fout ACCESS DENIED.

Oorspronkelijk KB-nummer: 2281774

Samenvatting

U hebt een toepassing die gebruikmaakt van de api's op down-level van de klasse NetUser of NetGroup, zoals NetUserGetInfo, , NetUserSetInfoNetUserEnum, NetGroupGetInfo, NetGroupSetInfo, , NetGroupEnum, , NetLocalGroupGetInfoen .NetLocalGroupEnumNetLocalGroupSetInfo In dit schema worden de NetUser-klasse-API's ook gebruikt voor het beheren van computeraccounts.

Dezelfde API's worden gebruikt wanneer u de ADSI WINNT-provider aanroept.

Deze API's kunnen mislukken met TOEGANG GEWEIGERD, hoewel het aanroepende account voldoende machtigingen heeft voor de doelaccounts. De reden hiervoor is dat de API-implementatie aan de clientzijde geen 1:1-relatie heeft met RPC API's van Security Account Manager (SAM). De clientzijde voert extra controles en voorbereiding uit voor deze aanroepen waarvoor extra machtigingen in Active Directory zijn vereist.

Een toepassing die gebruikmaakt van deze API's is de clusterservice. In het clusterservicelogboek ziet u:

00000a78.000021b8::2010/06/15-00:00:47.911 WARN [RES] Netwerknaam <cluster-resource1>: Kan niet bepalen of computeraccountcluster-resource1 al is uitgeschakeld. status 5

Een ander symptoom van dit effect kan overmatige controlerecords zijn in het beveiligingsgebeurtenislogboek van uw DC's voor deze API-aanroepen en de onderstaande objecten, als de controle van geslaagde of mislukte toegang voor het aanroepende account is ingeschakeld.

Meer informatie

De implementatie van de API's maakt gebruik van meerdere RPC-aanroepen die zijn gericht op de domeincontroller, om de sessie in te stellen en het domein te verifiëren. Deze heeft toegang tot de volgende objecten met leestoegang:

  • Domeinhoofdobject: hiermee wordt het primaire domein van de domeincontroller opgezoekt en wordt het domein geopend voor lezen, waardoor het AD-object voor het domein wordt geopend, zoals DC=contoso,dc=com.

  • Ingebouwde container: dit is het hoofdobject van het ingebouwde domein. Het wordt geopend als de beller het bestaan wil verifiëren. De aanroeper heeft dus leestoegang nodig tot de container CN=Builtin,DC=contoso,dc=com.

  • SAM-serverobject: dit object slaat algemene machtigingen op over algemene toegang tot en opsomming van sam-accounts. Deze wordt alleen gebruikt voor bepaalde oproepen. De objectnaam is cn=server,cn=system,DC=contoso,dc=com.

In de meeste Active Directory-domeinen worden machtigingen voor deze objecten verleend op basis van het lidmaatschap van algemene groepen, zoals Geverifieerde gebruikers, Iedereen of de groep Compatibele toegang voor Windows 2000. De wijziging om het probleem te activeren, kan zijn dat de gebruiker is verwijderd uit de laatste groep (misschien samen met Iedereen en/of de machtigingen voor de vermelde objecten zijn verwijderd in een verplaatsing om de Active Directory-machtigingen te beperken.

De methoden voor het oplossen van het probleem zijn het verlenen van de vereiste leesmachtigingen of het wijzigen van de toepassing voor het gebruik van LDAP in plaats van de oudere API's of de ADSI WINNT-provider. LDAP raakt de bovenstaande objecten niet aan en biedt ook ondersteuning voor de gedetailleerde machtigingen die u mogelijk hebt ingesteld voor het doelobject.

Overmatige controle

Wanneer u controle hebt ingeschakeld voor deze objecten, ziet u maximaal drie controlerecords voor de bovenstaande objecten voor zowel het openen als sluiten van de objecten, plus de werkelijke toegang tot het doelobject. Als de gebeurtenissen overmatig worden geregistreerd, is het zinvol om de vermeldingen in de controle-ACL te verwijderen, zodat deze algemene toegangstypen niet meer worden geregistreerd. Het probleem is dat het domeinhoofdobject en de ingebouwde container worden overgenomen door veel onderliggende objecten.

Om dit op te lossen, moet u overname bij de ingebouwde container verbreken en de ACL's die overnemen opnieuw definiëren om alleen van toepassing te zijn op dit object. U moet ook de ACL's op het domeinhoofdobject aanraken, zodat het probleem SACE's niet meer van toepassing zijn op het hoofdobject van het domein. De exacte stappen zijn afhankelijk van de werkelijke SACL-instellingen die van kracht zijn in uw omgeving.