Certaines applications et API nécessitent l’accès aux informations d’autorisation sur les objets de compte

Article
02/19/2024

Cet article décrit certaines applications et interfaces de programmation d’applications (API) doivent avoir accès à l’attribut token-groups-global-and-universal (TGGAU) sur les objets de compte d’utilisateur ou sur les objets de compte d’ordinateur dans le service d’annuaire Active Directory.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 331951

Résumé

Certaines applications ont des fonctionnalités qui lisent l’attribut token-groups-global-and-universal (TGGAU) sur les objets de compte d’utilisateur ou sur les objets de compte d’ordinateur dans le service d’annuaire Microsoft Active Directory. Certaines fonctions Win32 facilitent la lecture de l’attribut TGGAU. Les applications qui lisent cet attribut ou qui appellent une API (appelée fonction dans le reste de cet article) qui lit cet attribut ne réussissent pas si le contexte de sécurité appelant n’a pas accès à l’attribut.

Par défaut, l’accès à l’attribut TGGAU est déterminé par la décision Compatibilité des autorisations (prise lors de la création du domaine pendant le processus DCPromo.exe). La compatibilité des autorisations par défaut pour les nouveaux domaines Windows Server 2003 n’accorde pas un accès étendu à l’attribut TGGAU. L’accès pour lire l’attribut TGGAU peut être accordé en fonction des besoins au nouveau groupe d’accès d’autorisation Windows (WAA) dans Windows Server 2003.

Plus d’informations

L’attribut token-groups-global-and-universal (TGGAU) est une valeur calculée dynamiquement sur les objets de compte d’ordinateur et sur les objets de compte d’utilisateur dans Active Directory. Cet attribut énumère les appartenances aux groupes globaux et les appartenances aux groupes universels pour le compte d’utilisateur ou le compte d’ordinateur correspondant. Les applications peuvent utiliser les informations de groupe fournies par l’attribut TGGAU pour prendre différentes décisions concernant un utilisateur spécifique lorsque l’utilisateur n’est pas connecté.

Par exemple, une application peut utiliser ces informations pour déterminer si un utilisateur a obtenu l’accès à une ressource pour laquelle l’application contrôle l’accès. Les applications qui nécessitent ces informations peuvent lire l’attribut TGGAU directement à l’aide d’interfaces lightweight directory access protocol ou d’interfaces de services Active Directory. Toutefois, Microsoft Windows Server 2003 a introduit plusieurs fonctions (notamment la fonction AuthzInitializeContextFromSid et la fonction LsaLogonUser) qui simplifient la lecture et l’interprétation de l’attribut TGGAU. Par conséquent, les applications qui utilisent ces fonctions peuvent sans le savoir lire l’attribut TGGAU.

Pour que les applications puissent lire directement cet attribut ou lire indirectement cet attribut (via l’utilisation d’une API), le contexte de sécurité dans lequel l’application s’exécute doit avoir reçu un accès en lecture à l’objet TGGAU sur les objets utilisateur et sur les objets ordinateur. Vous ne vous attendez pas à ce que les applications supposent qu’elles ont accès à TGGAU. Par conséquent, vous pouvez vous attendre à ce que les applications échouent lorsque l’accès est refusé. Dans ce cas, vous (l’utilisateur) pouvez recevoir un message d’erreur ou une entrée de journal qui explique que l’accès a été refusé lors de la tentative de lecture de ces informations, et qui fournit des instructions sur la façon d’obtenir l’accès (comme décrit plus loin dans cet article).

Plusieurs applications existantes dépendent des informations fournies par TGGAU, car les informations sont disponibles par défaut dans Microsoft Windows NT 4.0 et dans les systèmes d’exploitation antérieurs. Ainsi, sur les systèmes d’exploitation Microsoft Windows 2000 et Windows Server 2003, l’accès en lecture à l’attribut TGGAU est accordé au groupe Accès compatible pré-Windows 2000 .

Pour les domaines qui utilisent des applications existantes, vous pouvez gérer ces applications en ajoutant les contextes de sécurité que ces applications exécutent au groupe Accès compatible pré-Windows 2000 . Au lieu de cela, vous pouvez sélectionner l’option « Autorisations compatibles avec les serveurs antérieurs à Windows 2000 » pendant le processus DCPromo lorsque vous créez un domaine. (Sur Windows Server 2003, cette option est libellée comme suit : « Autorisations compatibles avec les systèmes d’exploitation serveur antérieurs à Windows 2000 ».) Cette sélection ajoute le groupe Tout le monde au groupe Accès compatible pré-Windows 2000 et accorde ainsi au groupe Tout le monde l’accès en lecture à l’attribut TGGAU et à de nombreux autres objets de domaine.

Lorsqu’un domaine Windows Server 2003 est créé, la sélection de compatibilité d’accès par défaut est Autorisations compatibles uniquement avec les systèmes d’exploitation Windows 2000 ou Windows Server 2003. Lorsque cette option est définie, le groupe Accès de compatibilité pré-Windows 2000 inclut uniquement l’identificateur de sécurité intégré Utilisateurs authentifiés, et l’accès en lecture à l’attribut TGGAU sur les objets est limité. Dans ce cas, les applications qui nécessitent l’accès au groupe TGGAU se voient refuser l’accès, sauf si le compte sous lequel les applications s’exécutent dispose de droits d’administrateur de domaine ou de droits d’utilisateur similaires.

Activation des applications pour lire l’attribut TGGAU

Pour simplifier le processus d’octroi de l’accès en lecture sur l’attribut token-groups-global-and-universal (TGGAU) aux utilisateurs qui doivent lire l’attribut, Windows Server 2003 introduit le groupe Accès d’autorisation Windows (WAA).

Sur les nouvelles installations de domaines Windows Server 2003, le groupe WAA se voit accorder l’accès à l’attribut TGGAU de lecture sur les objets utilisateur et sur les objets de groupe.

Domaines Windows 2000

Si le domaine est en mode d’accès de compatibilité antérieur à Windows 2000, le groupe Tout le monde dispose d’un accès en lecture à l’attribut TGGAU sur les objets de compte d’utilisateur et sur les objets de compte d’ordinateur. Dans ce mode, les applications et les fonctions ont accès à TGGAU.

Si le domaine n’est pas en mode d’accès de compatibilité antérieur à Windows 2000, vous devrez peut-être autoriser certaines applications à lire le TGGAU. Étant donné que le groupe d’accès d’autorisation Windows n’existe pas sur Windows 2000, il est recommandé de créer un groupe local de domaine à cet effet et d’ajouter le compte d’utilisateur ou d’ordinateur qui nécessite l’accès à l’attribut TGGAU à ce groupe. Ce groupe doit avoir accès à l’attribut sur les tokenGroupsGlobalAndUniversal objets utilisateur, sur les objets ordinateur et sur les iNetOrgPerson objets.

Domaines en mode mixte et domaines mis à niveau

Lorsqu’un contrôleur de domaine Windows Server 2003 est ajouté à un domaine Windows 2000, la sélection de compatibilité d’accès précédemment sélectionnée n’est pas modifiée. Par conséquent, les domaines et domaines en mode mixte qui ont été mis à niveau vers Windows Server 2003 et qui étaient en mode d’accès de compatibilité antérieur à Windows 2000 continuent d’avoir le groupe Tout le monde dans le groupe Accès de compatibilité pré-Windows 2000 . En outre, le groupe Tout le monde a toujours accès à l’attribut TGGAU. Dans ce mode, les applications et les fonctions ont accès à TGGAU.

Si le domaine en mode mixte n’est pas en mode d’accès de compatibilité antérieur à Windows 2000, vous pouvez accorder des autorisations au moyen du groupe WAA :

Le groupe WAA est automatiquement créé lorsqu’un contrôleur de domaine Windows Server 2003 est promu au serveur d’opérations à maître unique flottant.
Le groupe WAA n’est pas automatiquement autorisé à accéder à l’attribut TGGAU sur les domaines en mode mixte et sur les domaines mis à niveau.

Une fois que le groupe Accès d’autorisation Windows (WAA) a accès à l’attribut TGGAU, vous pouvez placer les comptes qui nécessitent un accès dans le groupe WAA.

Nouveaux domaines Windows Server 2003

Si le domaine n’est pas en mode d’accès de compatibilité antérieur à Windows 2000, ajoutez au groupe WAA les comptes qui nécessitent l’accès à TGGAU. Dans les nouvelles installations de Windows Server 2003, le groupe WAA dispose déjà d’un accès en lecture à TGGAU sur les objets utilisateur et sur les objets ordinateur.