INFO : Comment utiliser ADSI pour interroger un serveur LDAP tiers

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

Sommaire

Résumé

Le fournisseur LDAP (Lightweight Directory Access Protocol) pour Active Directory Service Interfaces (ADSI) est utilisé pour récupérer des informations à partir de serveurs LDAP de tierce partie. Cet article décrit plusieurs problèmes qui peuvent survenir et comment les surmonter.

Plus d'informations

Lorsque vous utilisez ADSI pour récupérer des informations à partir d'un serveur LDAP tiers, vous devez :
  • Déterminer la disponibilité des informations de schéma.
  • Obtenir l'authentification correcte.
  • Éviter une recherche sur un conteneur qui n'existe pas.

Déterminer la disponibilité des informations de schéma

Conformément à la RFC Request for Comments () 2251, LDAP version 3 serveurs devraient pour exposer un attribut subSchemaSubEntry de la racine de l'entreprise Active directory (rootDSE). ADSI utilise cet attribut pour localiser les informations de subschema, il puis tente de valider et mettre en cache.

Pour plus d'informations sur la façon dont ADSI met en cache le subschema, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la base de connaissances Microsoft :
251189Information : Recherche d'un schéma de serveur LDAP mis en cache par ADSI
ADSI utilise les informations de subschema pour exposer les interfaces appropriées pour une classe donnée et pour récupérer des attributs dans la syntaxe correcte à partir du cache de propriétés.

Si ADSI n'est pas en mesure de localiser ou de valider correctement les informations de subschema, il utilise le schéma par défaut LDAP version 2. Parce que les serveurs LDAP version 2 n'exposent pas un subschema, ADSI conserve les informations de schéma en interne sur de nombreux attributs standard et les classes. Si ADSI utilise le schéma de version 2 par défaut, il n'a pas accès aux informations de schéma non standard, y compris des classes personnalisées ou des attributs qui ont été créés sur le serveur.

Si aucune information de schéma sur la syntaxe d'un attribut n'est disponible, ADSI ne peut pas récupérer l'attribut à partir du cache de propriété. Dans ce cas, vous pouvez utiliser la méthode IADsPropertyList.GetPropertyItem pour spécifier une syntaxe de l'attribut de la propriété demandée. Lorsque vous spécifiez une valeur ADsTYPE, vous évitez la nécessité d'informations de syntaxe concernant cet attribut.

Si vous utilisez Microsoft ActiveX Data Objects (ADO), et vous n'avez pas les informations de schéma disponibles, que vous devez récupérer la chaîne ADsPath de l'objet, lier à l'objet dans le répertoire, puis utilisez la méthode IADsPropertyList.GetPropertyItem. Il n'existe aucune solution de contournement pour l'utilisation d'ADO directement sans informations de schéma.

Obtenir l'authentification correcte

Il existe plusieurs façons pour authentifier un client LDAP à un serveur LDAP avec ADSI. Parmi ces méthodes, uniquement une liaison simple est pris en charge en mode natif par le protocole LDAP pour transmettre des informations d'identification au serveur. Dans les autres cas, le client et le serveur doivent se mettre d'accord sur la méthode, généralement avec l'utilisation d'une autre autorité de sécurité ou de protocole propriétaire.

Par exemple, la méthode GetObject (ou la fonction ADsGetObject dans C) utilise l'indicateur ADS_SECURE_AUTHENTICATION, qui peut se traduire par une liaison LDAP qui utilise Microsoft Windows NT Challenge/Response (NTLM). Cette liaison est susceptible d'échouer étant donné que de nombreux serveurs tiers n'acceptent pas NTLM. Si l'authentification échoue, la liaison sécurisée est déclassée pour une liaison anonyme ; par exemple, une simple liaison sans informations d'identification utilisateur. À ce stade, l'application peut avoir accès uniquement à un sous-ensemble des informations (ou même à aucune information) en fonction de la configuration du serveur.

Pour éviter cette situation, effectuer une liaison simple à l'aide de la méthode OpenDSObject (ou la fonction ADsOpenObject dans C) et spécifiez zéro (aucun indicateur) ou ADS_FAST_BIND (décrit ci-dessous) pour le paramètre lnReserved. Avec la liaison simple, transmettez un nom d'utilisateur avec attributs valide (cn = nom_utilisateur, cn =...) et un mot de passe pour le serveur LDAP pour vérification. Pour obtenir une liaison simple avec ADO, affectez FALSE à la propriété de Crypter le mot de passe de l'objet ADODB.Connection et définissez le nom d'utilisateur avec attributs et le mot de passe les propriétés de L'ID d'utilisateur et le mot de passe.

Empêcher une recherche sur un conteneur inexistant

Par défaut, ADSI effectue une recherche objectClass de l'objet de base spécifié dans une requête ou une liaison. Cette recherche échoue si le nom unique est donné n'existe pas dans le répertoire.

Par exemple, supposons qu'une recherche est définie sur commencent à "o = corp, c = US» pour tous les utilisateurs dans le répertoire. La structure du répertoire est telle qu'il n'existe aucun conteneur "Corp" réelle, mais plutôt deux objets à la racine du répertoire avec les noms uniques des «ou = Nord, o = corp, c = US "et" ou = Europe, o = corp, c = US». ADSI émet une recherche objectClass pour "o = corp, c = US» qui échoue, arrêt de la recherche pour les utilisateurs avant qu'elle ne démarre.

La solution la plus simple à ce problème consiste à spécifier un objet de base existe réellement dans le répertoire. Si elle n'est pas possible, en raison de la mise en oeuvre de répertoire, pour effectuer la recherche de votre choix avec un objet de base valide, vous devez empêcher ADSI d'une recherche par objectClass initiale.

Afin d'éviter une recherche objectClass sur l'objet, passer l'indicateur ADS_FAST_BIND dans le paramètre lnReserved de la méthode OpenDSObject (ou la fonction ADsOpenObject dans C). Comme cet indicateur détermine les actions d'ADSI après que la liaison s'est produit, elle n'affecte pas une authentification appropriée. Notez que cet indicateur n'est pas disponible avant ADSI version 2.5.

Le fournisseur ADO pour Microsoft Windows 2000 expose les propriétés ADSI indicateur sur l'objet ADODB.Connection. Vous pouvez définir l'indicateur ADS_FAST_BIND pour cette propriété pour empêcher les requêtes ADO d'effectuer une recherche objectClass. La propriété ADSI indicateur n'est pas présente dans ADSI version 2.5 pour Microsoft Windows NT version 4.0 ou Microsoft Windows 9 x. Pour une solution possible, consultez l'article suivant :

223049Comment faire : Requête Exchange 5.x de façon anonyme via ADSI

Références

Pour plus d'informations sur ADSI, consultez les articles suivants dans la base de connaissances Microsoft :
233023Comment faire : Rechercher tous les fournisseurs ADSI sur un système
187529Comment faire : Utiliser ADO d'objets Access via un fournisseur LDAP ADSI
251189Information : Recherche d'un schéma de serveur LDAP mis en cache par ADSI
223049Comment faire : Requête Exchange 5.x de façon anonyme via ADSI

Pour obtenir des informations générales sur ADSI, consultez le site Web suivant :
http://msdn2.microsoft.com/library/aa772170.aspx

Propriétés

Numéro d'article: 251195 - Dernière mise à jour: vendredi 28 septembre 2007 - Version: 1.3
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Active Directory Service Interfaces 2.5
Mots-clés : 
kbmt kbinfo kbmsg KB251195 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: 251195
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.
Exclusion de responsabilité concernant les contenus obsolètes dans la Base de connaissances
Cet article concerne des produits pour lesquels Microsoft n'offre plus de support. Il est par conséquent fourni « en l'état » et ne sera plus mis à jour.

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