Contexte
Lors des interactions en LDAP avec Active Directory, certaines actions nécessitent l’utilisation de LDAPS (LDAP sur SSL) entre le client et Active Directory.
Ceci est notamment le cas si l’on veut modifier le mot de passe.
Ce document décrit comment activer le LDAPS sur un environnement Active Directory.
Méthodes envisageables
A priori il y a deux méthodes possibles pour activer LDAPS sur un contrôleur de domaine :
- Installer un Certificat Racine sur le contrôleur de domaine
- Utiliser un certificat tiers sur le contrôleur de domaine.
C’est la seconde méthode que nous allons détailler ici.
Procédure
Les étapes de mise en place sont les suivantes :
- Demande de certificat
- Signature de la demande de certificat
- Import du certificat sur le serveur
Certificat
Contraintes sur le certificat Le certificat qui sera généré doit respecter certaines contraintes :
- Il doit être validé pour l’authentification de server, c’est à dire contenir l’OID d’authentification du serveur (1.3.6.1.5.5.7.3.1)
- Le CN doit correspondre au FQDN du serveur. Par exemple, si mon serveur s’appelle pdc1.mondomaine.com, on aura CN=pdc1.mondomaine.com
Demande de certificat
La demande de certificat peut se faire dans une fenêtre de commande sous Windows, avec la commande suivante :
certreq -new request.inf request.req
On aura auparavant créé le fichier request.inf contenant les informations suivantes :
;----------------- request.inf ----------------- [Version] Signature="$Windows NT$” [NewRequest] Subject = "CN=pdc1.mondomaine.com,O=IT,C=FR" ; replace with the FQDN of the DC KeySpec = 1 KeyLength = 2048 ; 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 ;-----------------------------------------------
Note : les éléments du Subject doivent correspondre à ceux du certificat racine issu de la PKI.
Signature de la demande de certificat
La génération du certificat peut se faire via une commande OpenSSL, à partir du fichier request.req généré à l’étape précédente.
Le certificat racine aura été généré auparavant, dans le répertoire /srv/pki/certs. L'arborescence de ce répertoire est la suivante :
cd /srv/pki ls -R .: certs index.txt index.txt.attr newcerts private reqs serial ./certs: ca.crt ./newcerts: ./private: ca.key ./reqs: request.req
On va générér le certificat à partir de la requête :
openssl ca -config /srv/pki/openssl.cnf -name CA_default -extensions CA_AD_SERVER -infiles /srv/pki/ca/reqs/request.req
Le fichier openssl.cnf contient les lignes suivantes :
[ ca ] default_ca = CA_default [ CA_default ] dir = . certs = $dir/ca/certs new_certs_dir = $dir/ca/newcerts database = $dir/ca/index.txt certificate = $dir/ca/certs/ca.crt serial = $dir/ca/serial private_key = $dir/ca/private/ca.key default_days = 3650 default_md = sha256 preserve = no policy = policy_match # For the CA policy [ policy_match ] countryName = match stateOrProvinceName = optional organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ CA_AD_SERVER ] nsComment = "Certificat Serveur AD" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always issuerAltName = issuer:copy basicConstraints = critical,CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment nsCertType = client, server extendedKeyUsage = serverAuth, clientAuth
Il faut ensuite extraire les informations « brutes », situées entre -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----.
On va ensuite créer la “chaîne” de certificats, en concaténant le certificat racine :
cd /srv/pki/ca/certs cat dwdc1.crt ca.crt > dwdc1-chain.crt
Intégration du certificat
Les certificats dwdc1-chain.crt et le certificat racine sont ensuite copiés sur le serveur Windows.
Le certificat racine doit être intégré (en utilisant la console mmc) dans les autorités de certification racines de confiance.
Le certificat chaîne peut ensuite être intégré via la commande :
certreq -accept dwdc1-chain.crt I
On peut vérifier la bonne intégration, dans les certificats personnels.
Il faut alors redémarrer le serveur sur lequel on vient d’installer le certificat.
Vérification
On peut vérifier en lançant ldp.exe, et en tentant une connexion sur le contrôleur de domaine, port 636.
Références
Ce document est basé sur les éléments suivants :
http://www.it-sudparis.eu/s2ia/user/procacci/Doc/ldaps-ad/ldaps-ad.html
https://support.microsoft.com/en-us/help/321051/how-to-enable-ldap-over…
https://www.petri.com/enable-secure-ldap-windows-server-2008-2012-dc
https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-o…
Annexes
Pour plus de détails sur la partie SSL, on pourra se reporter à https://www.vincentliefooghe.net/content/mémento-openssl
Génération du Certificat Racine
On génère d’abord la clé privée :
openssl genrsa -des3 -out /srv/pki/ca/certs/ca.key 2048
Puis le certificat racine :
cd /srv/pki openssl req -new -x509 -days 3650 -key private/ca.key -sha256 -extensions v3_ca -out certs/ca.crt
Ajout du certificat dans OpenIDM
Si on veut activer les échanges sécurisés via SSL, il faut importer les certificats des serveurs distants dans le keystore OpenIDM.
On peut récupérer le nom du truststore dans le fichier de configuration (conf/boot/boot.properties). Par défaut, il s’agit de OPENIDM_HOME/security/truststore.
cd /products/openidm/security keytool -import -alias ADLDAPS -file /tmp/ca/certs/dwdc1.crt -keystore truststore
Il faut ensuite arrêter / relancer openidm
Bien entendu, dans la déclaration du provisioner.openicf.json on va activer le ssl :
"configurationProperties" : {
"host" : "&{AD.HostName}",
"port" : "&{AD.LdapServerPortSSL}",
"ssl" : true,
"principal" : "&{AD.DirectoryAdminName}",
"credentials" : {
"$crypto" : {