Acceder à Active Directory en ldaps

Jehan Procaccia MCI INT-EVRY- jehan.procaccia@int-evry.fr

9 mai 2006

Table des matières

Résumé : Ce document décrit la mise en place d'un accés LDAPS à l'Active Directory d'un serveur windows 2003 dans l'objectif de synchronisation d'annuaire openldap/AD.

1  Objectif

L'objectif est d'acceder à un annuaire Active Directory depuis n'importe quel client ldap (sous unix/ windows en shell, perl, java etc ...) afin de pouvoir y apporter des modifications. Ici il s'agit de synchroniser des informations (attributs) depuis un annuaire openldap vers AD . La premiere étape sera de disposer d'une interface de changement de mot de passe centralisée pour les 2 annuaires.

2  Références

Il existe de très bonne références sur le sujet, elles sont très completes, mais il manque souvent un petit detail, une étape ... par exemple pour la doc du CRU sur laquelle je me suis prinncipalement basé, elle considere, à juste titre !, que toute la phase de création des certificats se fait dans le cadre de la PKI du CRU. Ayant perdu pas mal de temps sur cette étape, nous avons souhaité documenter également cette partie .

Cru: http://www.cru.fr/faqdata/cache/149.html
Microsof:How to enable LDAP over SSL with a third-party certification authority http://support.microsoft.com/default.aspx?scid=kb;en-us;321051
Novell: http://www.novell.com/documentation/dirxmldrivers/index.html?page=/documentation/dirxmldrivers/ad/data/bp8clek.html#bupd66p
cacert.org: http://wiki.cacert.org/wiki/DomainController

3  Principes

Avant de pouvoir dialoguer en écriture sur un AD, il faut le joindre en mode sécurisé (SSL). De plus, ici nous allons utiliser une authorité de certification externe à windows. Il faudra alors intégrer dans le magasin de certificat de windows, le certificat racine de l'autorité ainsi que le certificat serveur( et client !) signé par cette autorité.

4  Autorité de certification openssl

4.1  Autorité

Un simple package openssl sous unix permet de constituer une autorité, voici une documentation avec des reférences expliquants ceci : http://www.int-evry.fr/s2ia/user/procacci/Doc/openssl.html#htoc17 .

4.2  Type de certificat pour AD

La doc du CRU (http://www.cru.fr/faqdata/cache/149.html) indique un momment donné; "une fois la requete validée par le cru ..." C'est justement là qu'il faut intervenir si on ne se fait pas singer par le CRU. Ce qui n'est pas clairement expliquer, c'est qu'il faut signer un certificat client et serveur !, en effet, d'apres l'exemple de certificat du CRU qu'on a bien voulu me faire parvenir, qu'il faut que dans les extensions il soit mentionné client et serveur:
Netscape Cert Type:
               SSL Client, SSL Server
X509v3 Key Usage: critical
               Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
               TLS Web Server Authentication, TLS Web Client Authentication


5  Procédure détaillée

5.1  Environement windows AD

L'experience a été réalisée sous un Windows 2003 server fraichement installé, sur lequel nous avons crée un AD (nouvelle foret et domaine autonomes) sync.int-evry.fr sur la machine spock.sync.int-evry.fr

5.2  Demande de certificat

Depuis windows (en mode commande) on peux réaliser une demande de certificat avec les outils microsoft de la façon suivante:
c:\temp> certreq -new request.inf request.req

Avec un fichier request.inf contenant notament le CN (nom DNS du serveur windows, suivit d'information propres a notre autorité de certification) et l'EnhancedKeyUsageExtension -> Server Authentication (1.3.6.1.5.5.7.3.1) (peut-etre pourrait-on intégrer directement ici Client Authentication (1.3.6.1.5.5.7.3.2 !?) . L'Extensions 2.5.29.17=cm9tYWluLmRhdW1vbnRAaW50LWV2cnkuZnI= correspond au codage en base64 de l'adresse electronique de contact (exemple admins@int-evry.fr)
[Version]
Signature="$Windows NT$"

[NewRequest]
Subject="CN=spock.sync.int-evry.fr,O=INT,L=Evry,ST=Essonne,C=FR"
KeySpec=1
KeyLength=1024
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

[Extensions]
2.5.29.17=cm9tYWluLmRhdW1vbnRAaW50LWV2cnkuZnI=

5.3  Signature de la demande

Apres envoie de cette requette à l'autorité de certification (transfert du fichier.req dans l'arborescence de la pki), on signe la demande.
[root@pki1 ~/pki-s2ia/ca]
$ openssl ca -config ./openssl.cnf -name CA_default -extensions SERVER_RSA_SSL -infiles /root/request.req

Cette signature, fait appel aux sections CA_default et CA_AD_SERVER qui vont caracteriser le type de certificat à creer. Voici pour exemple le contenu de ces sections du fichier de configuration openssl openssl.cnf
$ ls openssl.cnf ca
openssl.cnf

ca:
ca.crt  crl        index.txt       newcerts  serial      tmp
certs   index.old  index.txt.attr  private   serial.old

$ cat openssl.cnf
[ 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/ca.crt
serial          = $dir/ca/serial
private_key     = $dir/ca/private/ca.key
default_days    = 365
default_md      = sha1
preserve        = no
policy          = policy_match

[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 importe de noter ici que la section que nous avons creé [CA_AD_SERVER] contient une extension d'usage de la clé pour un client et un serveur: extendedKeyUsage = serverAuth, clientAuth . Voici le resultat de la singature:
[root@pki1 ~/pki-s2ia/ca/newcerts]
$ cat C0.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 192 (0xc0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=MCI Certificate Authority, O=INT, C=FR
        Validity
            Not Before: Apr  4 17:04:08 2006 GMT
            Not After : Apr  4 17:04:08 2007 GMT
        Subject: C=FR, ST=Essonne, L=Evry, O=INT, CN=spock.sync.int-evry.fr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
...
X509v3 extensions:
            Netscape Comment:
                Certificat Serveur AD
            X509v3 Subject Key Identifier:
                AE:80:6F:C0:28:18:46:AD:C7:ED:20:27:66:43:48:43:10:CC:CD:B9
            X509v3 Authority Key Identifier:
                keyid:16:B1:2E:5B:ED:D8:76:2D:62:84:1E:AD:B1:C6:CF:2C:93:F7:7B:D3
                DirName:/CN=MCI Certificate Authority/O=INT/C=FR
                serial:00

            X509v3 Issuer Alternative Name:
                <EMPTY>

            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            Netscape Cert Type:
                SSL Client, SSL Server
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
...
-----BEGIN CERTIFICATE-----
MIIDoDCCAoigAwIBAgICAMAwDQYJKoZIhvcNAQEFBQAwPzEiMCAGA1UEAxMZTUNJ
...
-----END CERTIFICATE-----


5.4  Verifications

verification sur le sujet et le role du certificat:
[root@pki1 ~/pki-s2ia/ca/newcerts]
$ openssl x509 -in C0.pem -purpose  -noout
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : No
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No


$ openssl x509 -in C0.pem -subject  -noout
subject= /C=FR/ST=Essonne/L=Evry/O=INT/CN=spock.sync.int-evry.fr

5.5  Manipulation sur le certificat

Il Faudra ensuite retirer toute la partie texte de ce certificat, pour ne garder que ce qui se trouve entre BEGIN CERTIFICATE et END CERTIFICATE .

5.6  Creation de la chaine

Pour cela il suffit de concatener le certificat client/serveur fraichement signé et épuré du ``bla bla'', avec le certificat d'autorité de la ca:
( cat spock-sync-short.pem ; cat ca.pem ) > sync-spock-ca-chain.cer 

5.7  Importation dans windows

Reste a ramener ce fichier sync-spock-ca-chain.cer et celui de l'autorité racine ca.pem sous windows et proceder à leur importation dans le magasin de certificats.
c:\temp>certreq -accept sync-spock-ca-chain.cer

Pour le certificat racine, un simple drag and drop dans "Autorités de certification racines de confiance" suffit.

Il faut ensuite redemarrer le système windows afin d'être assurer que tout est bien pris en compte.

6  Acces depuis linux à l'AD

Voici un exemple d'acces depuis un shell sous linux à l'Active Directory. Il faut que le client charge la certificat de l'autorité afin d'etre reconnu par le certificat de l'AD lui meme signé par la même autorité !:

Ici /etc/openldap/ldap.conf , fichier de configuration du client shell ldapsearch, contient: TLS_CACERT /etc/openldap/cacerts/ca.crt, ca.crt étant le certificat d'autorité.
ldapsearch -x -H ldaps://spock.sync.int-evry.fr cn=test1 -D cn=administrateur,cn=users,dc=sync,dc=int-evry,dc=fr -W -b dc=sync,dc=int-evry,dc=fr 


Ce document a été traduit de LATEX par HEVEA.