25.3. Configuration de serveur avec slapd.conf

Votre système comporte un fichier de configuration complet pour le serveur LDAP dans /etc/openldap/slapd.conf. Les entrées individuelles sont succinctement décrites ici et les ajustements nécessaires sont expliqués. Les entrées introduites par le signe dièse (#) sont inactives. Supprimez ce caractère de commentaire pour les activer.

25.3.1. Directives globales dans slapd.conf

Exemple 25.2. slapd.conf : directive include pour les modèles

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/rfc2307bis.schema
include         /etc/openldap/schema/yast.schema

Cette première directive dans slapd.conf, illustrée dans l'Exemple 25.2, « slapd.conf : directive include pour les modèles », spécifie le modèle selon lequel l'annuaire LDAP est organisé. L'entée core.schema est obligatoire. Les modèles supplémentaires requis sont ajoutés à cette directive. Des informations sont disponibles dans la documentation OpenLDAP incluse.

Exemple 25.3. slapd.conf : pidfile et argsfile

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

Ces deux fichiers contiennent le PID (ID de processus) et certains des arguments avec lesquels le processus slapd est démarré. Aucune modification n'est requise ici.

Exemple 25.4. slapd.conf : contrôle d'accès

# Sample Access Control
#       Allow read access of root DSE
# Allow self write access
#       Allow authenticated users read access
#       Allow anonymous users to authenticate
# access to dn="" by * read
  access to * by self write
              by users read
              by anonymous auth
#
# if no access controls are present, the default is:
#       Allow read by all
#
# rootdn can always write!

L'Exemple 25.4, « slapd.conf : contrôle d'accès » est l'extrait de slapd.conf qui réglemente les autorisations d'accès pour l'annuaire LDAP sur le serveur. Les paramètres définis ici dans la section globale de slapd.conf sont valides tant qu'aucune règle d'accès personnalisée n'est définie dans la section spécifique aux bases de données. Ces dernières remplacent en effet les déclarations générales. Comme indiqué ici, tous les utilisateurs ont accès à l'annuaire en lecture, mais seul l'administrateur (rootdn) dispose de droits d'écriture. La réglementation du contrôle d'accès dans LDAP est un processus hautement complexe. Les astuces suivantes peuvent être utiles :

  • Chaque règle d'accès possède la structure suivante :

    access to <what> by <who> <access>
  • what désigne l'emplacement pour l'objet ou l'attribut auquel l'accès est donné. Des branches individuelles de l'annuaire peuvent être protégées explicitement à l'aide de règles séparées. Il est également possible de traiter des portions de l'arborescence d'annuaire avec une règle en utilisant des expressions régulières. slapd évalue toutes les règles dans l'ordre où elles sont répertoriées dans le fichier de configuration. Les règles plus générales doivent figurer après les règles plus spécifiques : la première règle slapd est considérée comme valide et toutes les entrées suivantes sont ignorées.

  • who détermine qui doit avoir accès aux zones définies par what. Des expressions régulières peuvent être employées. slapd annule à nouveau l'évaluation de who après la première correspondance. Les règles plus spécifiques doivent donc être spécifiées avant les règles plus générales. Les entrées illustrées dans Tableau 25.2, « Groupes d'utilisateurs et autorisations d'accès » sont possibles.

    Tableau 25.2. Groupes d'utilisateurs et autorisations d'accès

    Étiquette

    Portée

    *

    Tous les utilisateurs sans exception.

    anonymous

    Utilisateurs non authentifiés (« anonymes »).

    users

    Utilisateurs authentifiés.

    self

    Utilisateurs connectés à l'objet cible.

    dn.regex=<regex>

    Tous les utilisateurs correspondant à l'expression régulière.

  • access spécifie le type d'accès. Utilisez les options répertoriées dans Tableau 25.3, « Types d'accès ».

    Tableau 25.3. Types d'accès

    Étiquette

    Portée de l'accès

    none

    Aucun accès.

    auth

    Pour contacter le serveur.

    compare

    Accès aux objets pour comparaison.

    search

    Pour l'emploi de filtres de recherche.

    read

    Accès en lecture.

    write

    Accès en écriture.

    slapd compare les droits d'accès requis par le client à ceux accordés dans slapd.conf. Le client se voit accorder l'accès si les autorisations sont supérieures ou égales à celles demandées. Si le client demande des droits supérieurs à ceux qui sont déclarés dans les règles, l'accès lui est refusé.

L'Exemple 25.5, « slapd.conf : exemple de contrôle d'accès » illustre un exemple de contrôle d'accès simplifié pouvant être développé arbitrairement à l'aide d'expressions régulières.

Exemple 25.5. slapd.conf : exemple de contrôle d'accès

access to  dn.regex="ou=([^,]+),dc=suse,dc=de" 
by dn.regex="cn=administrator,ou=$1,dc=suse,dc=de" write  
by user read 
by * none

Cette règle déclare que seul l'administrateur correspondant possède des droits d'accès à une entrée ou individuelle. Les utilisateurs authentifiés disposent d'un accès en lecture, tandis que tous les autres n'ont aucun accès.

[Tip]définition de règles d'accès

En l'absence de règle access to ou de directive by correspondante, l'accès est refusé. Seuls les droits d'accès explicitement déclarés sont accordés. Si aucune règle n'est déclarée, le principe par défaut consiste à accorder des droits d'accès en écriture à l'administrateur et un accès en lecture à tous les autres utilisateurs.

Vous trouverez des informations détaillées et un exemple de configuration de droits d'accès LDAP dans la documentation en ligne du paquetage openldap2 installé.

Hormis le fichier central de configuration du serveur (slapd.conf), les autorisations d'accès peuvent également être administrées par le biais des informations de contrôle d'accès (ACI). ACI permet le stockage d'informations d'accès pour des objets individuels au sein de l'arborescence LDAP. Ce type de contrôle d'accès reste peu fréquent et est considéré comme expérimental par les développeurs. Reportez-vous au site http://www.openldap.org/faq/data/cache/758.html pour plus d'informations.

25.3.2. Directives spécifiques aux bases de données dans slapd.conf

Exemple 25.6. slapd.conf : directives spécifiques aux bases de données

database bdb 
checkpoint      1024    5
cachesize       10000
suffix "dc=suse,dc=de" 
rootdn "cn=admin,dc=suse,dc=de" 
# Cleartext passwords, especially for the rootdn, should 
# be avoided.  See slappasswd(8) and slapd.conf(5) for details. 
# Use of strong authentication encouraged.
rootpw secret 
# The database directory MUST exist prior to running slapd AND 
# should only be accessible by the slapd/tools. Mode 700 recommended. 
directory /var/lib/ldap 
# Indices to maintain 
index   objectClass     eq

Le type de base de données, Berkeley dans ce cas, est déterminé dans les premières lignes de cette section (reportez-vous à l'Exemple 25.6, « slapd.conf : directives spécifiques aux bases de données »). checkpoint détermine la quantité de données (en ko) conservée dans le journal des transactions avant d'être transférée dans la base de données et le temps (en minutes) séparant deux actions d'écriture. cachesize définit le nombre d'objets conservés dans le cache de la base de données. suffix détermine la portion de l'arborescence LDAP dont ce serveur doit être responsable. rootdn détermine ensuite qui bénéficie de droits d'administrateur sur ce serveur. L'utilisateur déclaré ici n'a pas besoin d'avoir une entrée LDAP ou d'exister en tant qu'utilisateur normal. Le mot de passe d'administrateur est défini avec rootpw. Au lieu d'utiliser secret ici, il est possible de saisir le hachage du mot de passe d'administrateur créé par slappasswd. La directive directory indique le répertoire (dans le système de fichiers) dans lequel les annuaires de bases de données sont stockés sur le serveur. La dernière directive, index objectClass eq, entraîne la maintenance d'un index de toutes les classes d'objet. Les attributs les plus fréquemment recherchés par les utilisateurs peuvent être ajoutés ici d'après l'expérience. Les règles Access personnalisées définies ici pour la base de données sont utilisées en lieu et place des règles Access générales.

25.3.3. Démarrage et arrêt des serveurs

Quand le serveur LDAP est entièrement configuré et que toutes les entrées souhaitées ont été effectuées conformément au modèle décrit à la Section 25.4, « Gestion de données dans l'annuaire LDAP », démarrez le serveur LDAP en tant que root en saisissant rcldap start. Pour arrêter manuellement le serveur, saisissez la commande rcldap stop. Pour interroger l'état du serveur LDAP en cours d'exécution, saisissez rcldap status.

L'éditeur de niveaux d'exécution de YaST, décrit à la Section 8.2.3, « Configuration des services système (niveau d'exécution) avec YaST », peut être utilisé pour configurer le démarrage et l'arrêt automatique du serveur à l'amorçage et à l'arrêt du système. Il est également possible de créer des liens correspondants aux scripts de démarrage et d'arrêt avec la commande insserv depuis une invite de commande, conformément à ce qui est décrit à la Section 8.2.2, « Scripts d'initialisation ».