Comment faire pour activer le protocole LDAP sur SSL avec une autorité de certification tierce

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

Sommaire

Résumé

Le protocole LDAP (Lightweight Directory Access Protocol) est utilisé pour lire et écrire dans Active Directory. Par défaut, le trafic LDAP est transmis de manière non sécurisée. Vous pouvez rendre le trafic LDAP confidentiel et sécurisé en utilisant la technologie SSL (Secure Sockets Layer) / TLS (Transport Layer Security). Vous pouvez activer le protocole LDAP sur SSL (LDAPS) en installant un certificat correctement mis en forme à partir d'une autorité de certification Microsoft ou d'une autorité de certification non-Microsoft en appliquant les procédures fournies dans cet article.

Plus d'informations

Il n'existe aucune interface utilisateur pour configurer le protocole LDAPS. L'installation d'un certificat valide sur un contrôleur de domaine permet au service LDAP d'écouter, et d'accepter automatiquement, les connexions SSL pour le trafic LDAP et le trafic de catalogue global.

Conditions liées au certificat LDAPS

Pour activer le protocole LDAPS, vous devez installer un certificat qui remplit les conditions suivantes :
  • Le certificat LDAPS se trouve dans le magasin de certificats Personnel de l'ordinateur local (également connu, en termes de programmation, sous le nom de magasin de certificats MY).
  • Une clé privée qui correspond au certificat est présente dans le magasin de l'ordinateur local et est associée correctement au certificat. La protection renforcée de clés privées ne doit pas être activée sur la clé privée.
  • L'extension Utilisation avancée de la clé inclut l'identificateur d'objet Authentification du serveur (1.3.6.1.5.5.7.3.1) (également appelé OID).
  • Le nom de domaine complet Active Directory du contrôleur de domaine (par exemple, DC01.DOMAIN.COM) doit apparaître à l'un des emplacements suivants :
    • le Nom commun (CN) dans le champ Subject ;
    • l'entrée DNS dans l'extension Autre nom de l'objet.
  • Le certificat a été publié par une autorité de certification approuvée par le contrôleur de domaine et les clients LDAPS. L'approbation est établie en configurant les clients et le serveur de façon à approuver l'autorité de certification racine à laquelle est enchaînée l'autorité de certification émettrice.
  • Vous devez utiliser le fournisseur de services de chiffrement Schannel (CSP) pour générer la clé.
Pour plus d'informations sur l'établissement de l'approbation pour les certificats, consultez la rubrique « Stratégies pour établir l'approbation d'autorités de certification racine » dans l'aide sur Windows 2000 Server.

Création de la demande de certificat

Tout utilitaire ou application qui crée une demande PKCS #10 valide peut être utilisé pour former la demande de certificat SSL. Utilisez Certreq pour former la demande.

Remarque Les commandes qui sont utilisées dans cet article reposent sur la version 2003 de Certreq. Pour utiliser les étapes de cet article sur un serveur Windows 2000, copiez certreq.exe et certcli.dll à partir d'un serveur Windows 2003 vers un répertoire temporaire sur le serveur Windows 2000.

Certreq.exe requiert un fichier d'instruction texte afin de générer une demande de certificat X.509 appropriée pour un contrôleur de domaine. Vous pouvez créer ce fichier à l'aide de votre éditeur de texte ASCII par défaut. Enregistrez le fichier en tant que fichier .inf dans un dossier quelconque sur votre disque dur.

Pour demander un certificat d'authentification serveur adapté au protocole LDAPS, procédez comme suit :
  1. Créez le fichier .inf. Voici un exemple de fichier .inf qui peut être utilisé pour créer la demande de certificat.
    ;----------------- request.inf -----------------

    [Version]

    Signature="$Windows NT$

    [NewRequest]

    Subject = "CN=<DC fqdn>" ; replace with the FQDN of the DC
    KeySpec = 1
    KeyLength = 1024
    ; Can be 1024, 2048, 4096, 8192, or 16384.
    ; Larger key sizes are more secure, but have
    ; a greater impact on performance.
    Exportable = TRUE
    MachineKeySet = TRUE
    SMIME = False
    PrivateKeyArchive = FALSE
    UserProtected = FALSE
    UseExistingKeySet = FALSE
    ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
    ProviderType = 12
    RequestType = PKCS10
    KeyUsage = 0xa0

    [EnhancedKeyUsageExtension]

    OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

    ;-----------------------------------------------
    Copiez et collez l'exemple de fichier dans un nouveau fichier texte nommé Request.inf. Spécifiez le nom DNS complet du contrôleur de domaine dans la demande.

    Remarque Certaines autorités de certification tierces peuvent nécessiter des informations supplémentaires dans le paramètre Subject, telles qu'une adresse de messagerie (E), une unité d'organisation (OU), une organisation (O), une ville (L), un état ou une province (S) et un pays ou une région (C). Vous pouvez ajouter ces informations au nom Subject (CN) dans le fichier Request.inf. Par exemple : Subject="E=admin@contoso.com, CN=<DC fqdn>, OU=Servers, O=Contoso, L=Redmond, S=Washington, C=US."
  2. Créez le fichier de demande. Pour ce faire, tapez la commande suivante à l'invite de commande, et appuyez sur ENTRÉE :
    certreq -new request.inf request.req
    Un nouveau fichier nommé Request.req est créé. Il s'agit du fichier de demande codé en base64.
  3. Soumettez la demande à une autorité de certification. Vous pouvez soumettre la demande à une autorité de certification Microsoft ou tierce.
  4. Récupérez le certificat qui est publié, puis enregistrez-le certificat en tant que Certnew.cer dans le même dossier que le fichier de demande. Pour cela, procédez comme suit :
    1. Créez un fichier nommé Certnew.cer.
    2. Ouvrez le fichier dans le Bloc-notes, collez le certificat codé dans le fichier, puis enregistrez le fichier.
    Remarque Le certificat enregistré doit être codé en base64. Certaines autorités de certification tierces retournent le certificat publié au demandeur en tant que texte codé en base64 dans un message électronique.
  5. Acceptez le certificat publié. Pour ce faire, tapez la commande suivante à l'invite de commande, et appuyez sur ENTRÉE :
    certreq -accept certnew.cer
  6. Vérifiez que le certificat est installé dans le magasin Personnel de l'ordinateur. Pour cela, procédez comme suit :
    1. Démarrez la console MMC (Microsoft Management Console).
    2. Ajoutez le composant logiciel enfichable Certificats qui gère les certificats sur l'ordinateur local.
    3. Développez Certificats (Ordinateur local), Personnel, puis Certificats.
    Il doit exister un nouveau certificat dans le magasin Personnel. Dans la boîte de dialogue Propriétés du certificat, le rôle prévu affiché est Authentification serveur. Ce certificat est publié au nom d'hôte complet de l'ordinateur.
  7. Redémarrez le contrôleur de domaine.
Pour plus d'informations sur la création de la demande de certificat, consultez le livre blanc suivant sur l'inscription et la gestion de certificats avancées. Pour afficher ce livre blanc, reportez-vous au site Web Microsoft à l'adresse suivante (en anglais) :
http://technet.microsoft.com/en-us/library/cc782583.aspx

Vérification d'une connexion LDAPS

Après l'installation d'un certificat, procédez comme suit pour vérifier la connexion LDAPS :
  1. Démarrez l'outil d'administration Active Directory (Ldp.exe).

    Remarque Ce programme est installé dans les Outils de support Windows 2000.
  2. Dans le menu Connection, cliquez sur Connect.
  3. Tapez le nom du contrôleur de domaine avec lequel établir une connexion.
  4. Tapez 636 comme numéro de port.
  5. Cliquez sur OK.

    Les informations RootDSE doivent s'imprimer dans le volet droit, indiquant la réussite de la connexion.

Problèmes possibles

  • Demande étendue Start TLS
    La communication LDAPS a lieu sur le port TCP 636. La communication LDAPS à un serveur de catalogue global a lieu sur le port TCP 3269. Lors de la connexion au port 636 ou 3269, le protocole SSL/TLS est négocié avant tout échange de trafic LDAP. Windows 2000 ne prend pas en charge la fonctionnalité de demande étendue Start TLS.
  • Certificats SSL multiples
    Schannel, le fournisseur SSL Microsoft, sélectionne le premier certificat valide qu'il trouve dans le magasin de l'ordinateur local. Si plusieurs certificats valides sont disponibles dans le magasin de l'ordinateur local, Schannel peut ne pas sélectionner le certificat correct.
  • Problème de mise en cache de certificat SSL pré-SP3
    Si un certificat LDAPS existant est remplacé par un autre certificat, par le biais d'un processus de renouvellement ou car l'autorité de certification émettrice a changé, le serveur doit être redémarré pour que Schannel utilise le nouveau certificat. Le fournisseur SSL dans Windows 2000 met en cache le certificat LDAPS et ne détecte la modification que lorsque le contrôleur de domaine est redémarré. Ce problème a été corrigé dans Windows 2000 Service Pack 3.

Améliorations de Windows Server 2008

La recommandation d'origine de cet article était de placer les certificats dans le magasin personnel de l'ordinateur local. Cette option est prise en charge, mais vous pouvez également placer les certificats dans le magasin de certificats personnel du service NTDS sous Windows Server 2008 et les versions ultérieures des services de domaine Active Directory (AD DS). Pour plus d'informations sur l'ajout du certificat au magasin de certificats personnel du service NTDS, reportez-vous au site web TechNet de Microsoft :
http://technet.microsoft.com/en-us/library/dd941846(WS.10).aspx
AD DS recherche les certificats dans ce magasin plutôt que dans le magasin de l'ordinateur local. Cela facilite la configuration d'AD DS pour utiliser le certificat approprié. Cela s'explique, car le magasin personnel des ordinateurs locaux peut comprendre plusieurs certificats, ce qui peut rendre difficile la prévision du choix.

AD DS détecte l'ajout d'un nouveau certificat dans son magasin et déclenche la mise à jour d'un certificat SSL sans impliquer le redémarrage d'AD DS ni du contrôleur de domaine.

Une nouvelle opération rootDse nommée renewServerCertificate permet de déclencher manuellement la mise à jour par AD DS de ses certificats SSL, sans redémarrage d'AD DS ni du contrôleur de domaine. Cet attribut peut être mis à jour au moyen de adsiedit.msc ou en important la modification au format LDAP Directory Interchange Format (LDIF) au moyen de ldifde.exe. Pour plus d'informations sur l'utilisation de LDIF pour mettre à jour cet attribut, reportez-vous au site web MSDN de Microsoft :
http://msdn.microsoft.com/en-us/library/cc223311(v=PROT.10).aspx
Pour conclure, si un contrôleur de domaine Windows Server 2008 ou d'une version ultérieure détecte plusieurs certificats dans son magasin, il sélectionne automatiquement celui dont la date d'expiration future est la plus éloignée. Si le certificat actuel approche de sa date d'expiration, vous pouvez ignorer le certificat de remplacement dans le magasin, et AD DS l'utilise automatiquement.

Ces procédures fonctionnent sous Windows Server 2008 AD DS et AD LDS 2008 (Active Directory Lightweight Directory Services). Pour AD LDS, placez les certificats dans le magasin de certificats personnel du service qui correspond à l'instance AD LDS et non au service NTDS.
Remarque Il s'agit d'un article de « PUBLICATION RAPIDE » rédigé directement au sein du service de support technique Microsoft. Les informations qui y sont contenues sont fournies en l'état, en réponse à des problèmes émergents. En raison du délai rapide de mise à disposition, les informations peuvent contenir des erreurs typographiques et, à tout moment et sans préavis, faire l'objet de révisions. Pour d'autres considérations, consultez les Conditions d'utilisation.

Propriétés

Numéro d'article: 321051 - Dernière mise à jour: mercredi 8 janvier 2014 - Version: 1.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Windows Server 2008 Standard
  • Windows Server 2008 Datacenter
  • Windows Server 2008 Enterprise
  • Windows Server 2008 Standard without Hyper-V
  • Windows Server 2008 Datacenter without Hyper-V
  • Windows Server 2008 Enterprise without Hyper-V
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
Mots-clés : 
kbproductlink kbinfo KB321051
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