Certaines applications et API nécessitent l’accès aux informations d’autorisation sur les objets de compte
Cet article décrit certaines applications et interfaces de programmation d’applications (API) doivent avoir accès à l’attribut TGGAU (token-groups-global-and-universal) sur les objets de compte d’utilisateur ou sur les objets de compte d’ordinateur dans le service d’annuaire Active Directory.
Numéro de la base de connaissances d’origine : 331951
Résumé
Certaines applications ont des fonctionnalités qui lisent l’attribut jeton-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 de compatibilité des autorisations (prise lorsque le domaine a été créé pendant le processus de 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 à la lecture de l’attribut TGGAU peut être accordé en fonction des besoins du nouveau groupe d’accès d’autorisation Windows (WAA) dans Windows Server 2003.
Plus d’informations
L’attribut TGGAU (Token-groups-global-and-universal) 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 de groupe universelles 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 reçu l’accès à une ressource pour laquelle l’application contrôle l’accès. Les applications qui nécessitent ces informations peuvent lire directement l’attribut TGGAU à l’aide d’interfaces de protocole d’accès à l’annuaire léger ou d’interfaces des 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 inconsciemment 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 d’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 s’exécutent comme au groupe d’accès compatible pré-Windows 2000. Au lieu de cela, vous pouvez sélectionner l’option « Autorisations compatibles avec les serveurs pré-Windows 2000 » pendant le processus DCPromo lorsque vous créez un domaine. (Sur Windows Server 2003, cette option est wordné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 d’accès compatible Pré-Windows 2000, et accorde ainsi au groupe Tout le monde un accès en lecture à l’attribut TGGAU et à de nombreux autres objets de domaine.
Lorsqu’un nouveau domaine Windows Server 2003 est créé, la sélection de compatibilité d’accès par défaut est compatible avec les autorisations uniquement avec les systèmes d’exploitation Windows 2000 ou Windows Server 2003. Lorsque cette option est définie, le groupe d’accès de compatibilité Pré-Windows 2000 inclut uniquement l’identificateur de sécurité intégré des 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 sont refusées, 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 d’un accès en lecture sur l’attribut TGGAU (token-groups-global-and-universal) aux utilisateurs qui doivent lire l’attribut, Windows Server 2003 introduit le groupe d’accès d’autorisation Windows (WAA).
Sur les nouvelles installations des domaines Windows Server 2003, le groupe WAA est autorisé à accéder à l’attribut TGGAU en 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 a 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 tokenGroupsGlobalAndUniversal
sur les objets utilisateur, sur les objets ordinateur et sur iNetOrgPerson
les 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. Ainsi, les domaines et domaines en mode mixte qui ont été mis à niveau vers Windows Server 2003 qui étaient en mode d’accès de compatibilité antérieur à Windows 2000 continuent d’avoir le groupe Tout le monde dans le groupe d’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 créé automatiquement lorsqu’un contrôleur de domaine Windows Server 2003 est promu au serveur d’opérations monomaître flottante.
- Le groupe WAA n’a pas automatiquement accès à 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 est en mode d’accès de compatibilité antérieur à Windows 2000, le groupe Tout le monde a 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, ajoutez au groupe WAA ces comptes qui nécessitent l’accès à TGGAU. Dans les nouvelles installations de Windows Server 2003, le groupe WAA a déjà accès en lecture à TGGAU sur les objets utilisateur et sur les objets ordinateur.