On entend par « politique de sécurité », comment éviter les accès non autorisés aux ressources, aux hackers éventuels, pour éviter l’espionnage industriel ou bien encore eviter une attaque de type DDOS qui ralentirait fortement l'activité de l'entreprise.

Encore une fois il faudra porter une attention particulière au résultat de la commande pour voir si l’installation s’est effectuée avec succès. Pour pouvoir le vérifier il suffit de se rendre dans /usr/local/etc/openldap par défaut et de vérifier que les fichier de configuration pour slapd sont bien présents.

2. Sécurisation du serveur

Nous verrons dans cette partie comment configurer OpenLDAP grâce au fichier sldap.conf situé par défaut dans le répertoire /usr/local/etc/openldap.

2.1 Configuration des ACL (Acess Control List)

Voici une liste des différentes directives possible pour une ACL sous OpenLDAP :

what correspond ici à l’attribut, l’objet de l’annuaire sur lequel et appliqué l’ACL.
who spécifie quand à lui à qui ou quel groupe s’applique l’ACL.
Enfin access détermine le type d’accès et les droits effectifs.

Il est aussi possible de configurer plusieurs ACL pour une même entité. Ici ne sont pas traités tous les types de combinaison possibles pour toutes les avoir il suffit de consulter le man à propos de sladp.access pour plus d’informations.

2.1.1 Directive what

Cette directive permet de spécifier à quel objet s’applique l’ACL, il y a deux façon de le faire soit par filtre soit par DN (Distinguished Name) comme suit :

La première ligne spécifie que l’ACL s’applique à tous les objets.

La seconde ligne applique l’ACL qu’aux entrées dont la cible correspond à regexp selon la norme DN.

Enfin la dernière ligne permet d’appliquer une ACL sur tout un domaine ou bien un objet du domaine ce qui permet de plus affiner les droits. DN doit suivre la normalisation décrite dans la norme RFC2253.

Par exemple si l’annuaire contient les entrées suivantes :

0: o=suffix 1: cn=Manager,o=suffix 2: ou=people,o=suffix 3: uid=kdz,ou=people,o=suffix 4: cn=addresses,uid=kdz,ou=people,o=suffix 5: uid=hyc,ou=people,o=suffix

Alors :

dn.base="ou=people,o=suffix" correspond à 2; dn.one="ou=people,o=suffix" correspond à 3 et 5; dn.subtree="ou=people,o=suffix" correspond à 2, 3, 4, et 5; dn.children="ou=people,o=suffix" correspond à 3, 4, et 5

Il est aussi possible de sélectionner les entrées grâce à des filtres comme suit :

Où ldap filter représente le filtre de recherche selon la normalisation RFC2254.

En voici un exemple :

to filter=(objectClass=person) 

On peut aussi utiliser les filtres de la manière suivante :

to dn.one="ou=people,o=suffix" filter=(objectClass=person) 

2.1.2 Directive who

Cette directive permet de définir sur quel utilisateur ou bien sur quel objet de l’annuaire s’applique une ACL voici les différentes options possibles :

2.1.3 Directive access

Cette directive permet de définir le type de droit possible pour les entités présentes dans l’ACL voici une liste des différents droits définissable :

2.1.4 Exemple de configuration

1. access to * by * read … 2. access to attr=userPassword 3. by self write 4. by anonymous auth 5. by dn.base="cn=Admin,dc=example,dc=com" write 6. by * none 7. access to * 8. by self write 9. by dn.base="cn=Admin,dc=example,dc=com" write 10. by * read … 11. access to * by users read

Explication ligne par ligne :
1. Permet l’accès en lecture à tout le monde
2 à 10. L’attribut userPassword est modifiable que par l’Admin ainsi que tout autre objet
11. Permet l’accès en lecture uniquement aux utilisateurs authentifiés.

2.2 Sécurisation SASL

Que se soit le client ou bien le serveur OpenLDAP tous deux sont capables de s’authentifier via le frameworks SASL (Simple Authentification and Security Layer) dont la nomenclature est décrite dans la norme RFC2222.

Plusieurs mécanismes d’authentification peuvent être utilisés avec le SASL tel que : GSSAPI pour Kerberos V, DIGEST-MD5, PLAIN et EXTERNAL pour l’utilisation avec le TSL décrit plus loin.

Par défaut les clients OpenLDAP tels que ldapsearch et ldapmodify essaient de s’authentifier au serveur slapd en utilisant SASL.

Il est à noter que pour la suite de ce chapitre il est sous entendu que les technologies Kerberos ainsi que les technologies Cyrus SASL vous sont familières et que certains passages ne sont pas ainsi détaillés à l’extrême.

2.2.1 Mécanisme GSSAPI

Le GSSAPI peut être utilisé en tandem avec le Kerberos V sur un serveur OpenLDAP, par la suite il sera étudié le fonctionnement de ce couple.

Pour pouvoir utiliser ce couple il faut tout d’abord créer une clé pour le serveur ldap et que le serveur slapd puisse y avoir accès en ajoutant l’entrée pointant sur cette clé dans le fichier : /etc/krb5.keytab (pour plus d’information sur la création de celle-ci il suffit de se référer a la documentation livrée avec Kerberos et ou celle de Cyrus SASL).

Pour les clients ils devront alors se lancer grace à l’option –Y GSSAPI. Ainsi toute requête d’authentification selon le DN sera de la forme :

Ce mécanisme rend alors obsolète l’authentification Kerberos IV qui lui est moins sécurisé.

2.2.2 Mécanisme DIGEST-MD5

Ce mécanisme se base sur des mots de passes stockés dans la base de données de SASL mais appliqué à OpenLDAP elle peut tout aussi bien être stockée directement dans la base de donnée du service d’annuaire dans sasldb.

Pour ajouter un utilisateur dans la base sasldb il suffit d’utiliser le logiciel saslpasswd2 comme suit :

Pour s’assurer que les mots de passe ne soient pas cryptés il faudra alors dans le fichier sladp.conf section userPassword ajouter :

password-hash   {CLEARTEXT} 

Ainsi toute requête d’authentification selon le DN sera de la forme :

2.3 Sécurisation SSL/TLS

L’authentification sur un serveur OpenLDAP peut aussi se faire par certificats de sécurité par le protocole TLS (Transport Layer Security) et l’utilisation d’OpenSSL pour la création de ces derniers.

Après obtention des certificats de sécurités il faut ensuite configurer les clients et le serveur LDAP pour les prendre en compte. Coté client il faudra paramétré le serveur comme serveur de confiance pour les CA (Certificate Authority) tandis que le serveur devra être configuré avec ces même CA ainsi que sa clef privée livre avec le certificat.

2.3.1 Configuration coté serveur grâce au fichier slapd.conf

L’option TLSCACertificateFile "fichier" permet de pointer vers le fichier au format PEM contenant le CA en lequel le serveur slapd doit faire confiance.

L’option TLSCACertificatePath "chemin" est utilisée dans le cas où il existe plusieurs CA disponibles sur le serveur qui peuvent être gérés par l’utilitaire d’OpenSSL c_reash pour générer les liens symboliques pointant sur les différents certificats.

L’option TLSCertificateFile "fichier" permet de définir le certificat du serveur slapd en lui-même.

L’option TLSCertificateKeyFile "fichier" donne la location de la clé privée du certificat spécifié dans TLSCertificateFile. Etant une donnée sensible en général cette clé est encryptée et protégé par un mot de passe, mais pour le moment seul les clés non cryptées sont supportées et doivent donc bénéficier d’un haute protection.

L’option TLSCipherSuite "cipher-suite-spec" précise quel type de cryptage est utilisé pour obtenir la liste il suffit d’utiliser la commande :

openssl ciphers -v ALL 

L’option TLSVerifyClient { never | allow | try | demand } défini de quel manière doit réagir le serveur LDAP lors d’une connexion cliente. Par défaut la valeur never est utilisée qui est peut sécurisée car un client sans certificat peut se connecter. Les paramètres allow et try demandent au contraire au client un certificat mais de manière non obligatoire. Le paramètre demand quand à elle est la plus sécurisée car en l’absence de certificat valide la session est immédiatement clôturée.

2.3.2 Configuration coté client grâce au fichier ldap.conf

L’option TLS_CACERTDIR "chemin" est équivalente à l’option TLSCACertificatePath du serveur. Le répertoire spécifié doit être géré par l’utilitaire c_rehash d’OpenSSL.

L’option TLS_CERT "fichier" indique quel fichier contient le certificat du client. Etant un paramètre utilisateur il doit être défini dans le fichier utilisateur .ldaprc.

L’option TLS_KEY "fichier" indique le fichier contenant la clé privée du certificat défini avec l’option TLS_CERT. La même contrainte que pour le paramètre TLSCertificateKeyFile coté serveur s’applique aussi ici et c’est aussi un paramètre utilisateur uniquement.

L’option TLS_RANDFILE "fichier" est identique à l’option serveur TLSRandFile.

L’option TLS_REQCERT { never | allow | try | demand } est équivalente à l’option serveur TLSVerifyClient. Cependant coté client la valeur par défaut est demand il est fortement recommandé de changer cette valeur en une autre plus sécurisée.

2.5 Serveur Radius

Un serveur Radius est un serveur dédié à l’authentification que ce soit en réseau local ou bien en réseaux distant dans le cas par exemple d’un accès qui aurait le même mécanisme que le VPN.

Il faut aussi savoir que ce type de serveur a sa propre base de donnée utilisateur et ne s’appuie donc pas sur celle de l’annuaire de OpenLDAP à l'origine pour ainsi éviter toute faille de sécurité. Il existe plusieurs serveurs Radius proposant des modules pour le LDAP tel que FreeRadius qui sera traité par la suite.

2.5.1 Configuration du serveur Radius FreeRadius

Après la mise en place du serveur le fichier de configuration est situé dans le répertoire /etc/raddb (ou bien /usr/local/etc/raddb).

Voici un exemple de fichier radiusd.conf :

[...omissis] # Uncomment this if you want to use ldap (Auth-Type = LDAP) # Also uncomment it in the authenticate{} block below ldap { server = ldap.yourorg.com #login = "cn=admin,o=My Org,c=US" #password = mypass basedn = "ou=users,dc=yourorg,dc=com" filter = "(posixAccount)(uid=%u))" } [...omissis] # Authentication types, Auth-Type = System and PAM for now. authenticate { pam unix # sql # sql2 # Uncomment this if you want to use ldap (Auth-Type = LDAP) ldap } [...omissis]

Avec cette configuration on est donc en mesure de passer par le serveur Radius pour : un compte local et un compte d’annuaire ldap.

Il faut ensuite modifier le fichier dictionnary comme suis :

[...omissis] # # Non-Protocol Integer Translations # VALUE Auth-Type Local 0 VALUE Auth-Type System 1 VALUE Auth-Type SecurID 2 VALUE Auth-Type Crypt-Local 3 VALUE Auth-Type Reject 4 VALUE Auth-Type ActivCard 4 VALUE Auth-Type LDAP 5 [...omissis]

Et enfin le fichier users :

[...omissis] DEFAULT Auth-Type := LDAP Fall-Through = 1 [...omissis]

Il reste plus qu’à vérifier que le serveur Radius a bien obtenue les informations pour les uid et les mots de passe utilisateurs grâce aux attributs posixAccount part le serveur OpenLDAP.

2.5.2 Test du serveur Radius

Il est possible de tester son serveur pour voir si tout fonctionne correctement grâce au mode de « debug » pour cela il suffit d’utiliser la commande :

/usr/local/sbin/radiusd  -X –A 

Puis il suffit tout simplement de lancer le logiciel radtest comme suis :

radtest username "password" radius.yourorg.com 1 testing123 

Le serveur devrait si tout se passe bien renvoyer un paquet de type Access-Accept.

Conclusion

Cette article a pour but de vous présenter au mieux les différentes technologies pouvant être associées à un serveur OpenLDAP et pourvoir ainsi les comparer. Après un bref rappel sur l'installation d'OpenLDAP chaque technologies ayant été présentées j'espère que vous avez put choisir celle qui correspond au mieux à vos besoin. Il ne faudrat pas oublié la multitude de How To ou autres documentations traitant du sujet pour avoir plus de détail dans une technologie souhaité en voici quelques un : OpenLDAP Administrator Guide, LDAP Implementation Howto...