Comment utiliser les composants ADSI natifs pour trouver le groupe principal

Traductions disponibles Traductions disponibles
Numéro d'article: 321360 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article explique comment utiliser les composants ADSI (Active Directory Services Interface) native pour déterminer l'appartenance au groupe principal d'un utilisateur.

Plus d'informations

Comment le groupe principal est stocké sur un objet utilisateur dans Active Directory

Chaque objet de contexte de sécurité (comme les utilisateurs et les groupes de sécurité) dans Active Directory possède un attribut d'identificateur (SID) de sécurité associé. Le SID possède plusieurs composants, comme décrit dans la référence « composants SID » incluse dans la section « référence » de cet article. Deux de ces composants sur le SID sont l'identificateur relatif domaine (RID) et les RID spécifiques à l'objet au sein du domaine.

Le groupe principal d'un utilisateur est stocké (sous forme de RID du groupe dans du domaine utilisateur) sur l'attribut PrimaryGroupID d'un objet utilisateur. Groupe principal d'un utilisateur peut uniquement être un groupe qui existe dans le même domaine que l'utilisateur, et ce groupe doit être un groupe de l'utilisateur est un membre de. En outre, cet objet de groupe dans l'Active Directory est un attribut appelé PrimaryGroupToken , qui stocke le RID de ce groupe au sein du domaine.

Fournisseurs de Windows NT et LDAP (Lightweight Directory Access Protocol) permettent aux programmeurs de modifier le groupe principal d'un utilisateur en attribuant la valeur d'attribut PrimaryGroupID le RID d'un groupe qui l'utilisateur est un membre de. Si l'utilisateur n'est pas un membre d'un groupe, PrimaryGroupID l'utilisateur Impossible de configurer le maître RID du groupe.

Lorsqu'il utilise le fournisseur de Windows NT dans ADSI, le groupe principal est inclus comme une entrée dans la collection IADsUser::Groups l'utilisateur.

Avec le fournisseur LDAP, le groupe primaire est non incluses comme une entrée dans la collection IADsUser::Groups , ni est partie de nom unique (DN, Distinguished Name) du groupe de l'attribut MemberOf de l'objet utilisateur dans le répertoire. RID du groupe dans le PrimaryGroupID est uniquement dans lequel le groupe principal d'un utilisateur est référencé sur l'objet utilisateur LDAP.

Aucun fournisseur définit un mécanisme permettant de déterminer le nom du groupe principal d'un utilisateur directement à partir de leurs objets utilisateur respectifs. Le problème est effectué encore plus complexe par le fait que chaque objet de groupe fourni par chaque fournisseur prend en une charge d'un autre jeu d'attributs, comme suit :
  • L'objet groupe Windows NT condition ne prend pas en charge les l'attribut PrimaryGroupToken , pas plus du fournisseur de Windows NT prend en charge d'une autre manière pour extraire des RID du groupe à l'aide en code natif ADSI.
  • L'attribut PrimaryGroupToken d'un objet de groupe fournisseur LDAP est un attribut calculé. Cet attribut n'existe pas sur l'objet de groupe dans le répertoire. L'attribut est, en fait, créé lorsqu'il est demandé par le client avec un appel de méthode IADs::GetInfoEx . Il n'est pas possible d'effectuer des recherches LDAP basées sur des attributs construits dans Active Directory. Par conséquent, vous ne pouvez pas rechercher à l'aide du fournisseur LDAP pour un groupe basé sur l'attribut PrimaryGroupToken qui correspond à l'attribut PrimaryGroupID sur l'objet utilisateur dont groupe principal que vous souhaitez déterminer. Ce également les règles d'une solution ADSI pure qui n'est pas tributaire un objet COM externe pour vous aider à déterminer le groupe principal.

Méthodes pour déterminer le groupe principal d'un utilisateur

Voici trois méthodes pour déterminer le nom du groupe principal d'un utilisateur connus :
  • Créer un SID chaîne de liaison pour l'objet groupe dans Active Directory du composant RID du domaine le SID de l'utilisateur des RID du groupe stocké sur l'attribut PrimaryGroupID sur l'objet utilisateur.

    Ceci est la méthode décrite dans Microsoft article Q297951 (inclus dans la section « référence » de cet article). Le problème majeur de cette méthode est que pour créer le SID chaîne de liaison, le programmeur doit compter sur l'objet ADsSID à convertir le descripteur de sécurité binaires de l'objet de domaine dans son format SDDL. L'objet ADsSID est hébergé par le fichier ADsSecurity.dll, qui doit être copié sur et enregistré sur le client avant du code de peut lancer correctement.
  • Utiliser une requête LDAP pour rechercher pour tous les groupes dans un domaine et retourner leur attribut PrimaryGroupToken .

    Cette méthode est une solution LDAP pure. Toutefois, la solution de script n'est pas très efficace car cette recherche renvoie tous les groupes dans le domaine, y compris ceux que l'utilisateur n'est pas un membre de, et étant donné que l'attribut PrimaryGroupToken est construit sur le client comme le jeu d'enregistrements est traversée, cette recherche est très lente. Cette méthode peut être particulièrement longue s'il existe un grand nombre de groupes dans le domaine. Exemples de créer des requêtes ADO de langage LDAP abound et par conséquent, ils ne sont pas incluses dans cet article.
  • Tirer parti des fonctionnalités de chaque fournisseur pour créer une solution hybride.

    Cette solution tire parti des fonctionnalités des différents fournisseurs pour déterminer le groupe principal de l'utilisateur. Pour ce faire, procédez comme suit :
    1. Lier à l'objet utilisateur avec le fournisseur de Windows NT.

      L'objet utilisateur Windows NT fournit un ensemble de groupe qui est garanti pour contenir le groupe principal de l'utilisateur. En outre, le PrimaryGroupID de l'objet utilisateur est stocké rangement dans un emplacement temporaire pour une utilisation plus loin dans cet algorithme.
    2. Énumérer la collection IADsUser::Groups .
    3. Extraire la propriété SamAccountName l'ADsPath de chaque groupe dans cette collection, puis créer une chaîne de requête de langage LDAP pour rechercher tous les groupes avec la propriété SamAccountName répertoriée dans cette collection renvoyant leurs valeurs d'attribut PrimaryGroupToken et le nom unique DistinguishedName .
    4. Exécuter la recherche ADSI ADO et ensuite une boucle sur jeu d'enregistrements, comparaison de chaque groupe PrimaryGroupToken avec la valeur d'attribut PrimaryGroupID mis en cache plus haut.
    5. Si vous trouvez une correspondance, Arrêter et afficher le nom unique pour ce groupe comme groupe principal pour cet utilisateur.
    6. Si vous ne trouvez pas une correspondance, passez une boucle dans les résultats de la recherche.
    Les avantages de cette méthode sont immédiatement évidentes. Tous les objets utilisés sont natives sur ADSI et ne nécessitent pas des composants supplémentaires. En outre, l'énumération inclut uniquement aux groupes qui peuvent être le groupe principal.

    Toutefois, notez l'inconvénient suivant : lors de la collection IADsUser::Groups est énumérée, l'objet renvoyé est une interface IADs au membre du groupe. Si, pour une raison quelconque, l'utilisateur exécution de l'énumération ne possède pas les autorisations nécessaires ouvrir un objet particulier, l'énumération s'arrête sans indiquant une erreur. Le code suivant illustre comment vous pouvez implémenter l'algorithme précédent :
    dim oUsr 
    dim oGrp 
    
    '
    ' ToDo: Change the following variables to specific values for your domain.
    ' 
    DomainName = "myDomain"
    UserLoginName = "myUserLoginName"
    
    '
    ' Bind to the user object with the Windows NT provider.
    ' 
    set oUsr = GetObject("WinNT://" & DomainName & "/" & UserLoginName & ",user") 
    set grp = oUsr.Groups 
    GrpID = oUsr.PrimaryGroupID 
    GrpName = "" 
    
    '
    ' Building Query Filter for the search for all the groups that the user is a member of.
    '
    QueryFilter = "(|"
    for each Item in Grp 
       NT4Name = replace(Item.ADsPath,"WinNT://","") 
       tempArray = split(nt4Name,"/") 
       NT4Name = tempArray(1)
       QueryFilter = QueryFilter & "(samAccountName=" & NT4Name & ")"
    next
    QueryFilter = QueryFilter & ")"
    
    '
    ' Building LDAP dialect Query String.
    '
    QueryString = "<LDAP://" & DomainName & ">;" & QueryFilter & ";PrimaryGroupToken,distinguishedName;subtree"
    
    '
    ' Performing Query against the Active Directory for all the groups that 
    ' the user belongs to and retrieving the RID of the group object off
    ' the PrimaryGroupToken attribute on the user.
    '
    Dim oConnection, oCommand, oRecordset
    Set oConnection = CreateObject("ADODB.Connection")
    Set oCommand = CreateObject("ADODB.Command")
    
    oConnection.Provider = "ADsDSOObject"
    oConnection.Open "Active Directory Provider"
    
    Set oCommand.ActiveConnection = oConnection
    oCommand.CommandText = QueryString
    oCommand.Properties("Page Size") = 900
    
    Set oRecordset = oCommand.Execute
    
    '
    ' Looping through all the records in the search result to determine whether
    ' any of these group's PrimaryGroupToken attribute value match the 
    ' PrimaryGroupID attribute value stored on the user object.
    '
    While ((NOT oRecordset.EOF) and (Not bGroupFound))
      if (GrpID = oRecordset.Fields("PrimaryGroupToken").value) then
        GrpName = oRecordset.Fields("DistinguishedName").Value
        bGroupFound = True 
      End If
      oRecordset.moveNext
    Wend
    
    Set oRecordset = Nothing
    Set oCommand = Nothing
    Set oConnection = Nothing
    
    '
    ' Displaying Results of the search.
    ' 
    if( bGroupFound ) then 
       WScript.Echo "Primary Group for " & oUsr.AdsPath 
       WScript.Echo "Is: " & GrpName 
    else 
       WScript.Echo "Primary Group Not Found" 
    end if
    					

Références

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
297951 Comment utiliser l'attribut PrimaryGroupID pour trouver le groupe principal d'un utilisateur

Propriétés

Numéro d'article: 321360 - Dernière mise à jour: lundi 3 mars 2008 - Version: 5.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows 2000 Server
  • Microsoft Active Directory Service Interfaces 2.5
  • Microsoft Active Directory Client Extension
Mots-clés : 
kbmt kbdswadsi2003swept kbinfo KB321360 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 321360
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com