Active Directory et LDAPS.
LDAP est utilisé pour lire et écrire dans Active Directory. Par défaut, le trafic LDAP est en clair. Nous pouvons rendre le trafic LDAP confidentiel et sécurisé à l’aide de la technologie SSL/TLS (Transport Layer Security). Pour activer LDAP sur SSL (LDAPS), il suffit d’installer un certificat correctement configurer à partir d’une autorité de certification Microsoft ou d’une autorité de certification tierce sur les contrôleurs de domaine.
Aujourd’hui, il est plus qu’urgent de passer sur des flux sécurisés, il ne faut plus lésiner là dessus…
Par contre, à n’appliquer que si toute votre infrastructure est compatible avec LDAPS… Si ce n’est pas le cas mais que vous voulez quand même avoir de la sécurité, rendez-vous sur le post « Active Directory et LDAP…«
Les ports LDAP par défaut :
Les ports LDAPS :
Partant du principe que nous avons 2 DC avec comme nom FQDN (exemple fictif) :
- SVW-ACD-01.LEENDIS.LOCAL (voir le post Convention de nommage des machines…),
- SVW-ACD-02.LEENDIS.LOCAL
Le certificat qui doit être installé sur les DC doit répondre aux exigences suivantes lors de sa création :
- La clé privée doit-être présente dans le magasin de l’ordinateur local et doit correspondre au certificat (pas de protection de clé privée forte activée.),
- L’identificateur d’objet (OID) à rajouter est « Authentification serveur (1.3.6.1.5.5.7.3.1)« ,
- Le nom FQDN du contrôleur de domaine (les noms FQDN sont au dessus) doit apparaître à l’un des endroits suivants :
- Nom commun (CN) dans le champ Objet.
- Entrée DNS dans l’extension Autre nom de l’objet.
Création de la demande de certificat
Tout utilitaire qui crée une demande #10 PKCS peut être utilisé tel que Certreq, une MMC avec l’option « Certificats » (si vous avec une PKI de domaine), OpenSSL, etc… pour lancer la demande de certificat SSL.
Nous prendrons pour exemples 2 manières de faire pour la création des certificats :
- Certreq avec une CA de domaine,
- OpenSSL.
CERTREQ
La commande Certreq (Certreq.exe est inclus dans toutes les distribs Windows) nécessite un fichier d’instructions texte pour générer une demande de certificat X.509 pour un contrôleur de domaine.
Pour créer ce fichier, l’utilisation de Nodepad++ (éditeur de texte ASCII) par exemple ou tout autre logiciel fera l’affaire puis enregistrer le fichier en tant que fichier .inf
1) Créez deux fichiers .inf (par exemple reqcert.inf) étant donné que nous avons 2 DC, donc un fichier par serveur. voici un exemple de fichier .inf que l’on va utiliser :
Le 1er fichier
;----------------- reqcert1.inf -----------------
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject="E= contact@leendis.com , CN= SVW-ACD-01.LEENDIS.LOCAL , OU=ServersDC, O=LeenDIS, L=IDF, S=Paris, C=FR." ; à remplacer par vos informations à vous...
KeySpec = 1
KeyLength = 2048
; Peut être 1024, 2048, 4096, 8192 ou 16384.
; Les plus grandes tailles de clé sont plus sécurisées, mais ont
; un impact plus important sur les performances.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft Software Key Storage Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
KeyAlgorithm = RSA
EncryptionLength = 256
EncryptionAlgorithm = AES
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; il s’agit de l’authentification du serveur
;--------------------------------------------------------
Le 2eme fichier
;----------------- reqcert2.inf -----------------
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject="E= contact@leendis.com , CN= SVW-ACD-02.LEENDIS.LOCAL , OU=ServersDC, O=LeenDIS, L=IDF, S=Paris, C=FR." ; à remplacer par vos informations à vous...
KeySpec = 1
KeyLength = 2048
; Peut être 1024, 2048, 4096, 8192 ou 16384.
; Les plus grandes tailles de clé sont plus sécurisées, mais ont
; un impact plus important sur les performances.
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft Software Key Storage Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
KeyAlgorithm = RSA
EncryptionLength = 256
EncryptionAlgorithm = AES
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; il s’agit de l’authentification du serveur
;--------------------------------------------------------
2) Créez un dossier dans C:\ puis exécuter les commandes ci-dessous via une invite de commandes :
c:\reqandcert\certreq -new reqcert1.inf reqcert1.req
c:\reqandcert\certreq -new reqcert2.inf reqcert2.req
Les fichiers ont été créés. Ce sont les fichiers de requête encodé en base64.
3) Soumettre les demandes à une Autorité de Certification (Microsoft ou une autorité Tierce).
En même temps, utiliser Nodepad++ (éditeur de texte ASCII) pour créer deux nouveaux fichiers : NewCert1.cer et NewCert2.cer : récupérer et coller les informations codées de la l’Autorité de Certification (CA) pour chaque demande dans les fichiers nouvellement créer puis les enregistrer dans le même dossier que les autres fichiers.
Exécuter la commande suivante afin d’accepter les certificats :
c:\reqandcert\certreq -accept NewCert1.cer
c:\reqandcert\certreq -accept NewCert2.cer
Si tout est ok, le certificat devrait apparaitre dans le « Magasin Personnel de l’Ordinateur » de chaque AD :
La chose à vérifier qui est dans les propriétés des certificats : « Authentification du serveur » doit être indiquée…
Nous pourrions en rester là et redémarrer les contrôleurs de domaine pour que les certificats soient pris en compte lors des connections LDAPS… Sauf qu’un souci va apparaitre : Schannel (le fournisseur SSL de Microsoft) sélectionne le premier certificat valide qu’il trouve dans le magasin personnel de l’Ordinateur. S’il existe plusieurs certificats dans le magasin, Schannel peut ne pas sélectionner le bon certificat… Et donc la connexion LDAPS ne se fera pas et passera de nouveau en connexion non sécure.
-
La première solution :
est d’exporter les certificats avec leur clef privée pour les mettre dans un autre magasin (NTDS\Personnel)… Après avoir exporter les certificats avec leur clef privé (fichier .pfx) dans notre dossier, il faut se rendre dans :
Se positionner au niveau de NTDS\Personnel puis importer le certificat .PFX…
Pas la peine de redémarrer les contrôleurs de domaine car AD DS détecte lorsqu’un nouveau certificat est déposé dans ce magasin de certificats, puis déclenche une mise à jour sans avoir à redémarrer AD DS ou redémarrer le contrôleur de domaine…
-
La deuxième solution :
est de passer par la base de registre pour exporter le certificat dans le magasin NTDS\Personnel… 1ere chose à faire est de récupérer l’empreinte numérique du certificat.
Puis se rendre dans la base de registre à cette endroit :
« HKLM:\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates »
pour repérer l’empreinte numérique…
A partir de là, il faudra exporter la clef dans un fichier en passant par « Fichier, puis Exporter… »
Clique droit sur le fichier qui a été exporté puis « Modifier« …
Remplacer la 1ere ligne :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates\49B9D02B5251E53C283FF46E77B5CAA9ACA36961]
par celle-ci :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Services\NTDS\SystemCertificates\My\Certificates\49B9D02B5251E53C283FF46E77B5CAA9ACA36961]
Il ne reste plus qu’à sauvegarder votre fichier et enfin, clic droit sur le fichier puis « Fusionner« .
Si vous vérifiez dans la base de registre ainsi que dans NTDS/Personnel (via la MMC), vous retrouverez le certificat !
Pas la peine de redémarrer les contrôleurs de domaine car AD DS détecte lorsqu’un nouveau certificat est déposé dans ce magasin de certificats, puis déclenche une mise à jour sans avoir à redémarrer AD DS ou redémarrer le contrôleur de domaine…
-
La troisième solution :
est de passer par un script PowerShell pour faire la même manipulation qu’au dessus mais en plus simple et avec un seul clic…
Exporter les certificats avec leur clef privé (fichier .pfx) dans notre dossier.
Créer le fichier Powershell (fichier .ps1) avec les indications ci-dessous :
$mypwd = Read-Host "Enter Password for PFX-File" -AsSecureString
$cert = Import-PfxCertificate -Password $mypwd -FilePath "c:\reqandcert\SVW-ACD-01.LEENDIS.LOCAL.pfx" cert:\localMachine\my
Move-Item "HKLM:\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates\$($cert.Thumbprint)" "HKLM:\SOFTWARE\Microsoft\Cryptography\Services\NTDS\SystemCertificates\MY\Certificates\"
Il ne restera plus qu’à lancer le script et le tour est joué ! Si vous vérifiez dans la base de registre ainsi que dans NTDS/Personnel (via la MMC), vous retrouverez le certificat !
4) Vérification de la connexion LDAPS
- Lancer l’outil « Ldp.exe« ,
- Dans le menu Connexion, cliquez sur Connecter,
- Indiquer le nom du contrôleur de domaine FQDN auquel vous souhaitez vous connecter,
- Taper 636 (port) et cocher la case SSL,
Les informations RootDSE doivent s’inscrire dans le volet droit…
Dans mon prochain post, nous aborderons la création de certificats pour LDAPS au travers de OpenSSL…
A bientôt !
Harry Cover.