Nous présenterons ici quelques concepts généraux à propos de LDAP, la gestion des utilisateurs et des groupes.

Les serveurs d'annuaires peuvent être vus comme des bases de données stockant des renseignements. LDAP est le protocole utilisé pour accéder à ces services :

Figure 6.5. Protocole LDAP

Le type de bases de données varie beaucoup entre les implémentations. Ce pourrait être une base de données relationnelle standard, une base de données plus spécialisées comme Berkeley DB, un script dynamique qui génère la sortie, etc.

Toutefois, LDAP tend à être comparé aux bases de données relationnelles (SQL). Il existe des différences importantes :

Voici un court exemple d'un arbre qui s'étend sur plus d'un serveur :

Figure 6.6. Arbre LDAP

Les services d'authentification et d'autorisation sont de bons candidats pour l'utilisation d'un annuaire. Vu qu'ils ont besoin de performance de lecture maximale, ils subissent moins d'opérations d'écriture et peuvent être distribués dans une structure, tout en restant connectés.

L'ensemble de règles concernant les données stockées dans un annuaire s'appelle un schéma. Le schéma d'annuaire définit plusieurs éléments :

Le schéma souffre du complexe amour/haine. Il est avantageux pour la standardisation, mais il est parfois difficile d'ajouter des données à un annuaire. Alors que dans une base de données, c'est aussi simple que d'ajouter un nouveau champ, dans un annuaire, vous devez obéir au schéma. Vous ne pouvez pas simplement ajouter n'importe quel type d'attribut à une entrée : seulement ceux alloués par les classes d'objet.

Par exemple, voici la définition d'une classe d'objet person :

    objectclass ( 2.5.6.6 NAME 'person'
    DESC 'RFC2256: a person'
    SUP top STRUCTURAL
    MUST ( sn $ cn )
    MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
   

Ceci nous dit :

Figure 6.6, « Arbre LDAP » illustre aussi les attributs obligatoires et certains attributs optionnels de la classe d'objet person.

Le paquetage openldap-mandriva-dit offre une arborescence qui peut héberger les services décrits, ainsi que l'authentification et l'autorisation. Voici l'arborescence :

Figure 6.7. Arborescence

La première entrée de l'annuaire, dc=example,dc=com, est substituée lors de l'installation par le domaine DNS détecté.

Chaque groupe possède un ensemble de privilèges assignés à ses membres, et ce par défaut. Le membre initial est l'administrateur du groupe dans la branche Comptes système. Les privilèges sont tels que chaque membre peut administrer la branche de service respective. Donc, les membres du groupe Sudo Admins peuvent lire et écrire sur la branche ou=Sudoers.

Les autres groupes qui ne sont pas directement associés à un service sont décrits plus bas :

Par défaut, deux comptes supplémentaires sont fournis avec cet arbre : smbldap-tools et nssldap. Le premier est utilisé par la suite d'outils smbldap-tools et est membre du groupe Account Admins. Le deuxième, nssldap, est un compte de lecture générique et n'est pas utilisé par défaut par un quelconque service. Il est fourni par commodité pour l'administrateur. Aucun ACL spécial n'est en place pour ce compte.

Fibric possède une option pour installer la pile « intergiciel d'identité » (Identity Middleware) qui installe l'arbre dont nous venons de traiter. Une configuration de base est également faite :

Figure 6.8. Installer la pile Identity

Dans la pile Identity, l'option kerberos installera MIT Kerberos, et non Heimdal. Si vous avez besoin de l'intégration Kerberos avec LDAP, jetez un coup d'œil à la section d'authentification par Kerberos, qui traite de ce type d'intégration.

Après que les paquetages de Identity Stack ont été installés, (openldap-server et krb5-server), la pile peut être configurée. L'écran de configuration, quoique simple, configure complètement un arbre LDAP, qui répond à quelques besoins :

Figure 6.9. Configurer la pile Identity

Le paquetage openldap-mandriva-dit contient aussi un script d'installation qui peut être exécuté depuis une console. Le script est installé dans /usr/share/openldap/scripts/mandriva-dit-setup.sh et fait les mêmes modifications que Fibric, lesquelles sont :

Même si le script fait plusieurs tests et sauvegarde plusieurs fichiers avant de les écraser, nous avisons les administrateurs de faire une copie de sauvegarde de leurs données avant de l'exécuter.

Voici un exemple utilisant le domaine dc=example,dc=com :

# /usr/share/openldap/scripts/mandriva-dit-setup.sh
Please enter your DNS domain name [mycompany.com]:
example.com


Administrator account

The administrator account for this directory is
uid=LDAP Admin,ou=System Accounts,dc=example,dc=com

Please choose a password for this account:
New password: secretpass
Re-enter new password: secretpass


Summary
=======

Domain:      example.com
LDAP suffix: dc=example,dc=com

Confirm? (Y/n)            Y
config file testing succeeded
Stopping ldap service
Finished, starting ldap service
Running /usr/bin/db_recover on /var/lib/ldap
removing /var/lib/ldap/alock
Starting slapd (ldap + ldaps):                                  [  OK  ]

Your previous database directory has been backed up as /var/lib/ldap.1145397294
   

Maintenant le service ldap est fonctionnel. Vous pouvez utiliser le compte administrateur avec le mot de passe que nous venons de régler pour peupler l'arbre. C'est le seul compte activé dans l'arbre jusqu'à présent : tous les autres sont désactivés. Pour activer le compte d'administration, il doit posséder un mot de passe. Par exemple, activons le compte DNS Admin :

$ ldappasswd -x -D "uid=LDAP Admin,ou=System Accounts,dc=example,dc=com" \  
  -W -S "uid=DNS Admin,ou=System Accounts,dc=example,dc=com"
New password: newsecret
Re-enter new password: newsecret
Enter LDAP Password: here is the password for the bind (-D) user: LDAP Admin
Result: Success (0)
   

Maintenant, le compte DNS Admin possède un mot de passe et peut être utilisé pour administrer la branche ou=dns de l'arbre.

Plusieurs frontaux (front-end) existent pour LDAP et ils peuvent créer des comptes POSIX. Voici un exemple rapide en utilisant le programme Luma. Il possède plusieurs greffons (plugins) et un de ceux-ci permet de gérer les utilisateurs :

Figure 6.10. Greffon Luma

Voici le greffon de gestion des utilisateurs :

Figure 6.11. Greffon de gestion des utilisateurs

Premièrement, il faut indiquer sur quel serveur et quelle branche vous voulez ajouter un utilisateur. Dans cet exemple, nous nous plaçons sur la branche ou=People :

Figure 6.12. Où ajouter un utilisateur

Ensuite, nous entrons l'information nécessaire pour cet utilisateur :

Figure 6.13. Ajouter un utilisateur

Il est nécessaire de spécifier au moins un groupe primaire pour cet utilisateur. Les groupes POSIX LDAP seront automatiquement affichés, mais si vous n'en avez pas, alors la liste sera vide. Maintenant, nous sélectionnons gidNumber=100, qui appartient au groupe local users :

Figure 6.14. Groupes

Voici à quoi ressemble notre nouvel utilisateur dans LDAP :

Figure 6.15. Peter dans LDAP

	Avertissement
	Luma tentera de trouver un uidNumber libre pour l'allouer à cet utilisateur. Vous devriez toujours être prudent, toutefois, parce qu'il est incorrect que deux utilisateurs possèdent le même uidNumber.

Les groupes UNIX sont représentés dans LDAP en utilisant la classe posixGroup. Une entrée typique pour un groupe ressemble à :

    dn: cn=ldapusers,ou=Group,dc=example,dc=com
    objectClass: posixGroup
    gidNumber: 1024
    cn: ldapusers
    memberUid: peter
    memberUid: queen
   

Cette entrée définit un groupe appelé ldapusers avec un numéro d'identification de 1024 et, jusqu'à présent, deux membres appelés peter et queen.

Cette structure est assez simple pour être créée manuellement. Il faut simplement être prudent de ne pas donner le même numéro d'identification à plus d'un groupe.

Note

Les groupes système utilise une classe d'objet différente : groupOfNames. La différence principale est que l'adhésion est définie par un DN complet au lieu de seulement un nom, comme c'est le cas pour posixGroup. Malheureusement, posixGroup et groupOfUniqueNames ne peuvent pas être utilisés en même temps parce qu'ils tous les deux des classes structurelles. Nous nous attendons à ce que la révision du RFC2307 redéfinisse posixGroup en tant que classe auxiliaire.

Tous les membres du groupe cn=Account Admins,ou=System Groups,dc=example,dc=com peuvent gérer des comptes utilisateur dans ou=People, ou=Group et ou=Hosts (pour Samba, qui est expliqué plus loin). Tout administrateur LDAP (LDAP Admin) ou l'utilisateur Account Admin lui-même peut ajouter des membres à ce groupe.

	Astuce
	Les groupes système ont des propriétaires, et par défaut, le propriétaire peut toujours éditer l'adhésion du groupe qu'il possède. Pour voir qui est le propriétaire, vérifiez l'attribut owner du groupe système en question.

Par exemple, ajoutons l'utilisateur Peter Pingus, que nous venons de créer, à ce groupe privilégié pour qu'il puisse gérer des comptes :

$ ldapmodify -x -D 'uid=Account Admin,ou=System Accounts,dc=example,dc=com' -W
Enter LDAP Password: secretpassword 
dn: cn=Account Admins,ou=System Groups,dc=example,dc=com
changetype: modify
add: member
member: uid=peter,ou=People,dc=example,dc=com

^D
modifying entry "cn=Account Admins,ou=System Groups,dc=example,dc=com"
   

La même opération peut être faite avec un client graphique. Ajoutez simplement l'attribut member en pointant vers l'utilisateur dn que vous voulez ajouter à ce groupe.

La manière recommandée de créer des comptes Samba sur LDAP est d'utiliser le paquetage smbldap-tools. Ce paquetage possède plusieurs outils pour ajouter, supprimer ou modifier des utilisateurs et des groupes dans un arbre LDAP avec les attributs de Samba. Il peut même être utilisé avec les attributs de Samba et traiter avec ceux de POSIX.

En raison de conflits avec le paquetage Kerberos de MIT, Heimdal est packagé comme suit dans Mandriva Corporate Server 4 :

Les conflits ont été résolus. Seulement heimdal-libs peut être installé concurremment avec les bibliothèques de MIT.

Voici un survol rapide des changements nécessaires pour que Heimdal puisse utiliser OpenLDAP en tant que système dorsal de base de données, et utiliser le DIT openldap-mandriva-dit :

Afin d'obtenir une base de données sur LDAP, la section [kdc] suivante doit être utilisée dans le fichier /etc/krb5.conf de Heimdal :

    [kdc]
    database = {
    dbname = ldap:ou=People,dc=example,dc=com
    mkey_file = /var/heimdal/mkey
    acl_file = /var/heimdal/kadmind.acl
    }
   

Ceci donnera comme directive à Heimdal d'utiliser le serveur OpenLDAP installé sur le même hôte et d'utiliser la branche ou=People pour ces principaux. La méthode d'accès Heimdal utilise ldapi://, qui est une interface de connexion (socket) UNIX sur le système de fichiers local. L'authentification est gérée par SASL EXTERNAL, que nous configurerons à l'instant.

OpenLDAP doit être configuré pour accepter les connexions via ldapi://. Il faut éditer le fichier /etc/sysconfig/ldap. Changez la liste SLAPD URL pour celle-ci :

    # SLAPD URL list
    SLAPDURLLIST="ldap:/// ldaps:/// ldapi:///"
   

OpenLDAP doit ensuite être redémarré.

Heimdal utilise SASL EXTERNAL pour s'authentifier au serveur OpenLDAP lorsqu'il se connecte via une interface de connexion ldapi://. Ce faisant, le lien dn devient :

    # ldapwhoami -Y EXTERNAL -H ldapi:///var/run/ldap/ldapi
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    Result: Success (0)
   

Nous allons lier ce dn à un binddn plus significatif via authz-regexp. Le fichier slapd.conf fourni avec openldap-mandriva-dit fait déjà cela, mais dans un souci d'exhaustivité, le voici de toute manière :

    (...)
    ppolicy_default "cn=default,ou=Password Policies,dc=example,dc=com"
    
    authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
    "uid=Account Admin,ou=System Accounts,dc=example,dc=com"
    authz-regexp ^uid=([^,]+),cn=[^,]+,cn=auth$ uid=$1,ou=People,dc=example,dc=com
   

Avec cette modification et après avoir redémarré OpenLDAP, ldapwhoami sait maintenant que nous sommes le Account Admin :

    # ldapwhoami -Y EXTERNAL -H ldapi:///var/run/ldap/ldapi
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    dn:uid=account admin,ou=system accounts,dc=example,dc=com
    Result: Success (0)
   

Notez que tout processus connectant à l'interface de connexion ldapi:// en tant que root (uid=0, gid=0) sera traité comme un Account Administrator après ce changement!

Nous pouvons maintenant initialiser l'univers Kerberos. Après que OpenLDAP aura été redémarré, exécutez la commande suivante :

    # kadmin -l
    kadmin> init EXAMPLE.COM
    Realm max ticket life [unlimited]:7d
    Realm max renewable ticket life [unlimited]:7d
    kadmin
   

Ceci créera quelques principaux par défaut sous ou=People :

ou=People
  krb5PrincipalName=krbtgt/EXAMPLE.COM@EXAMPLE.COM,ou=People,dc=example,dc=com
  krb5PrincipalName=kadmin/changepw@EXAMPLE.COM,ou=People,dc=example,dc=com
  krb5PrincipalName=kadmin/admin@EXAMPLE.COM,ou=People,dc=example,dc=com
  krb5PrincipalName=changepw/kerberos@EXAMPLE.COM,ou=People,dc=example,dc=co
  krb5PrincipalName=kadmin/hprop@EXAMPLE.COM,ou=People,dc=example,dc=com
  krb5PrincipalName=default@EXAMPLE.COM,ou=People,dc=example,dc=com
   

Le schéma Heimdal permet aux comptes principaux d'être stockés sur une branche différente de celles des comptes utilisateurs. Par exemple, vous pourriez placer les comptes principaux sous ou=KerberosPrincipals et les comptes utilisateurs sous ou=People.

Cette façon de faire possède un désavantage évident, soit de créer un problème dans la gestion des utilisateurs : lorsqu'un utilisateur est supprimé, par exemple, le compte principal correspondant est aussi supprimé. En d'autres mots, nous aurions besoin d'un pointeur dans l'entrée utilisateur pour le compte principal (l'attribut seeAlso est couramment utilisé pour des manœuvres de ce genre). Et un script devrait suivre cet attribut et supprimer le compte principal.

L'avantage serait qu'un utilisateur peut être associé avec plusieurs principaux kerberos en utilisant l'attribut seeAlso, comme john@UNIVERS et john/admin@UNIVERS.

Le plus gros désavantage des schémas où les principaux sont séparés des utilisateurs est l'intégration avec Samba et Ldap simple binds : il est perdu ! Heimdal ne mettra à jour que le hash du mot de passe de Samba s'il est stocké dans la même entrée. La même chose se produit avec userPassword : vu qu'OpenLDAP utilise le module smbk5pwdi (compilé en prenant en charge kerberos), les liens simples ne pourront qu'utiliser le mot de passe de kerberos si tout est dans la même entrée.

Une autre option serait de stocker les clés principales et les attributs qui y sont relatifs juste sous l'entrée utilisateur. Nous pouvons faire cela car les classes d'objet kerberos sont auxiliaires. Donc, l'utilisateur John serait, par exemple : uid=john,ou=people,dc=example,dc=com, et les clés kerberos seraient stockées dans cette même entrée. Lorsque cet utilisateur est supprimé, le compte principal l'est aussi. Le désavantage est qu'un utilisateur ne peut avoir qu'un principal, et non plusieurs comme dans le cas précédent (où john pouvait avoir john@UNIVERS et john/admin@UNIVERS associés à la même entrée uid=john,ou=people,dc=example,dc=com).

Mais un problème surgit : qu'utilisons-nous pour créer cet utilisateur en premier lieu? Si nous utilisons kadmin, cela créera une entrée de la forme suivante : krb5PrincipalName=john@EXAMPLE.COM,ou=People,dc=example,dc=com, le compte étant la classe d'objet structurel. Comme nous tendons à utiliser une classe dérivée de person en tant que classe structurelle (comme inetOrgPerson), il y a conflit. Si nous utilisons kadmin, nous aurions à supprimer l'entrée et à l'ajouter à nouveau avec inetOrgPerson (et ses attributs obligatoires).

Nous pouvons changer la classe structurelle que Heimdal utilisera, mais cela n'ajoute pas les attributs obligatoires alors nous ne pouvons pas simplement changer pour inetOrgPerson dans la configuration de Heimdal : ça ne marchera pas.

Une meilleure option serait de créer en premier lieu l'utilisateur avec un autre outil comme smbldap ou un autre script, puis ajouter les attributs kerberos plus tard. Les avantages principaux sont :

Le plus gros désavantage est que la table de correspondance entre les utilisateurs et les principaux serait de 1:1, ce qui signifie qu'un utilisateur pourrait avoir au plus un principal kerberos associé avec son entrée.

Toutefois, les deux schémas peuvent être utilisés ensemble. La question qui nous préoccupe est plutôt comment allons nous gérer les comptes. Donc, les utilisateurs réguliers pourraient stockés leur clé kerberos dans l'entrée utilisateur, tandis que les clés d'administration et de service pourraient être stockés sous la même branche, mais qu'aucun utilisateur n'y soit associé. Ce n'est pas très constant en regard de l'arbre (après tout, ou=People était censé hébergé des personnes), mais ça marche.

Nous continuons avec deux exemples : l'utilisation de kadmin directement, et l'utilisation d'un autre script pour créer en premier lieu le compte utilisateur et ensuite, ajouter les attributs kerberos.

Nous allons créer un compte kerberos pour l'utilisateur « john » en utilisant kadmin directement. Nous n'avons pas à démarrer Heimdal à ce stade puisque nous allons utiliser kadmin en mode local :

    # kadmin -l
    kadmin> add john
    Max ticket life [1 day]:10h
    Max renewable life [1 week]:1w
    Principal expiration time [never]:
    Password expiration time [never]:
    Attributes []:
    john@EXAMPLE.COM's Password: somesecretpassword
    Verifying - john@EXAMPLE.COM's Password: somesecretpassword
    kadmin>
   

Cela crée l'entrée suivante :

    dn: krb5PrincipalName=john@EXAMPLE.COM,ou=People,dc=example,dc=com
    objectClass: top
    objectClass: account
    objectClass: krb5Principal
    objectClass: krb5KDCEntry
    krb5PrincipalName: john@EXAMPLE.COM
    uid: john
    krb5KeyVersionNumber: 0
    krb5MaxLife: 36000
    krb5MaxRenew: 604800
    krb5KDCFlags: 126
    (...)
   

On peut obtenir un billet pour cet utilisateur :

    # service heimdal start
    Starting kdc:                                                  [  OK  ]
    # kinit john
    john@EXAMPLE.COM's Password: somesecretpassword
    # klist
    Credentials cache: FILE:/tmp/krb5cc_0
    Principal: john@EXAMPLE.COM

    Issued           Expires          Principal
    Jun 20 15:43:23  Jun 20 22:23:23  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    #
   

Cependant, remarquez que l'utilisateur john n'a pas les attributs POSIX nécessaires pour devenir un utilisateur système. De toute façon, nous avons besoin d'autre chose pour créer cet utilisateur POSIX : ici, le rôle de Heimdal est terminé.

Si le compte utilisateur existe déjà dans l'annuaire, nous n'avons qu'à ajouter les classes d'objet Heimdal nécessaires pour ce compte. Étant un auxiliaire, cela fait beaucoup de sens.

Donc, pour cet exemple, nous utiliserons un paquetage smbldap-tools préconfiguré pour créer un utilisateur modèle et ensuite, nous lui ajouterons les classes kerberos et les attributs, mais n'importe quel utilisateur POSIX déjà existant marcherait.

Remarquez que nous n'ajoutons pas les attributs Samba tout de suite :

    # smbldap-useradd mary
    # getent passwd mary
    mary:x:1001:513:System User:/home/mary:/bin/bash
   

L'utilisateur ressemble à ceci dans l'annuaire :

    dn: uid=mary,ou=People,dc=example,dc=com
    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: posixAccount
    objectClass: shadowAccount
    cn: mary
    sn: mary
    givenName: mary
    uid: mary
    uidNumber: 1001
    gidNumber: 513
    homeDirectory: /home/mary
    loginShell: /bin/bash
    gecos: System User
    userPassword: {crypt}x
   

Nous utiliserons la modification LDAP suivante pour ajouter les attributs et classes kerberos à cet utilisateur :

    $ ldapmodify -x -D 'uid=Account Admin,ou=System Accounts,dc=example,dc=com' -W
    Enter LDAP Password: somepassword
     dn: uid=mary,ou=people,dc=example,dc=com
     changetype: modify
     add: objectClass
     objectClass: krb5Principal
     objectClass: krb5KDCEntry
     -
     add: krb5PrincipalName
     krb5PrincipalName: mary@EXAMPLE.COM
     -
     add: krb5KDCFlags
     krb5KDCFlags: 126
     -
     add: krb5KeyVersionNumber
     krb5KeyVersionNumber: 0
    
    modifying entry "uid=mary,ou=people,dc=example,dc=com"
   

Maintenant, mary est reconnue en tant que principal kerberos. Heimdal peut ajouter les clés et autres attributs manquants en tapant la commande de changement de mot de passe en tant qu'administrateur ou en mode admin local :

    # kadmin -l
    kadmin> passwd mary
    mary@EXAMPLE.COM's Password: somesecretpass
    Verifying - mary@EXAMPLE.COM's Password:
    somesecretpass  kadmin>
   

Ceci ajoute les attributs manquants et maintenant, mary est un principal kerberos complet :

    $ kinit mary
    mary@EXAMPLE.COM's Password: somesecretpass
    $ klist
    Credentials cache: FILE:/tmp/krb5cc_500
    Principal: mary@EXAMPLE.COM

    Issued           Expires          Principal
    Jun 20 16:14:48  Jun 20 22:54:48  krbtgt/EXAMPLE.COM@EXAMPLE.COM $
   

mary est également un compte POSIX. À titre de rappel : dans une seule entrée LDAP, nous avons POSIX, Samba et Kerberos. Mais il existe toujours trois sources de mot de passe. Voyez la prochaine section.

La fonction la plus recherchée dans un réglage où Heimdal utilise OpenLDAP en tant que système dorsal de base de données est l'intégration de mot de passe.

Sur un réseau, il existe trois sources d'authentification très communes, soit les mots de passe Samba, les mots de passe POSIX et les mots de passe Kerberos. L'utilisation de LDAP ne rend pas magique l'intégration des trois mots de passe : LDAP n'est qu'un espace de stockage et, en effet, chaque application l'utilise pour elle-même. Par exemple, voici les attributs utilisés pour le stockage de password ou secrets par Samba, Heimdal et POSIX :

Donc, pam_ldap peut changer le userPassword lorsque l'utilisateur exécute la commande password depuis la console, mais la clé Heimdal et les hashs Samba ne seront pas changés. Donc, nous avons un problème de synchronisation.

Certains administrateurs exécutent des scripts pour régler ce problème, ou n'alloue qu'à l'utilisateur de changer son mot de passe via un frontal quelconque qui prendra en charge les détails concernant la mise à jour de tous les hashs. Une autre option consiste à utiliser le module smbk5pwd.

Le module smbk5pwd est disponible dans le répertoire contribs du tarball OpenLDAP et, lorsque compilé avec le support Samba et Kerberos, il permet cette intégration de mot de passe automatiquement. Ce module est disponible par défaut dans le paquetage openldap-servers.

L'intégration se déroule en trois temps :

Les modifications de configuration suivantes sont nécessaires afin d'utiliser le module smbk5pwd :

    (...)
    modulepath      /usr/lib/openldap
    moduleload      back_monitor.la
    moduleload      syncprov.la
    moduleload      ppolicy.la
    moduleload      smbk5pwd.so
    password-hash   {K5KEY}
    (...)
    database bdb
    (...)
    overlay ppolicy
    ppolicy_default "cn=default,ou=Password Policies,dc=example,dc=com"
    
    overlay smbk5pwd
    (...)
   

Si nous ne changeons pas le mécanisme de hash du mot de passe serveur à {K5KEY}, alors les changements de mot de passe via EXOP écraseront l'attribut userPassword avec le nouvel hash au lieu de laisser {K5KEY}.

Le module smbk5pwd accepte certaines instructions de configuration comme smbk5pwd-enable et smbk5pwd-must-change. Veuillez lire le fichier README dans le répertoire de documentation openldap-servers pour plus de détails.

Si Samba est utilisé, alors l'option ldap passwd sync devrait être réglée à Only. Avec cette option, Samba ne fera que la modification de mot de passe EXOP, et attendez-vous à ce que le serveur OpenLDAP mette à jour les hashs de Samba, soit exactement ce que fait smbk5pwd.

Dans la section [global] de /etc/samba/smb.conf, ajoutez:

    ldap passwd sync = Only
   

Mainteneant, testez ldappasswd, smbpasswd et kpasswd : un changement de mot de passe réalisé par une ou l'autre de ces applciations devrait changer les trois sources d'authentification.

La fondation par défaut d'OpenLDAP se nomme BDB (Berkeley DataBase). C'est une base de donnée robuste utilisée par de nombreux projets hautement paramétrables avec le fichier DB_CONFIG.

OpenLDAP (la version packagée par Mandriva Linux) est livré par défaut avec un fichier DB_CONFIG, mais celui-ci devrait être ajusté pour chaque environnement spécifique. Une configuration incorrecte peut causer de sérieux problèmes de performances ainsi que des problèmes d'intégrité de données.

Nous présentons ici les options clés de DB_CONFIG que tout administrateur OpenLDAP devrait connaître.

La plupart des configurations de DB_CONFIG prennent effet au chargement de la base de données, ce qui peut ête accompli avec la commande db_recover. Par exemple, pour rebâtir l'environement dans /var/lib/ldap, la commande serait db_recover -v -h /var/lib/ldap (-v pour voir plus de détails).

	Avertissement
	Il faut toujours exécuter db_recover lorsque le démon slapd est arrêté.

Après avoir ajusté DB_CONFIG, particulièrement le paramètre relié à la cache, vous devriez utiliser la commande db_stat -m -h /var/lib/ldap pour en vérifier l'efficacité. Vous verrez alors un rapport du pourcentage de requêtes en cache. Vous voulez une valeur suppérieur à 90 %. Si votre serveur a assez de RAM, ceci peut-être gonflé jusqu'à 99 % ou même 100 %.

En plus de la cache de BDB, OpenLDAP possède aussi sa propre cache. La paramètre de configuration cachesize prend une valeur comme argument qui détermine le nombre d'entrées qui doivent être conservées en cache. La valeur par défaut est 1000 (mille). C'est différent de la cache BDB et son impact est moindre sur les performances.

Les index constituent la pierre angulaire de tous les types de bases de données, OpenLDAP inclus. Sans index, les recherches peuvent être longues à compléter, et avoir un impact important sur le CPU.

Le paramètre index dans la section database de slapd.conf est utilisé pour spécifier quel attribut doit être indexé avec quel type d'index. La syntaxe habituelle est :

    index <attr1[,attr2,...]> <[pres,eq,approx,sub]>
   

Le type d'index varie selon le type de recherche prévue pour cet attribut. Par exemple, les recherches de type (uid=*john*) auront besoin d'un index sub pour la rapidité. Voici les types d'index les plus communs :

Le prochain exemple utilise différents types d'index pour certains attributs :

    index   objectClass,uid,uidNumber,gidNumber,memberUid   eq
    index   ou                                              eq
    index   cn,mail,surname,givenname                       eq,sub
    index   entryCSN,contextCSN,entryUUID                   eq
   

Dès qu'une recherche est lancée sur les attributs qui n'ont pas d'index appropriés, un mise en garde sera écrite dans slapd :

    Jul 31 14:12:36 pandora slapd[15130]: conn=8 op=1 SRCH
    base="dc=example,dc=com" scope=2 deref=0 filter="(ou=remotes)" Jul 31
    14:12:36 pandora slapd[15130]: <= bdb_equality_candidates: (ou)
    index_param failed (18)
   

Dès que ceci arrive, cela indique que la recherche a été particulièrement lente. Soit l'attribut doit être indexé, soit la recherche doit être modifiée pour inclure cet attribut.

Lorsqu'un index est ajouté après que la base de données ait été peuplé, celle-ci doit être réindexée. Cette tâche est accomplie en arrêtant le service et en exécutant la commande slapindex. Ce processus réindexera tous les attributs, ce qui peut être long pour certaines bases de données volumineuses.

OpenLDAP peut bénéficier d'un serveur avec beaucoup de RAM. Lorsque c'est possible, ou si vous constatez que la cache n'est pas très performante, ajoutez de la RAM à votre serveur. L'annuaire s'en portera mieux et vos utilisateurs également...

La superposition politique de mot de passe (ppolicy.la) intercepte les changements de mots de passe LDAP et y applique plusieurs politiques telles que :

Plusieurs politiques peuvent être définies sur le serveur et tous les usagers peuvent être assignés à n'importe quelle politique, ou recevoir celle par défaut.

	Astuce
	Les versions récentes de pam_ldap (182 ou plus) supporte ce module OpenLDAP. Pour l'activer, ajoutez pam_lookup_policy yes dans /etc/ldap.conf.

À titre d'exemple, nous allons configurer un compte avec un changement de mot de passe forcé, une longueur minimum avec un historique de mot de passe. La liste complète des politiques et leur usage sont documentés dans la page de man slapo-ppolicy(5).

Pour assigner une politique différente selon l'usager, utilisez l'attribut pwdPolicySubentry et pointez le vers le dn de la politique à utiliser. Par exemple, pour appliquer la politique cn=marketing à l'usager peter, faites :

    $ ldapmodify -x -D 'uid=Account Admin,ou=System Accounts,dc=example,dc=com' -W
    Enter LDAP Password: secretpassword
     dn: uid=peter,ou=People,dc=example,dc=com
     changetype: modify
     add: pwdPolicySubentry
     pwdPolicySubentry: cn=marketing,ou=Password Policies,dc=example,dc=com
    
    modifying entry "uid=peter,ou=People,dc=example,dc=com"
    
    ^D
   

De cette façon, nous pouvons avoir différentes politiques appliquées à différents usagers. À l'heure actuelle, il n'est pas possible d'appliquer une politique à un groupe d'usagers, le changement doit être appliqué à chaque usager avec l'attribut pwdPolicySubentry.

Avertissement

Soyez prudent lorsque vous utlisez les politiques de mots de passe de OpenLDAP avec des applications qui ont leur propre politique ou le propre hash de mots de passe. Samba est un bon exemple. L'utilisation des politiques de Samba et de OpenLDAP en même temps serait problématique, compte tenu que Samba utilise ses propres attributs de mot de passe, tandis que OpenLDAP surveille userPassword. Il est possible que Samba permette un changement de mot de passe pendant que OpenLDAP le refuse en raison de politiques divergentes.

La superposition unique (unique overlay) est utilisée en prévention qu'une partie de l'arborescence ne répète une paire attribut-valeur. Par exemple, la branche ou=People pourrait surveillée les changements dans l'attribut uidNumber. Si un changement devait survenir demandant d'utiliser un numéro pour cet attribut qui est déjà utilisé ailleurs, le changement serait refusé. Donc, chaque écriture vers un attribut surveillé déclenche une recherche LDAP pour cet attribut et vérifie si cette valeur est assignée quelque part dans la branche surveillée.

	Avertissement
	Il est très important que l'attribut surveillé ait l'index approprié !

À titre d'exemple, configurons le serveur pour prévenir la duplication de uidNumber et cn sous ou=People. Toutes les options sont décrites dans la page de man slapo-unique(5).

	Astuce
	Prenez soin de ne pas lister d'attributs qui pourraient avoir des valeurs doublées. gidNumber, par exemple, pendant qu'il est unique pour identifier un groupe POSIX, peut être utilisé plusieurs fois avec la même valeur sous ou=People : pensez aux usagers qui partagent le même groupe principal.

Les groupes et les listes dynamiques sont très similaires et peuvent être utilisés pour peupler automatiquement une entrée avec des éléments.

Par exemple, nous pourrions avoir une liste dynamique qui s'étendrait automatiquement pour inclure toutes les addresses email que nous avons assignées à des utilisateurs. Ce serait notre alias email all@example.com.

De la même manière, nous pourrions avoir un groupe nommé allusers qui serait toujours à jour concernant les usagers de notre annuaire. Si un usager est supprimé ou ajouté, le groupe refléterait ce changement dès que recherché.

Dès qu'un entrée avec une classe surveillée est retournée suite à une requête, une recherche est lancée pour assembler les attributs qui doivent être retournés avec la requête. C'est cette recherche qui rend l'entrée dynamique. Les paramètres de recherche sont encodés dans un attribut de cette même entrée.

L'exemple suivant illustre comment configurer l'alias email automatique présenté plus haut, qui s'étendra toujours pour inclure tous les usagers de l'annuaire :

Nous allons faire une configurations similaire, mais pour le groupe dynamique.

Notez cependant qu'une recherche comme celle présentée plus bas ne fonctionnerait pas sur un groupe dynamique.

$ ldapsearch -x -LLL -b ou=Group,dc=example,dc=com "(&(objectClass=groupOfNames)(member=uid=queen,ou=People,dc=example,dc=com))"
    $
   

Pour que cela fonctionne, le serveur devrait effectuer la recherche spécifiée dans labeledURI pour chaque groupe, ce qui n'est pas supporté présentement. Mais une comparaison fonctionne :

    $ ldapcompare -x cn=allusers,ou=group,dc=example,dc=com member:uid=queen,ou=People,dc=example,dc=com
TRUE
   

L'intégrité référentielle est une fonctionnalité commune dans les bases de données relationnelles. Ce concept signifie que lorsqu'une entrée qui est requise par une autre est supprimée, l'opération est refusée. Un scénario commun dans le monde LDAP serait de supprimer un compte utilisateur sans supprimer l'usager du groupe. Ce qui occasionnerait des usagers fantômes à l'intérieur de groupes, c'est-à-dire, des groups avec des usagers qui n'existent plus.

Pour gérer ce scénario, les administrateurs ont typiquement recours à des scripts ou des outils qui mettront les groupes à jour, ou n'importe quelle entité dépendante de l'entrée suprimée. Ceci n'est pas difficile, seulement quelques recherches et une mise à jour sont nécessaires.

La couche de superposition refint permet de réaliser une partie de ceci automatiquement. Poursuivons avec notre exemple de groupe. Cette superposition peut être configurée pour garder l'intégrité de l'attribut member, qui liste le membre du groupe. Dès qu'une entrée est supprimée de l'annuaire, une recherche est lancée sur tous les attributs member pointant vers cette entrée supprimée. Les entrées qui correspondent se verront l'attribut member retiré, maintenant ainsi l'intégrité.

Ceci démontre que la couche de superposition refint, plutôt que de refuser une opération qui briserait l'intégrité, va plutôt retirer ou renommer les attributs pour composer avec la suppression.

L'exemple suivant supprime un usager et montre comment le groupe est mis à jour automatiquement.

Si nous supprimons le dernier usager du groupe, (queen), nous verrons alors la configuration refint_nothing s'activer :

    $ ldapdelete -x -D 'uid=Account Admin,ou=System Accounts,dc=example,dc=com' -W uid=queen,ou=People,dc=example,dc=com
Enter LDAP Password: secretpassword
$ ldapsearch -x -LLL cn=mkt member
dn: cn=mkt,ou=Group,dc=example,dc=com
member: uid=LDAP Admin,ou=System Accounts,dc=example,dc=com
   

Au lieu de laisser le groupe sans membres, ce qui est proscrit par la classe d'objet groupOfNames, le recouvrement est ajouté au DN refint_nothing en tant que son seul membre.

Le rôle du producteur est assigné par la couche de superposition syncprov. La configuration du paquetage openldap-mandriva-dit et ses scripts de démarrage ont déjà tous les détails nécessaires, mais nous les répéterons par souci d'intégrité.

Voici ce dont nous aurons besoin dans slapd.conf :

(...)
modulepath      /usr/lib/openldap
moduleload      back_monitor.la
moduleload      syncprov.la
(...)

database        bdb
suffix          "dc=example,dc=com"
(...)
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
			

Selon le fonctionnement de suncrepl (consultez OpenLDAP Admin Guide et le RFC 4533 pour plus de détails), les opérations d'écriture sont mieux suivies avec l'utilisation d'un log de session. Ce sont des valeurs suggérées qui varient selon le nombre d'écritures que l'annuaire reçoit dans une période donnée.

Il nous reste un changement à faire : configurer les limites.

syncrepl fonctionne via une opération de recherche hiérarchique. Le consommateur lancera cette recherche sur le producteur et la réponse est la données en train d'être répliquée. Donc, si le consommateur commence vide, la réponse contiendra toutes le données à répliquer. Une fois synchronisé, la réponse ne contiendra que les entrées changées, ajoutées ou supprimées. Ce qui signifie ::

Afin d'aborder tous ces enjeux, la solution habituelle est de créer un compte spécifique à la réplication et d'ajuster les ACL et les limites pour ce compte. openldap-mandriva-dit accomplit ceci à travers le groupe LDAP Replicators et ses membres :

    limits group="cn=LDAP Replicators,ou=System Groups,dc=example,dc=com"
        limit size=unlimited
        limit time=unlimited

    access to dn.subtree="dc=example,dc=com"
    by group.exact="cn=LDAP Admins,ou=System Groups,dc=example,dc=com" write
    by group.exact="cn=LDAP Replicators,ou=System Groups,dc=example,dc=com" read
    by * break
   

Cette configuration vérifie que les membres du groupe LDAP Replicators peuvent lire toutes les entrées et attributs, et n'a pas de limite de taille ou de temps appliquée, ce qui correspond exactement à ce dont nous avons besoin pour le support de la réplication avec syncrepl. Notez que les ACL peuvent être ajustés si vous préférez limiter les accès de lecture aux données qui ne seront jamais répliquées à votre avis.

Après avoir fait ces modifications et redémarré le service, ce serveur est prêt a recevoir des consommateurs avec des données répliquées. Aucun autre changement n'est nécessaire (mise à part de l'optimisation) pour ajouter un autre consommateur.

La configuration au niveau consommateur est plus complexe et ressemble au processus de slurpd. Il y a deux types de réplications :

pour la réplication refresh, voici ce dont on a besoin :

syncrepl    rid=001
            provider=ldap://provider.example.com
            starttls=critical
            type=refreshOnly
            interval=00:01:00:00
            searchbase="dc=example,dc=com"
            scope=sub
            filter="(objectClass=*)"
            attrs="*,+"
            bindmethod=simple
            binddn="uid=LDAP Replicator,ou=System Accounts,ou=global,dc=example,dc=com"
            credentials="ldapreplicator"
   

Pour refreshAndPersist, la configuration est comme ceci :

syncrepl rid=001 provider=ldap://provider.example.com
    starttls=critical type=refreshAndPersist retry="60 +"
    searchbase="dc=example,dc=com" scope=sub
    filter="(objectClass=*)" attrs="*,+" bindmethod=simple
    binddn="uid=LDAP Replicator,ou=System
    Accounts,ou=global,dc=example,dc=com"
    credentials="ldapreplicator"
    
    updateref   ldap://provider.example.com
   

Les paramètres plus importants sont décris plus bas. Vous trouverez plus de détails dans la page de man de slapd.conf(5).

	Avertissement
	N'utilisez pas un hash de mot de passe (hashed password) pour le paramètre credentials, ce doit être du texte clair ! Souvenez-vous que dans ce cas, le consommateur est u client LDAP comme tous les autres. Lorsque vous vous authentifier avec votre serveur, tapez-vous votre mot de passe en texte clair ou la version hash ?

Pour tester la réplication, la façon la plus simple est de vider la base de données et de la redémarrer en étant vide. Les fichiers journaux de producteur producer logs (au loglevel 256) devraient afficher les connexions des consommateurs (nous avons supprimé quelques colonnes pour que ce soit plus clair) :

conn=1 fd=27 ACCEPT from IP=10.0.4.29:4479 (IP=0.0.0.0:389) 
conn=1 op=0 BIND dn="uid=LDAP Replicator,ou=System Accounts,dc=example,dc=com" method=128 
conn=1 op=0 BIND dn="uid=LDAP Replicator,ou=System Accounts,dc=example,dc=com" mech=SIMPLE ssf=0 
conn=1 op=0 RESULT tag=97 err=0 text= 
conn=1 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" 
conn=1 op=1 SRCH attr=* + 
conn=1 op=2 UNBIND 
conn=1 fd=27 closed 
   

Après un court instant, et tout dépendant de la taille de la base de données, le consommateur devrait être synchro avec le producteur.

Pour surveiller l'efficacité de la cache BDB, vous devez lancer la commande db_stat. Voici un exemple :

    # db_stat -m -h /var/lib/ldap/ | head -n 6
    40MB 1KB 604B   Total cache size.
    1       Number of caches.
    40MB 8KB        Pool individual cache size.
    0       Requested pages mapped into the process' address space.
    975     Requested pages found in the cache (98%).
    19      Requested pages not found in the cache.
    (...)
   

L'écran précédent montre la taille actuelle de la cache (40MB) et le pourcentage de réponse pertinente (hit percentage) de la base de données principale (98%). Une façon rapide de faire un survol des réponses de la base de données est d'utiliser la commande db_stat -m -h /var/lib/ldap | grep %.

Si le pourcentage de réponse pertinente est peu élevé (disons sous les 90 %), vous devriez accroître la cache. Souvenez-vous d'exécuter db_recover après pendant que le service est arrêté afin que ces changements deviennent effectifs.

Notez que vous devriez toujours prendre en considération le nombre de requêtes qu'un fichier de base de données a reçu. S'il y a peu de requêtes, le pourcentage de réponse pertinente pourrait être déformé et il n'est pas nécessaire de faire quoi que ce soit.

OpenLDAP utilise le support pour les transactions qu'utilise BDB. Cela veut dire qu'en temps voulu, le répertoire de base de données se remplira de fichiers journaux :

    # l /var/lib/ldap/log.*
    -rw-------  1 ldap ldap 170K Ago 18 17:40 /var/lib/ldap/log.0000000001
   

Par défaut, chaque fichier journal grossira jusqu'à une taille de 10 Mo et sera pivoté, ce qui signifie qu'un nouveau fichier commencera. Cahque fichier journal contient toutes les opérations d'écriture faites sur la base de données. Il serait donc possible de la reconstruire depuis zéro si tous les fichiers journaux sont disponibles. C'est ce qu'on appelle une « restauration extraordinaire » (catastrophic recovery).

Un fichier journal peut contenir des transactions ouvertes, c'est-à-dire des changements qui n'ont pas encore été envoyés à la base de données. La commande db_archive peut être utilisée pour lister les fichiers journaux qui ne sont plus en utilisation et qui pourraient être supprimés (ou sauvegardés ailleurs si vous voulez pouvoir exécuter une restauration extraordinaire dans le futur) :

    # db_archive -h /var/lib/ldap
    #
   

Dans cet exemple, aucun fichier journal n'a été imprimé par db_archive, ce qui signifie que tous les fichiers journaux sont en fonction. Voici une sortie différente possible :

# db_archive -h /var/lib/ldap
log.0000000001
log.0000000002
log.0000000003
#
   

Ceci signifie que les fichiers journau affichés ne sont plus en usage et peuvent être supprimés ou sauvegardés. L'outil peut supprimer ces fichiers journaux automatiquement à travers l'option -d.

En option, les fichiers journaux peuvent être supprimés automatiquement par la bibliothèque elle-même, lorsqu'ils sont pivotés. Pour que cela arrive, vous devez spécifier au drapeau DB_LOG_AUTOREMOVE dans le fichier DB_CONFIG :

    (... other DB_CONFIG options ...)
    set_flags DB_LOG_AUTOREMOVE
   

Les index sont importants pour toutes les bases de données, incluant les serveurs de répertoires. Lorsque OpenLDAP reçoit une requête de recherche sur des attributs dont l'index est incorrect, une mise en garde est inscrite dans le fichier journal. Particulièrement dans les prochains jours de mise en fonction, il est important de regarder les fichiers journaux périodiquement et de repérer ces mises en garde, de réindexer les attributs ou de changer les paramètres de recherche :

    # grep index_param /var/log/ldap/ldap.log
    Aug 24 10:04:43 cs4 slapd[27399]: <= bdb_equality_candidates: (ou) index_param failed (18) 
    Aug 24 10:04:45 cs4 slapd[27399]: <= bdb_equality_candidates: (ou) index_param failed (18)
    (...)
    Jul 21 15:43:59 cs4 slapd[29666]: <= bdb_equality_candidates: (sambaSIDList) index_param failed (18) 
    Jul 21 15:43:59 cs4 slapd[29666]: <= bdb_equality_candidates: (sambaSIDList) index_param failed (18) 
    (...)
   

Ceci montre qu'au moins deux recherches étaient faites sur des attributs non indexés. Dans les deux cas, l'index manquant était de type égalité equality type (donc, bdb_equality_candidates). Pour remédier à la situation, ces index doivent être ajourés et la base de données doit être réindexée.

Le symptôme classique est d'excuter getent passwd john et que l'utilisateur john n'existe pas, mais il est dans LDAP. Plusieurs sont impliqués dans cette vérification pourtant simple, ce qui veut dire que plusieurs éléments peuvent en être la cause.

Le checmin à travers lequel cette commande passe est plus ou moins celui-ci : glibc, nss, nss_files, nss_ldap, ldap, user entry (classe d'objet posixAccount). Jetons-y un œil :

OpenLDAP vous donne un niveau exhaustif de détails en ce qui concerne les fichiers journaux du serveur. Celui qui est le plus utilisé, et celui que nous recommandons pour commencer à déboguer, est le 256. Donc, lorsque vous déboguez, assurez-vous de commencer avec loglevel 256 dans slapd.conf. D'autres niveaux sont disponibles, lisez la page de man de slapd.conf(5) pour une liste complète.

Pour qu'un serveur d'identité fonctionne correctement, plusieurs services sont nécessaires. Voici une liste non exhaustive :