Petit point sur la synchronisation LDAP/Kerberos (cad du champ userPassword et des clés du KDC). J’ai décidé de faire ça avec l’overlay smbk5pwd fourni dans les contribution d’OpenLDAP. Cet overlay met à jour les clés (et eventuellement les empreintes NTLM et LM) en même que le champs userPassword lors d’une requête de changment de mot de passe (par exemple via ldappasswd). Cependant il faut faire face à plusieurs contraintes :
- Cet overlay ne marche que avec un KDC Heimdal. Un autre overlay qui interagit avec kadmind nommé smbkrb5pwd est disponible. Il est donc utilisable avec MIT et Heimdal mais n’est pas encore prêt pour la production.
- Les attributs Kerberos pour LDAP doivent être accolés à la feuille. On ne peut pas avoir une OU kerberos ou on stock les principals dedans. En effet, l’overlay regarde pour quelle feuille on demande le changement de mot de passe, ensuite il regarde si c’est un objet de type krb5KDCEntry et alors il met à jour les clés.
- Le KDC maître doit être sur le même machine que slapd car la communication se fait via un socket local (ldapi).
1. Installation de l’over-laid
On récupere les sources de slapd (synchronisées avec la version courante su paquet que l’on a installé) :
cd /usr/local/src
aptitude build-dep slapd
On se place dans les sources :
cd openldap-2.4.17
./configure
make depends
make
On installe évidement pas slapd, on va juste compiler l’overlay :
cd contrib/slapd-modules/smbk5pwd
aptitude install heimdal-dev
make
Note : il faut faire quelques petits ‘ln’ pour que ça passe :
ln -s /usr/lib/libldap_r-2.4.so.2 /usr/lib/libldap_r.so
ln -s /usr/lib/liblber-2.4.so.2 /usr/lib/liblber.so
ln -s /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so
Enfin, on déplace le contenu de .libs vers /usr/lib/ldap (endroit contenant les modules / overlays de slapd, du moins sous Debian).
mv .libs/* /usr/lib/ldap/
2. Configuration de slapd
Hypothèses :
- Mes utilisateurs sont stockés dans la branche ou=people,dc=garnett,dc=fr.
- Ils sont identifiés par un attribut ‘uid’ contenant leur matricule.
Pour activer l’overlay :
include /etc/ldap/schema/hdb.schema
include /etc/ldap/schema/samba.schema
moduleload smbk5pwd
...
database hdb
...
overlay smbk5pwd
Et ensuite quelques ACLs l’idée est de permettre l’accés en écriture au clés (même pas aux attributs Kerberos car ils sont ajoutés par une autre moulinette) :
access to dn.base="ou=people,dc=garnett,dc=fr"
by dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
by * read
access to dn.subtree="ou=people,dc=garnett,dc=fr"
attrs=krb5KeyVersionNumber,krb5Key
by dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
by * none
access to dn.subtree="ou=people,dc=garnett,dc=fr"
attrs=entry,objectclass,krb5PrincipalName,krb5MaxLife,\
krb5MaxRenew,uid,krb5KDCFlags
by dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by * noneLe DN de connexion bizarre est celui utilisé par la SASL lors de l’accès via ldapi. Avec ce jeu d’ACL (a ajuster selon vos besoins) on peut changer les clés des utilisateurs sans soucis et faire un dump du KDC. Je dois tester comment ça se comprote avec la réplication KDC maitre / esclave(s). pour voir si les ACLs merdouillent, slapd avec le loglevel à 128.
3. Configuration du KDC
On l’installe :
aptitude install heimdal-kdc
Il faut juste indiquer au KDC Heimdal d’utiliser un backend LDAP. dans le /etc/heimdal-kdc/kdc.conf :
[logging]
kdc = FILE:/var/log/heimdal-kdc.log
[kdc]
database = {
dbname = ldap:ou=people,dc=garnett,dc=fr
realm = UNIV-ORLEANS.FR
mkey_file = /var/lib/heimdal-kdc/m-key
acl_file = /etc/heimdal-kdc/kadmind.acl
}
[kadmin]
[password-quality]Puis dans le /etc/krb5.conf :
database = {
dbname = ldap:ou=people,dc=garnett,dc=fr
}Un restart du KDC Heimdal. Et on peu créer les principals par défaut :
kadmin -l
> init GARNETT.FR
Les principals par défaut ont du être crées dans la branche people (attention aux ACLs slapd, dans notre configuration on ne pourra pas le faire si directement).
4. Ajout des informations Kerberos à une feuille
Je suis dans le cas ou les gens existent déjà et donc on ne peut pas casser le LDAP. Un simple ldapmodify permet de s’en sortir. Créons le fichier kerb.ldif :
dn: uid=matricule,ou=people,dc=garnett,dc=fr
changetype: modify
add: objectClass
objectClass: krb5Principal
-
add: objectClass
objectClass: krb5KDCEntry
-
add: krb5PrincipalName
krb5PrincipalName: p10613@UNIV-ORLEANS.FR
-
add: krb5KeyVersionNumber
krb5KeyVersionNumber: 1
-
add: krb5MaxLife
krb5MaxLife: 86400
-
add: krb5MaxRenew
krb5MaxRenew: 604800
-
add: krb5KDCFlags
krb5KDCFlags: 126
-
On fait un ldapmodify et un changment de mot de passe derrière et les attributs krb5Key seront ajoutés à la feuille. Fin de l’histoire. Derrière on peut faire un kinit pour topper son ticket.
Hier soir j’ai terminé le livre “Extrusion Detection : Security Monitoring for Internal Intrusions” de