Les systèmes d’exploitation
Les serveurs Windows sont de base configurés pour utiliser un annuaire Active Directory, et il est donc difficile de les raccorder à un serveur LDAP. Cependant, des solutions existent pour cela (ex. Samba, pGina) si cela s’avérait nécessaire.
Les serveurs Unix/Linux n’ont pas de client LDAP installé par défaut. Cependant, de nos jours, chaque distribution ou version peut disposer des packages d’installation nécessaires auprès de leurs serveurs de dépôts afin de pouvoir bénéficier de l’authentification LDAP.
Ci-après, deux exemples de configuration : pour un serveur Linux et pour un serveur Unix (AIX).
1. Les serveurs Linux Red Hat (cas d’un RHEL6)
a. Installation des packages
Pour installer le client LDAP OpenLDAP sur un serveur Red Hat et bénéficier du service "sssd",  il faudra au préalable disposer de la liste de paquetages suivante :
	•	openldap.x86_64
	•	openldap-clients.x86_64
	•	sssd-ldap.x86_64
	•	sssd-client.x86_64
	•	sssd-proxy.x86_64
	•	sssd.x86_64
	•	sssd-common.x86_64
	•	sssd-tools
	•	authconfig
	•	authconfig-gtk 
¬
Sur un système utilisant les paquetages .rpm, toujours privilégier l’installation par la commande YUM pour ainsi bénéficier de son service de résolution des dépendances. 
Le service "sssd" est apparu avec la version 6 de Red Hat et permet en fait de centraliser toutes les méthodes d’authentification dont le système peut avoir besoin (annuaire LDAP ou AD) et de s’interfaçer avec différents programmes ou applications ayant besoin de valider une authentification (su, ssh, login, etc.) via les mécanismes PAM ou le fichier de configuration /etc/nsswitch.conf. Il assure donc le rôle de fournisseur d’authentification (Auth_provider), mais aussi celui de fournisseur d’identité (Id_provider). Il possède également un puissant système de cache qui, une fois bien configuré, permet de réduire le nombre de requêtes aux serveurs d’authentification et de faire face à une indisponibilité des serveurs LDAP… ceci afin d’être toujours en mesure de s’authentifier avec son compte utilisateur personnel.
¬
Figure 13-1 - Mécanisme sssd
b. Configuration du service "sssd"
Pour configurer le service LDAP, il faudra utiliser la commande authconfig issue du paquetage précédemment installé.
Exemple
authconfig --enableldap --enableldapauth --ldapserver=ldap:
//xxx.xxx.xxx.xxx:389 --ldapbasedn="dc=exemple,dc=com"  --update
Cette commande va permettre de :
1.	Créer le fichier de configuration /etc/sssd/sssd.conf ci-dessous auquel il faudra ajouter les informations en gras italique :	
[root@test01 pam.d]# cat /etc/sssd/sssd.conf 
[domain/default]  
autofs_provider = ldap 
cache_credentials = True 
ldap_search_base = dc=exemple,dc=com 
krb5_realm = EXAMPLE.COM 
krb5_server = kerberos.example.com  id_provider = ldap 
auth_provider = ldap 
chpass_provider = ldap 
sudo_provider = ldap 
ldap_uri = ldaps://ldap01.exemple.com:636 
ldap_backup_uri = ldaps://ldap02.exemple.com:636 
ldap_default_bind_dn = cn=linux,ou=binds,ou=site1,dc=exemple,dc=com 
ldap_sudo_search_base = ou=sudoers,ou= site1,dc=exemple,dc=com 
enumerate = True 
debug_level = 7 
ldap_tls_cacertdir = /etc/openldap/cacerts 
ldap_tls_cacert = /etc/openldap/cacerts/DigiCertCA.crt 
ldap_tls_reqcert = allow 
 
[sssd] 
services = nss, pam, autofs, sudo 
config_file_version = 2 
domains = default 
 
[nss] 
homedir_substring = /home 
 
[pam] 
[sudo] 
[autofs] 
[ssh] 
[pac] 
[ifp]
2.	Démarrer le service "sssd".	
[root@test01 delivery]# service sssd status 
sssd (pid  2212) is running...
3.	Configurer le démarrage automatique du service "sssd" pour les niveaux d’exécution 3, 4 et 5.	
[root@ldap01 ~]# chkconfig --list sssd 
sssd     0:off   1:off   2:off   3:on    4:on    5:on    6:off
4.	Modifier le fichier /etc/nsswitch.conf en ajoutant la chaîne sss comme suit :	
passwd:     files sss 
shadow:     files sss 
group:      files sss
5.	Et enfin, modifier les fichiers PAM par défaut ci-dessous en y ajoutant la librairie "pam_sss.so".	
/etc/pam.d/system-auth-ac 
/etc/pam.d/password-auth-ac 
/etc/pam.d/fingerprint-auth-ac 
/etc/pam.d/smartcard-auth-ac
c. Ajout du certificat de l’autorité de certification
Afin de pouvoir établir une connexion sécurisée LDAPS, il faut copier le fichier contenant le certificat de l’autorité de certification (ici DigiCertCA.crt) à l’endroit précisé dans le fichier de configuration /etc/sssd/sssd.conf.
cp DigiCertCA.crt ’/etc/openldap/cacerts’ 
put in 750 with root :root
d. Mise à jour du fichier /etc/hosts
Le fichier /etc/hosts doit être mis à jour avec les alias des serveurs LDAP utilisés dans le fichier de configuration /etc/sssd/sssd.conf.
Attention à l’utilisation d’un serveur DNS avec les agents LDAP, en cas de perte de celui-ci ou surtout de mauvais fonctionnement, cela pourrait perturber l’authentification sur le système. Il est donc préconisé de toujours enregistrer la correspondance "nom FQDN/adresse IP" dans le fichier /etc/hosts du serveur et de mettre la résolution locale en priorité via le fichier /etc/nsswitch.conf.
e. Dissimulation du mot de passe du Bind user
Un autre avantage du service "sssd" est qu’il permet de hasher le mot de passe de l’utilisateur de liaison utilisé pour se connecter à l’annuaire.
Pour ce faire, il faut utiliser la commande sss_obfuscate -d default et entrer le mot de passe désiré.
Exemple
[root@ldap01 ~]# sss_obfuscate -d default 
Enter password:  
Re-enter password:
Contrôler par la suite que les lignes suivantes sont bien apparues dans le fichier /etc/sssd/sssd.conf.
ldap_default_authtok_type = obfuscated_password 
ldap_default_authtok=AAAQAEqhzaIt73J1sgOHhYqrxVdJ4v4l3mp5oS/ 
M90yH4txfUPIcsqyWc/DzZtnNrT5fZ/Nl+GjV75lIhyRZdwJDfqkAAQIDAAA=
f. Redémarrage du service "sssd"
Utiliser la commande : service sssd restart.
g. Vérifier le bon fonctionnement de la configuration
Utiliser la commande getent passwd laquelle devrait retourner tous les utilisateurs de l’annuaire.
Exemple
[root@ladp01 ~]# getent passwd 
root:x:0:0:root:/root:/bin/bash 
sshd:x:74:74:Privilege-separated  
SSH:/var/empty/sshd:/sbin/nologin 
it:x:757:750:ENTREPRISE/F/ENTREPRISE IT ACCOUNT:/home/it:/bin/bash 
........... 
testuser1:*:60002:60001:GGS IT TEAM  
Member:/home/testuser1:/bin/bash 
bboudj:*:60003:60001:GGS IT TEAM Member:/home/bboudj:/bin/bash 
nice06:*:60001:60001:GGS SUPPORT TEAM Member:/home/nice06:/bin/bash
Ce test permet de valider la connexion à l’annuaire LDAP.
Il est également intéressant de regarder au niveau des connexions réseau si la connexion avec l’annuaire LDAP est établie et aussi, selon le port utilisé, en déduire l’utilisation du LDAP ou du LDAPS (dans l’exemple ci-dessous, la connexion à l’annuaire est en LDAPS).
Exemple
[root@test01 pam.d]# netstat -na | egrep "389|636" 
tcp        0      0 10.76.104.210:47452         ldap01:636         ESTABLISHED
Faire ensuite un test de connexion avec un utilisateur avec la commande (su -) ou bien une commande ssh pour valider l’authentification avec le mot de passe.
Exemple
[root@test01 ~]# su - it 
[it@test01 ~]$ id 
uid=757(it) gid=750(cnr) groups=750(cnr) 
[it@test01 ~]$ su - testuser1 
Password: 
[testuser1@test01 ~]$ id 
uid=60012(testuser1) gid=60001(gtogldap)  
groups=60001(gtogldap),60002(gtoggsit) 
[testuser1@test01 ~]$
h. Observation du mécanisme PAM
Il est intéressant d’observer dans le fichier /var/log/secure, la façon dont le système gère l’authentification d’un utilisateur issue de l’annuaire LDAP. En effet, il apparaît bien dans l’exemple ci-dessous que l’utilisateur testuser1 est authentifié par le mécanisme pam_sss et non pas par le mécanisme local pam_unix.
Apr  3 08:08:52 test01 su: pam_unix(su-l:auth): authentication 
failure; logname=testuser1 uid=757 euid=0 tty=pts/1 ruser=it 
rhost=  user=testuser1 
Apr  3 08:08:52 test01 su: pam_sss(su-l:auth): authentication  
success; logname=testuser1 uid=757 euid=0 tty=pts/1 ruser=it 
rhost= user=testuser1 
Apr  3 08:08:52 test01 su: pam_unix(su-l:session): session opened 
for user testuser1 by testuser1(uid=757) 
Apr  3 08:09:47 test01 su: pam_unix(su-l:session): session closed 
for user testuser1
Beaucoup d’applications, dont su fait partie, s’appuient ainsi sur les modules PAM afin de s’affranchir de la gestion des authentifications tel que le montre la figure ci-dessous.
¬
Figure 13-2 Mécanisme PAM
¬
Afin d’identifier si une application utilise ou non les mécanismes d’authentification PAM, il suffit de regarder si elle fait appel à la librairie partagée libpam.so.
Exemple
[root@test01 ~]# which su 
/bin/su 
 
[root@test01 ~]# ldd /bin/su 
    linux-vdso.so.1 =>  (0x00007fff517ff000) 
    libpam.so.0 => /lib64/libpam.so.0 (0x00007f2776af9000) 
    libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00007f27768f5000) 
    libc.so.6 => /lib64/libc.so.6 (0x00007f2776560000) 
    libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f277633d000) 
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f2776139000) 
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f2775f01000) 
    /lib64/ld-linux-x86-64.so.2 (0x00000036fc200000) 
    libfreebl3.so => /lib64/libfreebl3.so (0x00007f2775c88000)
Le programme su s’appuie sur PAM pour gérer l’authentification des comptes, il a ainsi utilisé les mécanismes d’authentification au travers du fichier /etc/pam.d/su dont les principales actions pointent sur le fichier /etc/pam.d/system-auth.
Exemple
[root@test01 pam.d]# cat /etc/pam.d/su 
#%PAM-1.0 
auth            sufficient      pam_rootok.so 
# Uncomment the following line to implicitly trust users in the "wheel" group. 
#auth           sufficient      pam_wheel.so trust use_uid 
# Uncomment the following line to require a user to be in the "wheel" group. 
#auth           required        pam_wheel.so use_uid 
auth            include         system-auth 
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet 
account         include         system-auth 
password        include         system-auth 
session         include         system-auth 
session         optional        pam_xauth.so 
.... 
[root@test01 pam.d]# cat system-auth 
#%PAM-1.0 
# This file is auto-generated. 
# User changes will be destroyed the next time authconfig is run. 
auth        required      pam_env.so 
auth        sufficient    pam_fprintd.so 
auth        sufficient    pam_unix.so nullok try_first_pass 
auth        requisite     pam_succeed_if.so uid >= 500 quiet 
auth        sufficient    pam_sss.so use_first_pass 
auth        required      pam_deny.so 
 
account     required      pam_unix.so broken_shadow 
account     sufficient    pam_localuser.so 
account     sufficient    pam_succeed_if.so uid < 500 quiet 
account     [default=bad success=ok user_unknown=ignore] pam_sss.so 
account     required      pam_permit.so 
 
password    requisite     pam_cracklib.so try_first_pass retry=3 type= 
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok 
password    sufficient    pam_sss.so use_authtok 
password    required      pam_deny.so
2. Les serveurs IBM AIX
L’installation du client LDAP appelé ITDS client (IBM Tivoli Directory Server) sur un serveur AIX, qui est le serveur Unix d’IBM, est réalisée au travers des étapes de configuration ci-dessous. Cet exemple de configuration a été réalisé sur un serveur AIX 6.1.
a. Prérequis
Disposer des informations suivantes :
	•	Le nom ou l’adresse IP et ports utilisés par le serveur LDAP.
	•	La base de recherche des utilisateurs, des groupes et des IDs.
	•	L’utilisateur de liaison (BindUser) .
	•	Le certificat de l’autorité de certification qui a signé le certificat du serveur LDAP.
	•	Les flux 389/TCP et/ou 636/TCP doivent être autorisés depuis votre client LDAP vers le serveur LDAP.
	•	Disposer des paquetages (appelés "fileset" chez IBM) ci-dessous disponibles inclus dans l’image iso de base (appelé Global Image) du serveur AIX :
Exemple
- xlC.rte version 6.0.0.0 or higher  
- Java Client version 1.4.2 or higher  
- idsldap.clt32bit61.rte      Directory Server - 32 bit  Client 
- idsldap.clt64bit61.rte      Directory Server - 64 bit  Client 
- idsldap.clt_max_crypto32bit61.rte   Directory Server - 32 bit 
Client (SSL) 
- idsldap.clt_max_crypto64bit61.rte   Directory Server - 64 bit 
Client (SSL) 
- idsldap.cltbase61.adt       Directory Server - Base Client 
- idsldap.cltbase61.rte       Directory Server - Base Client 
- gsksa.rte     AIX Certificate and SSL Base Runtime ACME Toolkit 
- gskta.rte     AIX Certificate and SSL Base Runtime ACME Toolkit
b. Installation et configuration des paquetages de cryptographie (gsk)
Cette étape permettra d’utiliser les communications LDAP sécurisées par SSL (LDAPS).
Installation des paquetages gsk en ligne de commande :
- installp -acgXd /home/xxxx/gskta.rte gskta.rte 
- installp -acgXd /home/xxxx/gsksa.rte gsksa.rte 
Avec : 
-ac pour ’commit’, 
-g : permet d’installer des package requis, 
-X étend le système de fichier si necessaire, 
-d spécifie le répertoire où se trouve le paquetage.
¬
Sur les serveurs AIX, il est possible de configurer les paquetages applicatifs et autres paramètres système à l’aide d’une interface de configuration en mode texte nommé SMITTY. Cette interface est à la fois pratique, car complète et rapide (ne nécessite aucune ressource graphique dont le chargement de l’affichage peut devenir long).
Configuration de la cryptographie :
# Création de la ’KeyDB’ qui contiendra tous les éléments de 
cryptographie (certificat, autorité de certification, clef privée 
etc.). Celle-ci est encryptée. 
gsk7cmd -keydb -create -db /etc/clientkey.kdb -pw <password>  
-type cms 
# Création du fichier ’stash’  A CHERCHER A QUOI CA SERT 
gsk7cmd -keydb -stashpw -db /etc/clientkey.kdb -pw <password> 
# Importer le certificat de l’autorité de certification 
gsk7cmd -cert -add -db /etc/clientkey.kdb -pw <password> -file   
/tmp/rootCA.cer -format ascii -label LDAP_rootCA -trust enable 
# Vérifier que le certificat est bien dans la ’KeyDB’ 
gsk7cmd -cert -list -db /etc/clientkey.kdb -pw <password>
c. Installation et configuration des paquetages du client LDAP
Installation des paquetages idsldap en ligne de commande :
- installp -acgXd . idsldap.*
¬
En fonction de la version du client LDAP et de AIX, il faudra créer le lien suivant : ln -s /opt/IBM/ldap/V6.1/lib/libldap.a libldap.a.
Configuration du client LDAP :
mksecldap -c -h serveur_ldap -a <bind DN> -p <bind DN password> 
-d <base DN> -k /usr/ldap/etc/clientkey.kdb -w <key database 
password> -t 60 -A ldap_auth
d. Paramétrage système
Modifier /etc/security/user pour activer l’authentification LDAP sur le système.
chsec -f /etc/security/user -s default -a SYSTEM="files or LDAP"
S’assurer que les utilisateurs locaux (notamment root) utilisent les paramètres : SYSTEM = "compat" et REGISTRY = "files".
À partir de la version "AIX 5.3 TL9" jusqu’à la version "6.1 TL2", il faudra modifier le fichier security/ldap/2307aixuser.map :
Remplacer    :   lastupdate SEC_INT shadowlastchange s   days 
par    :         lastupdate SEC_INT shadowlastchange s   seconds
e. Vérification de l’installation du client LDAP
S’assurer que le processus client LDAP est démarré :
	•	ps -aef | grep -i secldap
	•	Auquel cas faire un stop/start :
	▪	stop-secldapclntd
	▪	start-secldapclntd
	•	Puis lister les paramètres chargés :
	▪	ls-secldapclntd
Exemple
ldapservers=MyldapServer 
current ldapserver=MyLdapServer 
ldapport=389 
active connections=1 
ldapversion=3 
usercachesize=1000 
usercacheused=0 
groupcachesize=100 
groupcacheused=0 
usercachetimeout=0 
groupcachetimeout=0 
heartbeat interval=300 
numberofthread=10 
connectionsperserver=10 
authtype=LDAP_AUTH 
searchmode=ALL 
defaultentrylocation=LDAP 
ldaptimeout=60 
serverschematype=RFC2307AIX 
userbasedn=ou=People,cn=aixdata 
groupbasedn=ou=Groups,cn=aixdata 
idbasedn=ou=System,cn=aixdata 
userobjectclass=posixaccount,account,shadowaccount,aixauxaccount, 
ibm-securityIdentities 
groupobjectclass=posixgroup,aixauxgroup
Enfin, effectuer un test réel :
	•	Passer la commande ci-dessous pour lister les utilisateurs de l’annuaire :
	▪	lsuser -R LDAP ALL
	•	Ou se connecter directement avec son compte :
	▪	su - "votre_compte".