Documentation<Précédent | Table des matières | Suivant>
1.7. Contrôle d'accès
La gestion du type d'accès (lecture, écriture, etc.) que les utilisateurs doivent être accordés aux ressources est connue sous le nom de
contrôle d'accès. Les directives de configuration impliquées sont appelées listes de contrôle d'accès ou ACL.
Lorsque nous avons installé le package slapd, diverses ACL ont été configurées automatiquement. Nous examinerons quelques conséquences importantes de ces défauts et, ce faisant, nous aurons une idée du fonctionnement des ACL et de leur configuration.
Pour obtenir l'ACL effective pour une requête LDAP, nous devons examiner les entrées ACL de la base de données interrogée ainsi que celles de l'instance de base de données frontale spéciale. Les listes de contrôle d'accès appartenant à ces dernières agissent par défaut au cas où celles des premières ne correspondent pas. La base de données frontend est la deuxième à être consultée et l'ACL à appliquer est la première à correspondre (« first match wins ») parmi ces 2 sources d'ACL. Les commandes suivantes donneront respectivement les ACL de la base de données mdb ("dc=example,dc=com") et celles de la base de données frontend :
sudo ldapsearch -Q -LLL -Y EXTERNE -H ldapi:/// -b \ cn=config '(olcDatabase={1}mdb)' olcAccess
dn : olcDatabase={1}mdb,cn=config
olcAccess : {0}to attrs=userPassword par auto écriture par authentification anonyme par * aucun olcAccess : {1}to attrs=shadowLastChange par auto écriture par * lecture
olcAccess : {2}à * par * lire
Le rootDN a toujours les droits complets sur sa base de données et n'a pas besoin d'être inclus dans une ACL.
sudo ldapsearch -Q -LLL -Y EXTERNE -H ldapi:/// -b \ cn=config '(olcDatabase={-1}frontend)' olcAccess
dn : olcDatabase={-1}frontend,cn=config
olcAccess : {0}à * par dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth gérer par * pause
olcAccess : {1}à dn.exact="" par * lire
olcAccess : {2}à dn.base="cn=Subschema" par * lire
Les deux premières ACL sont cruciales :
olcAccess : {0}to attrs=userPassword par auto écriture par authentification anonyme par * aucun olcAccess : {1}to attrs=shadowLastChange par auto écriture par * lecture
Cela peut être représenté différemment pour une digestion plus facile :
à attrs=userPassword
par auto-écriture
par authentification anonyme par * aucun
à attrs=shadowLastChange par auto-écriture
par * lire
Ces listes de contrôle d'accès appliquent les éléments suivants :
• Un accès « authentifié » anonyme est fourni au mot de passe de l'utilisateur attribut afin que les utilisateurs puissent s'authentifier, ou lier. Peut-être contre-intuitivement, « par authentification anonyme » est nécessaire même lorsque l'accès anonyme au DIT est indésirable, sinon ce serait un problème de poule et d'œuf : avant l'authentification, tous les utilisateurs sont anonymes.
• Le par auto-écriture ACL accorde un accès en écriture au mot de passe de l'utilisateur attribuer aux utilisateurs qui se sont authentifiés en tant que dn où habite l'attribut. En d'autres termes, les utilisateurs peuvent mettre à jour le mot de passe de l'utilisateur attribut de leurs propres entrées.
• Le mot de passe de l'utilisateur L'attribut est autrement inaccessible par tous les autres utilisateurs, à l'exception du rootDN, qui a toujours accès et n'a pas besoin d'être mentionné explicitement.
• Pour que les utilisateurs puissent changer leur propre mot de passe, en utilisant passwd ou d'autres utilitaires, le propre de l'utilisateur shadowDernier changement l'attribut doit être accessible en écriture. Tous les autres utilisateurs du répertoire peuvent lire le contenu de cet attribut.
Ce DIT peut être recherché de manière anonyme en raison de 'to * by * read' dans cette ACL, qui accorde un accès en lecture à tout le reste, par n'importe qui (y compris anonyme):
à *
par * lire
Si cela n'est pas souhaité, vous devez modifier les listes de contrôle d'accès. Pour forcer l'authentification lors d'une demande de liaison, vous pouvez également (ou en combinaison avec l'ACL modifiée) utiliser la directive 'olcRequire: authc'.
Comme mentionné précédemment, il n'y a pas de compte administratif ("rootDN") créé pour la base de données slapd-config. Il existe cependant une identité SASL à laquelle un accès complet est accordé. Il représente le superutilisateur de l'hôte local (root/sudo). C'est ici:
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
La commande suivante affichera les ACL de la base de données slapd-config :
sudo ldapsearch -Q -LLL -Y EXTERNE -H ldapi:/// -b \ cn=config '(olcDatabase={0}config)' olcAccess
dn : olcDatabase={0}config,cn=config
olcAccess : {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred, cn=external,cn=auth manage by * break
Puisqu'il s'agit d'une identité SASL, nous devons utiliser une SASL mécanisme lors de l'appel de l'utilitaire LDAP en question et nous l'avons vu à maintes reprises dans ce guide. C'est le mécanisme EXTERNE. Voir la commande précédente pour un exemple. Noter que:
1. Vous devez utiliser sudo pour devenir l'identité racine afin que l'ACL corresponde.
2. Le mécanisme EXTERNE fonctionne via IPC (Sockets de domaine UNIX). Cela signifie que vous devez utiliser le ldapi
Format d'URI.
Voici un moyen succinct d'obtenir toutes les listes de contrôle d'accès :
sudo ldapsearch -Q -LLL -Y EXTERNE -H ldapi:/// -b \ cn=config '(olcAccess=*)' olcAccess olcSuffix
Il y a beaucoup à dire sur le sujet du contrôle d'accès. Voir la page de manuel de slapd.access4.