Les applications utilisant NetUserGetInfo et des API similaires s’appuient sur l’accès en lecture à certains objets AD

Cet article traite d’un problème où les applications qui utilisent des API de bas niveau de la classe NetUser ou NetGroup comme NetUserGetInfo ou NetGroupGetInfo échouent avec l’erreur ACCESS DENIED.

Numéro de la base de connaissances d’origine : 2281774

Résumé

Vous disposez d’une application qui utilise les API de bas niveau de la classe NetUser ou NetGroup comme NetUserGetInfo, NetUserSetInfo, NetUserEnum, NetGroupGetInfoNetGroupSetInfo, NetGroupEnum, NetLocalGroupGetInfo, NetLocalGroupSetInfo, et NetLocalGroupEnum. Dans ce schéma, les API de classe NetUser sont également utilisées pour gérer le compte d’ordinateur.

Les mêmes API sont utilisées lorsque vous appelez le fournisseur WINNT ADSI.

Ces API peuvent échouer avec ACCÈS REFUSÉ, bien que le compte appelant dispose d’autorisations suffisantes sur les comptes cibles. La raison en est que l’implémentation de l’API côté client n’a pas de relation 1 :1 avec les API RPC du Gestionnaire de comptes de sécurité (SAM). Le côté client effectue des vérifications et une préparation supplémentaires pour ces appels qui nécessitent des autorisations supplémentaires dans Active Directory.

Le service de cluster est une application qui utilise ces API et, dans le journal du service de cluster, vous verrez :

00000a78.000021b8 ::2010/06/15-00 :00 :47.911 WARN [RES] Nom <réseau cluster-resource1> : Impossible de déterminer si le compte d’ordinateur cluster-resource1 est déjà désactivé. état 5

Un autre symptôme de cet effet peut être un nombre excessif d’enregistrements d’audit dans le journal des événements de sécurité de vos contrôleurs de domaine pour ces appels d’API et les objets cités ci-dessous, si l’audit d’accès réussi ou défaillant pour le compte appelant est activé.

Informations supplémentaires

L’implémentation des API utilise plusieurs appels RPC dirigés vers le contrôleur de domaine pour configurer la session et vérifier le domaine. Il accède aux objets suivants avec un accès en lecture :

• Objet racine du domaine : il recherche le domaine principal du contrôleur de domaine et ouvre le domaine pour la lecture, qui à son tour ouvre l’objet AD pour le domaine, comme DC=contoso,dc=com.

• Conteneur intégré : il s’agit de l’objet racine du domaine intégré. Il est ouvert lorsque l’appelant souhaite vérifier son existence. Par conséquent, l’appelant a besoin d’un accès en lecture au conteneur CN=Builtin,DC=contoso,dc=com.

• Objet serveur SAM : cet objet stocke les autorisations générales relatives à l’énumération et à l’accès général au compte SAM. Il sera utilisé uniquement sur certains appels. Le nom de l’objet est cn=server,cn=system,DC=contoso,dc=com.

Dans la plupart des domaines Active Directory, les autorisations pour ces objets sont accordées en fonction de l’appartenance à des groupes génériques tels que Utilisateurs authentifiés, Tout le monde ou le groupe Accès compatible pré-Windows 2000. Le changement pour déclencher le problème peut avoir été que l’utilisateur a été supprimé du dernier groupe (peut-être avec Tout le monde, et/ou les autorisations sur les objets répertoriés ont été supprimées dans un déplacement pour renforcer les autorisations Active Directory.

Les approches pour résoudre le problème sont d’accorder les autorisations de lecture requises ou de modifier l’application pour utiliser LDAP au lieu des anciennes API ou du fournisseur WINNT ADSI. LDAP ne touche pas les objets ci-dessus et prend également en charge les autorisations granulaires que vous avez peut-être définies sur l’objet cible.

Audit excessif

Lorsque vous avez activé l’audit sur ces objets, vous voyez jusqu’à trois enregistrements d’audit pour les objets ci-dessus pour l’ouverture et la fermeture des objets, ainsi que l’accès réel à l’objet cible. Si les événements sont enregistrés de manière excessive, il est judicieux de supprimer les entrées dans la liste de contrôle d’accès Audit afin que ces types d’accès génériques ne soient plus enregistrés. Le problème est que l’objet racine du domaine et le conteneur intégré héritent de nombreux objets subordonnés.

Pour résoudre ce problème, vous devez interrompre l’héritage au niveau du conteneur intégré et redéfinir les ACÉ qui héritent pour s’appliquer uniquement à cet objet. Vous devez également toucher les AAC sur l’objet racine du domaine afin que les ÉLÉMENTS SAC Ne s’appliquent plus à l’objet racine de domaine. Les étapes exactes dépendent des paramètres SACL réels qui sont en vigueur dans votre environnement.