Partager via

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

  • Article

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 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, , NetUserSetInfoNetUserEnum, NetGroupGetInfo, , NetGroupEnumNetGroupSetInfo, 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 ADSI WINNT.

Ces API peuvent échouer avec ACCESS 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 compte 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.

Une application qui utilise ces API est le service de cluster et, dans le journal des services de cluster, vous verrez :

0000a78.000021b8 ::2010/06/15-00:00:47.911 WARN [RES] Network Name <cluster-resource1> : Impossible de déterminer si cluster-resource1 du compte d’ordinateur est déjà désactivé. état 5

Un autre symptôme de cet effet peut être des enregistrements d’audit excessifs 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é.

Plus d’informations

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 accès en lecture :

  • Objet racine de domaine : il recherche le domaine principal du contrôleur de domaine et ouvre le domaine de lecture, qui ouvre à son tour 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 comme l’appelant veut vérifier son existence. Ainsi, 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 sur l’accès et l’énumération généraux du compte SAM. Elle sera utilisée 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 les utilisateurs authentifiés, tout le monde ou le groupe d’accès compatible pré-Windows 2000. La modification permettant de déclencher le problème a peut-être é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 permettant de 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 ADSI WINNT. LDAP ne touche pas les objets ci-dessus et prend également en charge les autorisations granulaires que vous avez définies sur l’objet cible.

Audit excessif

Lorsque vous avez activé l’audit sur ces objets, vous verrez jusqu’à trois enregistrements d’audit pour les objets ci-dessus pour ouvrir et fermer les objets, ainsi que l’accès réel aux objets cibles. Si les événements sont enregistrés de manière excessive, il est judicieux de supprimer les entrées de la liste de contrôle d’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 ACL qui héritent de s’appliquer uniquement à cet objet. Vous devez également toucher les AAC sur l’objet Racine du domaine afin que les saces de problème ne s’appliquent plus à l’objet racine du domaine. Les étapes exactes dépendent des paramètres SACL réels qui sont en vigueur dans votre environnement.