Servidor LDAP 389DS

Servidor LDAP 389DS¶

Configuración previa¶

Los pasos a seguir para configurar un servidor 389DS que contenga la información necesaria para autenticar/identificar usuarios (y los pasos a seguir para configurar un cliente LDAP para que esos usuarios accedan a ella) se detallan a continuación.

Deberás utilizar dos máquinas virtuales Fedora: una de ellas hará de servidor LDAP y la otra hará de cliente. Asegúrate que ambas tengan, además de una tarjeta en modo NAT para poder conectarse a Internet, una tarjeta en modo red interna con una IP fija (en este documento supondremos que tienen la 192.168.0.1 y 192.168.0.2, respectivamente) y de que la máquina que haga de cliente tenga instalado un entorno gráfico con navegador y gestor de ficheros (bastará hacer sudo dnf install gdm firefox nautilus para ello).

Servidor¶

A. Antes de instalar nada, a la máquina que hará de servidor LDAP dale un nombre que tenga una estructura similar a un nombre DNS (por ejemplo, en este documento usaremos el de miservidor.midominio.local). De hecho, la infrastructura básica de una red con servidor LDAP integrado se debería completar con un servidor DNS más pronto que tarde (para, entre otras cosas, no tener que configurar el archivo /etc/hosts de los clientes individualmente -como tendremos que hacer más adelante-), pero para no complicar más las cosas, realiza estos tres simples pasos y ya está:

1. -Ejecuta el comando sudo hostnamectl set-hostname miservidor.midominio.local. Esto hará que el fichero /etc/hostname contenga el nuevo nombre “tipo DNS” de nuestro servidor (lo puedes comprobar también con el comando hostnamectl status).

2. Modifica manualmente el archivo /etc/hosts para que las IP 127.0.0.1 (v4) y ::1 (v6) allá indicadas estén asociadas a “miservidor.midominio.local” en vez de a “localhost”.

3. Una vez hecho estos dos pasos, reinicia la máquina.

Instalación¶

Instala el software correspondiente a un servidor LDAP básico:

sudo dnf install 389-ds-base

Configuración inicial¶

Configura el servidor LDAP propiamente dicho para poderlo empezar a usar. Para ello primero crea un fichero INF (llamémoslo "fichero.inf"), el cual tendrá un contenido ya predeterminado, mediante el comando dscreate create-template /ruta/fichero.inf . Este fichero INF representa un "molde" que podremos editar a conveniencia con cualquier editor de texto para asignar los valores deseados a las distintas directivas allí presentes. Estas directivas están perfectamente documentadas dentro del propio fichero y son bastante obvias; de todas maneras, como todas ellas ya tienen un valor por defecto asignado, nosotros tan solo necesitaremos editar unas pocas. En concreto, deberemos tener las siguientes directivas escritas como sigue:

• Directiva instance_name=miservidor: Para indicar que la instancia del servidor 389 a crear se llamará "miservidor" (aunque podría tener cualquier otro nombre). En un mismo ordenador podemos tener diferentes instancias del servidor 389DS, cada una independiente de la otra, gestionando cada una su/s propio/s directorio/s estancos y administrándose de forma individual. Cada instancia tendrá que definirse en un fichero INF diferente
• Directiva root_dn = cn=admin : Indica que el "common name" del usuario administrador del directorio manejado por la instancia en cuestión será "cn=admin".Por defecto este usuario es el único que puede hacer tanto modificaciones como consultas en los directorios de servidores 389DS.
• Directiva root_password = 12345678 : Indica que la contraseña del usuario administrador anterior será "12345678". Si no se quisiera escribir la contraseña en texto plano directamente en el fichero INF, existe la posibilidad de generar previamente un hash adecuado mediante el comando pwdhash contraseña. Mínimo 8 caracteres y entonces asignar el valor mostrado por pantalla tal cual a esta directiva
• Directiva create_suffix_entry = true : Indica que se desea crear una entrada raíz en el directorio
• Directiva suffix = dc=midominio,dc=local : Indica que el nombre de la entrada raíz del directorio a crear será "dc=midominio,dc=local"

A continuación utiliza el fichero INF generado en el paso anterior como entrada en el siguiente comando : sudo dscreate from-file /ruta/fichero.inf

Este comando establece realmente la configuración de la instancia "miservidor" en un formato que el servidor LDAP entenderá (concretamente, genera el archivo de configuración /etc/dirsrv/slapd-miservidor/dse.ldif, el cual contiene todas las directivas indicadas en el fichero INF anterior -con alguna variación en su nombre- además de muchas otras más; todas las directivas presentes en este fichero dse.ldif tienen la particularidad de estar escritas en un formato de texto llamado LDIF, el cual estudiaremos más adelante pero básicamente lo que hay que saber ahora es que esto significa que este fichero puede ser modificado igualmente mediante cualquier editor de texto estándar).

sudo dsconf -D "cn=admin" -W miservidor backend create –suffix dc=otrodominio,dc=local --be-name nombreBackend

Abrir puertos en el Firewall¶

:::bash
systemctl status firewalld
systemctl enable firewalld
systemctl start firewalld
firewall-cmd --permanent --add-port={389/tcp,636/tcp}
firewall-cmd --reload

Administración básica del directorio:¶

Ya tenemos el servidor LDAP funcionando y escuchando en el puerto 389 TCP. Ahora deberíamos generar la estructura de entradas de nuestro directorio y rellenarlas de datos.

Agregar información - Procedimiento genérico¶

La forma más básica de añadir información a un directorio cualquiera es utilizar ficheros de texto cuyo contenido está escrito en el formato LDIF (LDAP Data Interchange Format). El formato básico de una entrada es...:

:::text
# comentario 
dn: <nombre global único> 
    <atributo>: <valor> 
    <atributo>: <valor> 
    ...

...donde los atributos indicados deben pertenecer a algún objeto perteneciente a algún "schema" previamente reconocido por el servidor para que sean interpretados correctamente (por suerte, todos los objetos que utilizaremos en este documento están definidos en "schemas" que ya vienen incluidos de serie en cualquier software de tipo servidor LDAP actual).

Entre dos entradas consecutivas escritas en un archivo LDIF debe existir siempre una línea en blanco. Por otro lado, si una línea es demasiado larga, podemos repartir su contenido entre varias, siempre que las líneas de continuación comiencen con un carácter de tabulación o un espacio en blanco.

Una vez creados estos ficheros, para añadirlos al directorio (incluso con el servidor en marcha) podemos utilizar el comando ldapadd (disponible al instalar el paquete llamado “ldap-utils” -en Ubuntu-, o"openldap-clients" -en Fedora- aunque en el caso de haber instalado el paquete "389-ds-base" ya se habrá instalado automáticamente como dependencia). La mayoría de veces necesitaremos indicar los siguientes parámetros:

• -H ldap://nomDnsServidor:nºpuerto: Indica el servidor LDAP (y, opcionalmente, el número de puerto) contra el cual se van a ejecutar. Si el servidor LDAP estuviera funcionando en la misma máquina donde se ejecuta el comando ldapadd (o cualquier otro de su familia:ldapsearch, ldapmodify, etc), normalmente este parámetro se podrá omitir. Si el servidor LDAP funciona sobre TLS (es decir, es un servidor LDAP seguro), la URL a indicar deberá ser

  -H ldaps://nomDnsServidor:nºpuerto
  

  Nota

  NOTA: Si el comando cliente (cualquiera de los que estudiaremos: ldapadd, ldapsearch, ldapmodify, etc) se ejecuta en la misma máquina donde está funcionando el servidor, en vez de conectar con éste mediante TCP (que es lo que pasa cuando se usa la url del tipo ldap://...) automáticamente utiliza sockets internos que emplean el mecanismo IPC, que es un sistema de intercomunicación entre procesos locales más óptimo para estos casos. Aunque ya hemos dicho que no sería necesario, si se quisiera especificar la url, en este caso entonces se debería escribir así: ldapi://%2fruta%2fcarpeta%2ffichero.socket (notar que el protocolo es "ldapi" y no "ldap" y que las "/" se sustituyen por "%2f").

  Nota

  En el caso de contactar con un servidor LDAPS (es decir, funcionando sobre TLS), dicho servidor puede o bien ofrecer un certificado autofirmado o bien un certificado firmado por una determinada CA (Autoridad de Certificación). En el primer caso, para que los clientes admitan ese servidor como seguro se ha establecer previamente la variable de entorno LDAPTLS_REQCERT al valor "never" (simplemente precediendo el comando en cuestión con la expresión LDAPTLS_REQCERT=never ya sería suficiente). En el segundo caso, se ha de establecer previamente la variable de entorno LDAPTLS_CACERT indicando la ruta del certificado de la CA (simplemente precediendo el comando en cuestión con la expresión LDAPTLS_CACERT=/etc/dirsrv/slapd-miservidor/ca.crt, por ejemplo, ya sería suficiente). Para que estas variables sean permanentes, se pueden indicar dentro del archivo /etc/openldap/ldap.conf

• -D cn=admin: Indica el "common name" de la cuenta de usuario (guardada en el propio servidor) con la que nos autenticaremos en el servidor LDAP para realizar la modificación del directorio; esta cuenta ha de tener privilegio para ello, así que usaremos la cuenta "admin" que creamos en la instalación del servidor.

• -W : Solicita interactivamente la contraseña de la cuenta anterior. Otra opción sería indicar la contraseña como un parámetro más, así :

  -w contraseña (notar que en este caso la "w" es minúscula).

• -f fichero.ldif : Indica el fichero cuyo contenido se desea agregar

Ejercicios Agregar Datos¶

1.- a) Crea un fichero llamado base.ldif con el contenido mostrado a continuación y seguidamente agrégalo al directorio con el comando: ldapadd -D cn=admin -W -f base.ldif . Con esto habrás generado dos entradas de tipo “unidad organizativas” que servirán para contener (a modo de “carpetas”) los usuarios y grupos que generaremos a continuación.

dn: ou=usuarios,dc=midominio,dc=local 
objectClass: organizationalUnit 
ou: usuarios

dn: ou=grupos,dc=midominio,dc=local 
objectClass: organizationalUnit 
ou: grupos

1.-b) Crea un fichero llamado grupos.ldif con el siguiente contenido y seguidamente agrégalo al directorio con un comando similar al del apartado anterior:

dn: cn=grupoldap,ou=grupos,dc=midominio,dc=local 
objectClass: posixGroup 
cn: grupoldap 
gidNumber: 10000

1.-c) Crea un fichero llamado usuarios.ldif con el siguiente contenido y seguidamente agrégalo al directorio con un comando similar al del apartado anterior:

dn: uid=usu1ldap,ou=usuarios,dc=midominio,dc=local
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: usu1ldap
sn: Lopez
givenName: Juan
cn: Juan Lopez
displayName: Juan Lopez
uidNumber: 3001
gidNumber: 10000
userPassword: XXX
gecos: Es muy tonto
loginShell: /bin/bash
homeDirectory: /home/jlopez
shadowExpire: -1
shadowFlag: 0
shadowWarning: 7
shadowMin: 8
shadowMax: 999999
shadowLastChange: 10877
mail: juan.lopez@gmail.com
postalCode: 29000

dn: uid=usu2ldap,ou=usuarios,dc=midominio,dc=local
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: usu2ldap
sn: Perez
givenName: Perico
cn: Pedro Perez
displayName: Pedro Perez
uidNumber: 3002
gidNumber: 10001
userPassword: XXX
gecos: Es un crack
loginShell: /bin/bash
homeDirectory: /home/pperez
shadowExpire: -1
shadowFlag: 0
shadowWarning: 7
shadowMin: 8
shadowMax: 999999
shadowLastChange: 10877
mail: pedrito@yahoo.es
postalCode: 29001

Buscar información - ldapsearch¶

Para comprobar si el contenido anterior se ha añadido correctamente, podemos usar el comando ldapsearch (también del paquete “ldap-utils”), el cual permite hacer una búsqueda en el directorio. La mayoría de veces necesitaremos indicar, además de los parámetros -H ldap://nomDnsServidor:nopuerto, -D cn=admin y -W/-w contraseña ya conocidos, otros como los siguientes:

• -LLL : Indica a ldapsearch que muestre la respuesta en modo "no verboso" (más fácil de leer)

• d 1 : d 1, d 2, ..... establece el nivel de debug y muestra errores detallados en el resultado del comando.

• -b "dc=midominio,dc=local" : Indica el DN "base" a partir del cual se empezará la búsqueda por las entradas inferiores del árbol. El ejemplo anterior buscaría a partir de la entrada raíz "para abajo" por todas las subentradas. Pero no es necesario que la entrada raíz sea el DN "base": si, por ejemplo, escribiéramos -b "ou=grupos,dc=midominio,dc=local" entonces solo se buscaría a partir de la organizationalUnit "grupos" "para abajo" por las subentradas que contuviera.

  Nota

  NOTA: En el servidor 389DS, l'entrada "cn=config" pot fer-se servir com a DN base per obtenir tota la configuració del propi servidor

• -s {base | one | sub } : El comportamiento descrito en el párrafo anterior de buscar recursivamente todas las entradas por debajo de una entrada "base" dada (incluyendo ésta) es el comportamiento por defecto, que equivaldría a indicar el parámetro -s sub Pero otros valores de este parámetro modifican el "scope" de la búsqueda; por ejemplo,

  • -s base solamente muestra información de la entrada marcada como "base" y nada más (es decir, no recorre ninguna rama del árbol)
  • -s one solamente muestra información de las entradas directamente colgando de la entrada "base" pero nada más (es decir, sólo muestra las entradas "hijas": ni muestra entradas "nietas" ni la propia entrada "base")

• "(atributo=valor)" "(atributo=valor)"... : Filtro que permite "quedarse", de todas las entradas recorridas, solo con las que contienen el atributo indicado con el valor indicado. Existen otros filtros más sofisticados que se pueden estudiar en el cuadro inferior. Si aparece este parámetro, ha de ir escrito después de cualquier otro parámetro de los anteriores. Si no aparece, todas las entradas recorridas serán "válidas" para mostrarse.

  Nota

  • is a special value representing “any possible value”. It can be used to build a "presence" filter that requests all objects where the attribute is present and has a valid value, but we do not care what the value is. For instance, by default, ldapsearch provides the filter "(objectClass=*)"; because all objects must have an objectClass, this filter is the equivalent to saying “all valid objects”.

• atributo atributo ... : De la información encontrada en las entradas recorridas (y ya filtradas, si fuera el caso), se muestra solo aquellos atributos indicados. Si aparece este parámetro, ha de ir escrito después del filtro (si hubiera). Si no aparece -o se escribe "*"-, se mostrarán todos los atributos pertenecientes a las entradas recorridas (y ya filtradas si fuera el caso); en el caso de escribir "+" se mostrarán los metaatributos de la entradas recorridas (como la fecha de creación de la entrada, el usuario que la creó, etc).

  Nota

  To show what basedns are available, you can query the special ‘’ or blank rootDSE (Directory Server Entry) using "namingContexts" as the attribute to look up, like this:

  ldapsearch -D cn=admin -W -LLL -b "" -s base namingContexts
  

2.- Ejecuta el comando ldapsearch -D cn=admin -W -LLL -b "dc=midominio,dc=local" uid=usu1ldap sn givenName Con este comando de ejemplo estaremos buscando un usuario con uid=usu1ldap y pediremos que nos muestre solo el contenido de los atributos sn y givenName. Comprueba que efectivamente sea así:

*A filter can request objects whose attribute values are greater/less than a value by "(uid>=test0005)" or "(uid<=test0005)".If used with letters, it compares alphabetically.

A filter can request a partial match of an attribute value on the object by using the ‘’ operator (multiple times if necessary): "(uid=005)" or "(uid=*st000)". Note you should always have at least 3 characters in your substring filter, else indexes may not operate efficently.

*Filters can be nested with AND (&) or OR (|) conditions. Condition applies to all filters that follow within the same level of brackets, that is: (condition (attribute=value)(attribute=value)).

• AND requires that for an object to match, all filter elements must match; this is the “intersection” operation and is written like this: "(&(uid=test0006)(uid=guest0006))"

• OR filters will return the aggregate of all filters; this is the union operation so provided an object satisfies one condition of the OR, it will be part of the returned set; it's written like this:

  (|(uid=test0006)(uid=guest0007))
  

*A NOT filter acts to invert the result of the inner set. For example: "(!(uid=test0010))" Note you can’t list multiple parameters in a "not" condition: to combine NOT's you need to use this in conjunctionwith AND and OR.

    (&
    (objectClass=person)
    (objectClass=posixAccount)
    (|
    (uid=test000*)
        )
    (!(uid=test0001))
    )

Another example would be this:

(|(& (...K1...) (...K2...))(& (...K3...) (...K4...)))

which means

(K1 AND K2) OR (K3 AND K4)

Borrar y modificar información ldapdelete y ldapmodify¶

Otros comandos importantes del paquete “ldap-util” son ldapdelete y ldapmodify. Un ejemplo del primero podría ser:

ldapdelete -D cn=admin -W "uid=usu2ldap,ou=usuarios,dc=midominio,dc=local"

donde se ha indicado el DN del elemento que se desea eliminar.

El segundo tiene tres formas de modificar una entrada: cambiando el valor de un atributo , añadiendo un nuevo atributo o eliminando un atributo existente:

1. -Para cambiar, por ejemplo, el atributo uidNumber de un usuario, podríamos ejecutar el comando

   ldapmodify -D cn=admin -W -f fichero.cambios
   

   donde fichero.cambios debería tener un contenido como el siguiente (donde se especifica qué entradas se quieren modificar y de qué manera):

   dn:uid=usu2ldap,ou=usuarios,dc=midominio,dc=local
   changetype:modify
   replace:uidNumber
   uidNumber:3002
   

   Nota

   NOTA: La información anterior la podríamos haber introducido directamente desde la entrada estándar si no hubiéramos especificado el parámetro -f.

2. -Para añadir un atributo nuevo (en este caso llamado jpegPhoto) deberíamos ejecutar el mismo comando ldapmodify anterior pero ahora fichero.cambios debería tener un contenido como este:

   dn:uid=usu2ldap,ou=usuarios,dc=midominio,dc=local
   changetype: modify
   add:jpegPhoto
   jpegPhoto:file:///tmp/foto.png
   

3. -Para eliminar un atributo (en este caso llamado jpegPhoto) deberíamos ejecutar el mismo comando ldapmodify anterior pero ahora "fichero.cambios" debería tener un contenido como este:

   dn:uid=usu2ldap,ou=usuarios,dc=midominio,dc=local
   changetype: modify
   delete:jpegPhoto
   

    ldapmodify -D cn=admin -W -f fichero.cambios

    dn: cn=config
    changetype: modify
    replace: nsslapd-ldapilisten
    nsslapd-ldapilisten: on
    -
    add: nsslapd-ldapifilepath
    nsslapd-ldapifilepath: /var/run/slapd-exemple.socket

    dn: <dn to add>
    changetype: add
    objectclass: ...
    attribute1: ...
    attribute2: ...

    dn: <dn to delete>
    changetype: delete

3.-a) Modifica el atributo “gecos” del usuario Juan López para que muestre la descripción: “Ronca”. Comprueba mediante ldapsearch que el cambio lo has realizado correctamente

b) Añade el atributo “jpegPhoto” del usuario Juan López indicando la ruta (ficticia) de su foto identificativa. Comprueba mediante ldapsearch que el cambio lo has realizado correctamente

c) Elimina el atributo “jpegPhoto” anterior.Comprueba mediante ldapsearch que el cambio lo has realizado correctamente

ACIs¶

By default, the directory server denies access to everything. The administrator must allow certain types of access to certain resources for users to be able to use the directory server. The operational attribute aci is used for access control. This attribute can be applied to any entry in the directory tree, and has subtree scope: it applies to the entry that contains it and any children and descendants of that entry.

An ACI consists of 3 parts: a target, a subject, and the type of access (permission):

• The target represents the entry or resource is being protected. The target specification should be a DN (written with the syntax "ldap:///DN"), but can be stretched by specifying one or more atributes to restrict its application, or even a LDAP filter. Writing a target it's optional: by default it applies to all entries in subtree scope of the entry which ACI is defined (that's is which contains the aciattribute).

• The subject represents the entity which is granted (or denied) access to the target. The subject may be userdn="ldap:///DN" or groupdn="ldap:///DN" (where DN can be any DN of a user or a group, respectively). It also can be some of these values: userdn="ldap:///self" (to specify the user who has done the query), userdn="ldap:///anyone" (to specify anonymous binds), or userdn="ldap:///all" (to specify any authenticated user). Modifiers can be used to allow or deny access based on the client IP address or hostname, access time, or connection type (encrypted or not). You can also use attributes to specify a subject with userattr="attrname" syntax.

• The permission is any combination of the following keywords:

  • read Indicates whether directory data may be read. Indicates whether directory data may be changed or created. This permission also allows write directory data to be deleted but not the entry itself: to delete an entire entry, the user must have delete permissions.
  • search Indicates whether the directory data can be searched. This differs from the read permission in that read allows directory data to be viewed if it is returned as part of a search operation. For example, if searching for common names is allowed as well as read permission for a person's room number, then the room number can be returned as part of the common namesearch, but the room number itself cannot be used as the subject of a search. Use this combination to prevent people from searching the directory to see who sits in a particular room.
  • add Indicates whether child entries beneath the targeted entry can be created.
  • delete Indicates whether targeted entry can be deleted.
  • all Means all types of above accesses

  The permission is modified by using allow or deny If there are conflicts between what is allowed and what is denied, the deny wins. Better explained: when a user attempts any kind of access to a directory entry, Directory Server applies the precedence rule. This rule states that when two conflicting permissions exist, the permission that denies access always takes precedence over the permission that grants access. For example, if write permission is denied at the directory's root level, and that permission is applied to everyone accessing the directory, then no user can write to the directory regardless of any other permissions that may allow write access. To allow a specific user write permissions to the directory, the scope of the original deny-for-write has to be set so that it does not include that user. Then, there must be additional allow-for-write permission for the user in question.

  The aci attribute has the following syntax (version 3.0 and acl "name" values are mandatory and, as it can be seen, several targets can be specified as well as several allow(permission)(subject)... values):

  aci: (target="ldap:///DN)(target=...)(version 3.0; acl "name"; allow(per,miss,ion)(userdn="ldap:///subject"); allow...;)
  

  Nota

  NOTA: Some interesting modifiers to add in a ACI to restrict targeted entries are "targetattr" and "targetfilter" keywords, (which must be specified after these targeted entries). Another interesting keyword is "targetscope"

  For instance, in the following example, the ACI states that "bjensen" has rights to modify all attributes in her own directory entry:

      aci: (target="ldap:///uid=bjensen,dc=example,dc=com")(targetattr="*")(targetscope="subtree")(version 3.0; acl "example"; allow (write)(userdn="ldap:///self");)
  

Access control rules can be placed on any entry in the directory although administrators often place access control rules on entries with the object classes "domainComponent", "organizationalUnit", "inetOrgPerson", or "group". You can add/replace/delete an aci attribute like any other using LDIF files and ldapmodify command. For instance, this content would add the permission of anonymous searches/reads to all the directory's content:

dn:dc=midominio,dc=local
changetype: modify
add:aci
aci: (targetattr!="userPassword")(version 3.0; acl "xxx"; allow(read,search)(userdn="ldap:///anyone");)

The aci attribute is a multi-valued operational attribute that can be read and modified by directory users. Therefore, the ACI attribute itself should be protected by ACIs. Administration users are usually given full access to the aci attribute doing ldapsearch -D cn=admin -W -b entryDN -s base "(objectclass=*)" aci

Login LDAP desde cliente con SSSD¶

Introducción¶

En Linux se puede utilizar el demonio SSSD para autenticar al usuario contra servidores LDAP remotos (Combinados con servidores Kerberos o no) además de identificarlos. Mediante SSSD todo el proceso de autenticación / identificación del usuario se produce en el cliente de una forma homogénea y coherente, independientemente de la distribución Linux allí instalada.

Una gran ventaja de utilizar SSSD en vez de los módulos PAM / NSS "standalone" individualmente es que este demonio guarda una caché (en la carpeta /var/lib/sss/db) que permite el acceso "Offline" a / los sistema/s cliente/s (sin tener ninguna cuenta local diferente) en el caso de que el servidor LDAP / Kerberos remoto no esté disponible en ese momento o, en caso de que sí, disminuir su carga.

El demonio SSSD proporciona sus propios módulos PAM y NSS para conectar con servidores LDAP / Kerberos y LDAP, respectivamente, los cuales son diferentes de los módulos "standalone" pam_ldap / pam_krb5 y nss_ldap ya conocidos. Esto es porque SSSD ofrece funcionalidades extra como un framework conjunto y librerías homogéneas, un mecanismo de caché de credenciales -similar al que ofrecía el demonio ncsd, ya obsoleto-, una interfaz D-Bus, etc. Para que los programas de inicio de sesión (login, gdm, su, sudo, ssh, etc) utilicen los módulos PAM / NSS propios de SSSD deberemos realizar un conjunto de configuraciones al sistema que explicaremos a continuación.

Configuración de SSSD:¶

SSSD lee los archivos de configuración en este orden: primero lee el archivo primario /etc/sssd/sssd.conf y luego, otros archivos * .conf en /etc/sssd/conf.d (en orden alfabético). Si aparece el mismo parámetro en múltiples archivos de configuración, SSSD usa el último parámetro de lectura. Esto le permite usar el valor predeterminado /etc/sssd/sssd.conf en todos los clientes y aagregar configuraciones adicionales en otros archivos de configuración para extender la funcionalidad individualmente por cliente.

Los proveedores de autenticación e identidad se configuran como "dominios" en el archivo de configuración SSSD.

Puede configurar varios dominios para SSSD pero al menos un dominio debe estar configurado, de lo contrario, SSSD no arrancará. Un solo dominio se puede usar como:

• Un proveedor de autenticación (para solicitudes de autenticación)
• Un proveedor de identidad (para información del usuario)
• Un proveedor de control de acceso (para solicitudes de autorización). No los estudiaremos aquí.
• Una combinación de estos proveedores (si todas las operaciones correspondientes se realizan dentro de un solo servidor)

Sección [sssd]¶

En el archivo "sssd.conf" debe haber al menos una sección general [sssd] y una sección para cada dominio. Debajo de la sección [sssd] debemos tener en cuenta esta línea (más información en man sssd.conf):

domains =

Especifica una lista separada por comas de dominios definidos en el orden que desee para ser consultado Por lo tanto, si un dominio no aparece en esta lista, no se consultará aunque esté definido en el archivo "sssd.conf"

Sección [domain/xxx]¶

Las secciones correspondientes a dominios definidos deben titularse así [domain/xxx] donde "xxx" puede ser cualquier cosa. Debajo de una sección de dominio debemos tener en cuenta estas líneas (más en man sssd.conf):

• Line "auth_provider =": establece el proveedor de autenticación utilizado para el dominio. Los valores posibles son: - "ldap", "krb5", "ipa", "ad" o "proxy", entre otros. Dependiendo del proveedor elegido, habrá sea ​​necesario escribir líneas más específicas (ver man sssd-ldap, man sssd-krb5, man sssd-ipa u man sssd-ad para más detalles).
• -Line "id_provider =": establece el proveedor de identidad utilizado para el dominio. Los valores posibles son: "ldap", "archivos", "ipa", "anuncio" o "proxy". Dependiendo del proveedor elegido, habrá que escribir líneas más específicas (vea man sssd-ldap, man sssd-files, man sssd-ipa o man sssd-ad para más detalles).
• -Line "access_provider =": establece el proveedor de acceso utilizado para el dominio, que se utiliza para evaluar qué usuarios tienen acceso al sistema. Incluso si un usuario se autentica con éxito, si no Si cumple con los criterios proporcionados por el proveedor de acceso, su acceso será denegado. Los valores posibles son: "ldap", "krb5", "simple", "ipa", "ad", "proxy", "denegar" (siempre niega el acceso) o "permitir" (por defecto,siempre permite el acceso). Dependiendo del proveedor elegido, habrá que escribir más.
• líneas específicas (vea man sssd-ldap, man sssd-krb5, man sssd-simple, man sssd-ipa o man sssd-ad para detalles).

[domain/nombre_dominio]
...
access_provider = simple
simple_allow_users = usuario1, usuario2
#simple_allow_groups = group1

Si el proveedor de acceso que está utilizando es el "ldap", también puede especificar un filtro de control de acceso LDAP que el usuario debe coincidir para poder acceder al sistema.

[domain/domain_name]
...
access_provider = ldap
ldap_access_filter = (memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com)
#ldap_access_order = filter, host, authorized_service

*"filter" : Se usa el filtro indicado en ldap_access_filter como criterio. Valor per defecto
*"host" : Se usa el atributo "host" en el directorio como criterio
*"authorized_service" : Se usa el valor de "authorizedService" en el directorio como criterio
*"expire" : Se usa el valor de la directiva ldap_account_expire_policy como criterio

• -Line "chpass_provider =": establece el proveedor que debe manejar las operaciones de cambio de contraseña para el dominio. Los valores posibles son: "ldap", "krb5", "ipa", "ad", "proxy" o "none" (esto explícitamente deshabilita la capacidad de cambiar las contraseñas). Si no se especifica esta línea, entonces se usa por defecto el valor especificado en la línea "id_provider". Ver man sssd-sudo para detalles

  Nota

  Nota SSSD no almacena en caché las credenciales de usuario de forma predeterminada. Entonces, al procesar solicitudes de autenticación,de manera predeterminada, SSSD siempre contacta al proveedor de identidad; si el proveedor no está disponible, la autenticación de usuario falla Para garantizar que las credenciales se almacenen localmente después de autenticar con éxito a los usuarios para que puedan mantener autenticación incluso cuando el proveedor de identidad no está disponible, debe habilitar el almacenamiento en caché de credenciales local agregando la línea cache_credentials = true debajo de la sección de dominio correspondiente. Por defecto, la credencial la memoria caché nunca caduca: si desea que sssd elimine las credenciales almacenadas en caché, account_cache_expiration = line hacer que caduquen después del número de días especificado.

  Nota

  Cuando un usuario intenta una operación de sudo, ya sabemos que SSSD contacta al proveedor de identidad / sudo definido en el dominio para obtener la información requerida sobre la configuración actual de sudo. Si la línea cache_credentials se establece en true,también almacenará esa información de sudo en una memoria caché, para que los usuarios puedan realizar operaciones de sudo incluso cuando LDAP / IPA / AD El servidor está fuera de línea.

Secciones opcionales [pam] y / o [nss]¶

Las secciones opcionales [pam] y / o [nss] también pueden aparecer en el archivo "sssd.conf". Podrían ser utilizadas para configurar algunos aspectos del comportamiento de los módulos PAM o NSS de SSSD, respectivamente. Por ejemplo, si se quiere configurar un límite de tiempo (en días) para cuánto tiempo SSSD permite la autenticación sin conexión si el proveedor de identificación no está disponible, puede usar la línea offline_credentials_expiration = debajo de la sección [pam] para especificar ese límite de tiempo. Otras líneas interesantes para especificar debajo de la sección [pam] son offline_failed_login_attempts =, offline_failed_login_delay = o reconnection_retries, entre otros.

Igualmente, debajo de la sección [nss] algunas líneas interesantes que merecen atención son filter_groups = y filter_users = (que excluye a ciertos usuarios, por defecto, solo "root") de ser extraídos del backend NSS Esto es particularmente útil para las cuentas del sistema .; esta opción también se puede establecer por dominio o incluir nombres totalmente calificados para filtrar solo usuarios del dominio en particular), entry_cache_timeout = (que especifica cuántos segundos, por defecto 5400- debe considerar sssd entradas válidas antes de preguntar al NSS backend otra vez),

"entry_cache_nowait_percentage =",
"override_homedir =",
"override_shell =",
"allowed_shells =", etc.

Ejemplo 1 (un servidor LDAP como proveedor de autenticación e identidad)¶

Un fichero "sssd.conf" podría ser algo así:

[sssd]
domains=pepito
[domain/pepito]
auth_provider=ldap
id_provider=ldap
ldap_uri=ldaps://ldapserver.example.com
ldap_search_base=dc=example,dc=com

Example 2 (a KDC server as authentication provider and a LDAP server as identity provider)¶

A suitable sssd.conf file could be like this: [sssd] domains=pepito [domain/pepito] auth_provider=krb5 krb5_server=kdc.example.com krb5_realm=EXAMPLE.COM id_provider=ldap ldap_uri= ... ldap_search_base= ...