Documentación<Anterior | Contenido | Siguiente>
1.7. Control de acceso
La gestión de qué tipo de acceso (lectura, escritura, etc.) deben tener los usuarios a los recursos se conoce como
control de acceso. Las directivas de configuración involucradas se denominan listas de control de acceso o ACL.
Cuando instalamos el paquete slapd, se configuraron automáticamente varias ACL. Veremos algunas consecuencias importantes de esos valores predeterminados y, al hacerlo, tendremos una idea de cómo funcionan las ACL y cómo están configuradas.
Para obtener la ACL efectiva para una consulta LDAP, necesitamos mirar las entradas de ACL de la base de datos que se consulta, así como las de la instancia de base de datos de interfaz especial. Las ACL pertenecientes a este último actúan como predeterminadas en caso de que las del primero no coincidan. La base de datos de la interfaz es la segunda que se consulta y la ACL que se aplica es la primera en hacer coincidir ("la primera coincidencia gana") entre estas 2 fuentes de ACL. Los siguientes comandos darán, respectivamente, las ACL de la base de datos mdb ("dc = example, dc = com") y las de la base de datos frontend:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \ cn = config '(olcDatabase = {1} mdb)' olcAccess
dn: olcDatabase = {1} mdb, cn = config
olcAccess: {0} a attrs = userPassword por autoescritura por autenticación anónima por * none olcAccess: {1} to attrs = shadowLastChange por autoescritura por * read
olcAccess: {2} a * por * lectura
El rootDN siempre tiene todos los derechos sobre su base de datos y no necesita estar incluido en ninguna ACL.
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \ cn = config '(olcDatabase = {- 1} frontend)' olcAccess
dn: olcDatabase = {- 1} interfaz, cn = config
olcAccess: {0} a * por dn.exact = gidNumber = 0 + uidNumber = 0, cn = peercred, cn = external
, cn = auth administrar por * break
olcAccess: {1} a dn.exact = "" por * lectura
olcAccess: {2} a dn.base = "cn = Subschema" por * leer
Las dos primeras ACL son cruciales:
olcAccess: {0} a attrs = userPassword por autoescritura por autenticación anónima por * none olcAccess: {1} to attrs = shadowLastChange por autoescritura por * read
Esto se puede representar de manera diferente para facilitar la digestión:
a attrs = userPassword
por autoescritura
por autenticación anónima por * none
to attrs = shadowLastChange por autoescritura
por * leer
Estas ACL hacen cumplir lo siguiente:
• Se proporciona acceso de "autenticación" anónimo al contraseña de usuario atributo para que los usuarios puedan autenticarse, o se unen. Quizás de forma contraria a la intuición, se necesita 'por autenticación anónima' incluso cuando el acceso anónimo al DIT no es deseado, de lo contrario, esto sería un problema de la gallina y el huevo: antes de la autenticación, todos los usuarios son anónimos.
• El por autoescritura ACL otorga acceso de escritura al contraseña de usuario atributo a los usuarios que se autenticaron como el dn donde vive el atributo. En otras palabras, los usuarios pueden actualizar el contraseña de usuario atributo de sus propias entradas.
• El contraseña de usuario De lo contrario, el atributo es inaccesible para todos los demás usuarios, con la excepción de rootDN, que siempre tiene acceso y no necesita ser mencionado explícitamente.
• Para que los usuarios puedan cambiar su propia contraseña, utilice passwd u otras utilidades, del usuario sombraÚltimoCambio El atributo debe poder escribirse. Todos los demás usuarios del directorio pueden leer el contenido de este atributo.
Este DIT se puede buscar de forma anónima debido a 'to * by * read' en esta ACL, que otorga acceso de lectura a todo lo demás, por cualquier persona (incluido el anónimo):
a *
por * leer
Si no lo desea, debe cambiar las ACL. Para forzar la autenticación durante una solicitud de vinculación, alternativamente (o en combinación con la ACL modificada) puede usar la directiva 'olcRequire: authc'.
Como se mencionó anteriormente, no existe una cuenta administrativa ("rootDN") creada para la base de datos slapd-config. Sin embargo, existe una identidad SASL a la que se le concede acceso completo. Representa al superusuario del localhost (root / sudo). Aquí está:
dn.exact = gidNumber = 0 + uidNumber = 0, cn = peercred, cn = externo, cn = auth
El siguiente comando mostrará las ACL de la base de datos slapd-config:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \ cn = config '(olcDatabase = {0} config)' olcAccess
dn: olcDatabase = {0} config, cn = config
olcAccess: {0} a * por dn.exact = gidNumber = 0 + uidNumber = 0, cn = peercred, cn = external, cn = auth manage by * break
Dado que esta es una identidad SASL, necesitamos usar una SASL mecanismo al invocar la utilidad LDAP en cuestión y la hemos visto muchas veces en esta guía. Es el mecanismo EXTERNO. Consulte el comando anterior para ver un ejemplo. Tenga en cuenta que:
1. Debes usar sudo para convertirse en la identidad raíz para que coincida la ACL.
2. El mecanismo EXTERNO funciona a través de IPC (Sockets de dominio UNIX). Esto significa que debe utilizar el ldapi
Formato de URI.
Una forma sucinta de obtener todas las ACL es la siguiente:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \ cn = config '(olcAccess = *)' olcAccess olcSuffix
Hay mucho que decir sobre el tema del control de acceso. Consulte la página de manual de slapd.access4.