Activer le protocole LDAP sur SSL avec une autorité de certification tierce

  • Article

Cet article explique comment activer le protocole LDAP (Lightweight Directory Access Protocol) sur SSL (Secure Sockets Layer) avec une autorité de certification tierce.

S’applique à : Windows Server 2012 R2
Numéro de l’article d’origine dans la base de connaissances : 321051

Résumé

Le protocole LDAP est utilisé pour lire et écrire dans Active Directory. Par défaut, le trafic LDAP est transmis sans sécurité. Vous pouvez rendre le trafic LDAP confidentiel et sécurisé en utilisant la technologie SSL/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.

Il n’existe aucune interface utilisateur permettant de 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 requises pour un 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).

    Remarque

    S’il y a un certificat dans le magasin NT Directory Services (NTDS), DC utilise le certificat dans le magasin NTDS à la place.

  • 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 pour la clé privée.

  • L’extension Utilisation amélioré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.contoso.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.

  • Utilisez le fournisseur de services de chiffrement (CSP) Schannel pour générer la clé.

Créer 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.

Certreq.exe requiert un fichier d’instructions 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

    ;-----------------------------------------------

    Coupez et collez l’exemple de fichier dans un nouveau fichier texte nommé Request.inf. Indiquez le nom DNS complet du contrôleur de domaine dans la demande.

    Certaines autorités de certification tierces peuvent nécessiter des informations supplémentaires dans le paramètre Subject, telles qu’une adresse de courrier (E), une unité d’organisation (OU), une organisation (O), une ville (L), un département/É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 en exécutant la commande suivante à l’invite de commandes :

    certreq -new request.inf request.req

    Un 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 émis, puis enregistrez-le en tant que Certnew.cer dans le même dossier que le fichier de demande en procédant 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 émis en exécutant la commande suivante à l’invite de commandes :

    certreq -accept certnew.cer

  6. Vérifiez que le certificat est installé dans le magasin personnel de l’ordinateur en procédant 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, consultez l’article Advanced Certificate Enrollment and Management (en anglais uniquement).

Vérifier une connexion LDAPS

Après avoir installé un certificat, procédez comme suit pour vérifier que le protocole LDAPS est activé :

  1. Démarrez l’outil d’administration Active Directory (Ldp.exe).

  2. Dans le menu Connexion, cliquez sur Connecter.

  3. Tapez le nom du contrôleur de domaine avec lequel établir une connexion.

  4. Tapez 636 pour le 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, SSL/TLS est négocié avant l’échange du trafic LDAP.

  • 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.

Améliorations

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 ainsi qu’avec les versions ultérieures de Active Directory Domain Services (AD DS). Pour plus d’informations sur l’ajout du certificat au magasin de certificats personnel du service NTDS, consultez l’article Event ID 1220 - LDAP over SSL.

AD DS recherche de préférence des 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 se produit 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émarrer AD DS ni le 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, consultez renewServerCertificate.

Enfin, si un contrôleur de domaine Windows Server 2008 ou version ultérieure trouve plusieurs certificats dans son magasin, il sélectionne automatiquement un de ces certificats.

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.