Autenticación centralizada mediante OpenLDAP

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Centralized authentication using OpenLDAP and the translation is 53% complete.
Outdated translations are marked like this.
Other languages:
The information in this article is probably outdated. You can help the Gentoo community by verifying and updating this article.

Esta guía presenta las cuestiones básicas de LDAP y le muestra cómo configurar OpenLDAP para realizar tareas de autenticación entre un grupo de computadoras.

Advertencia
The current state does not yield a working configuration. See Talk:Centralized_authentication_using_OpenLDAP for details. Work is in progress.

Comenzar con OpenLDAP

¿Qué es LDAP?

LDAP significa Lightweight Directory Access Protocol (Protocolo Ligero de Acceso a Directorio). Está basado en X.500 el cual define la mayoría de sus funciones y carece de algunas funciones esotéricas que tiene X.500. Ahora bien, ¿Qué es X.500 y porqué existe LDAP?

X.500 es un modelo de Servicio de Directorio basado en el concepto OSI (Interconexión de sistemas Abiertos). Contiene definiciones de espacios de nombres y protocolos para consultar y actualizar el directorio. Sin embargo, se ha encontrado en muchos casos que X.500 es demasiado estricto. Mejor entrar en LDAP. Al igual que X.500, proporciona un modelo de datos y espacio de nombres para el directorio y el protocolo. No obstante, LDAP está diseñado para correr directamente sobre la pila TCP/IP. Podemos considerar a LDAP como una versión ligera de X.500.

No lo pillo. ¿Qué es un directorio?

Un directorio es una base de datos especializada diseñada para consultas frecuentes y actualizaciones no tan frecuentes. Al contrario que las bases de datos generalistas, no ofrecen soporte para transacciones o funcionalidad de vuelta atrás (roll-back). Los directorios se replican fácilmente para incrementar disponibilidad y fiabilidad. Cuando se replican los directorios, se permiten inconsistencias temporales siempre que acaben sincronizándose.

¿Cómo se estructura la información?

Toda la información dentro de un directorio está estructurada jerárquicamente. Aún más, si intenta introducir datos en un directorio, éste debe conocer la forma de almacenar estos datos en un árbol. Eche un vistazo a una compañía ficticia y a su organigrama:

CÓDIGO Estructura organizativa de GenFic, una comunidad Gentoo ficticia
dc:           org
              |
dc:          genfic           ## (Organización)
            /      \
ou:    Personas  Servidores   ## (Unidades organizativas)
       /      \     ..
uid:  ..     John             ## (Datos específicos de las UO)

Puesto que no puede alimentar la base de datos con este tipo de arte ascii, se debe definir cada nodo de este árbol. Para nombrar estos nodos, LDAP usa un sistema de definición de nombres. La mayor parte de distribuciones de LDAP (incluyendo OpenLDAP) ya contienen un buen número de esquemas predefinidos (y normalmente aprobados), como el inetOrgPerson o un esquema llamado posixAccount utilizado frecuentemente para definir usuarios que los equipos Unix o Linux pueden utilizar. Observe que existen herramientas basadas en GUI para que facilitar la gestión de LDAP. Eche un vistazo a Trabajar con OpenLDAP para una lista exhaustiva.

Se recomienda a los usuarios interesado leer la Guía de Administración de OpenLDAP.

Y bien.. ¿Para qué se utiliza?

Se puede usar LDAP para diferentes propósitos. En este documento se trata la administración centralizada de usuarios, manteniendo todas las cuentas de usuario en una única ubicación LDAP (lo que no significa que esté albergada en un único servidor, puesto que LDAP ofrece soporte a alta disponibilidad y redundancia). Sin embargo, se puede utilizar LDAP para otros fines.

  • Infraestructura de Clave Pública (PKI)
  • Calendario compartido
  • Libreta de direcciones compartida
  • Almacenamiento para DHCP, DNS, ...
  • Directivas de configuración de clases del sistema (manteniendo el seguimiento de varias configuraciones del servidor)
  • Autenticación centralizada (PosixAccount)
  • ...

Configuración del servidor OpenLDAP

Notas comunes

En esta guía utilizamos como ejemplo el dominio genfic.org. Por supuesto, deberá cambiarlo. Sin embargo, asegúrese de que el nodo superior es un dominio oficial de primer nivel (net, com, cc, be, ...).

USE flags for net-nds/openldap LDAP suite of application and development tools

argon2 Enable password hashing algorithm from app-crypt/argon2
autoca Automatic Certificate Authority overlay
berkdb Add support for sys-libs/db (Berkeley DB for MySQL)
cleartext Enable use of cleartext passwords
crypt Add support for encryption -- using mcrypt or gpg where applicable
cxx Build support for C++ (bindings, extra libraries, code generation, ...)
debug Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
experimental Enable experimental backend options
gnutls Prefer net-libs/gnutls as SSL/TLS provider (ineffective with USE=-ssl)
iodbc Add support for iODBC library
ipv6 Add support for IP version 6
kerberos Add kerberos support
kinit Enable support for kerberos init
minimal Build libraries & userspace tools only. Does not install any server code
odbc Enable ODBC and SQL backend options
overlays Enable contributed OpenLDAP overlays
pbkdf2 Enable support for pbkdf2 passwords
perl Add optional support/bindings for the Perl language
samba Add support for SAMBA (Windows File and Printer sharing)
sasl Add support for the Simple Authentication and Security Layer
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
sha2 Enable support for pw-sha2 password hashes
smbkrb5passwd Enable overlay for syncing ldap, unix and lanman passwords
ssl Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security)
static-libs Build static versions of dynamic libraries as well
syslog Enable support for syslog
systemd Enable use of systemd-specific libraries and features like socket activation or session tracking
tcpd Add support for TCP wrappers
test Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
Data provided by the Gentoo Package Database · Last update: 2024-03-29 18:45 More information about USE flags

En primer lugar haga emerge de OpenLDAP. Asegúrese que se usan los ajustes USE berkdb, crypt, gnutls, ipv6, sasl, ssl, syslog, -minimal' y tcpd.

root #emerge --ask openldap

OpenLDAP ofrece soporte para dos mecanismos de autenticación:

  1. Contraseña de usuario estándar (en términos de LDAP user significa binddn) llamada SIMPLE
  2. Redirigir las peticiones de autenticación hacia SASL (Simple Authentication and Security Layer)
  1. Standard user-password (in LDAP terms user means binddn) named SIMPLE.
  2. Proxying authentication requests to SASL (Simple Authentication and Security Layer, see RFC4422 for details).

Aunque por defecto OpenLDAP utiliza SASL, la versión inicial de este artículo utilizaba únicamente la autenticación basada en contraseña. Con el añadido OLC, el artículo comienza a describir la utilización del mecanismo SASL más sencillo llamado EXTERNAL, el cual depende de la autenticación del sistema.

OpenLDAP tiene un usuario principal llamado "rootdn" (Root Distinguished Name o Nombre Distinguido de Root) el cual está definido dentro de la aplicación. Al contrario que el usuario root clásico de Unix, al usuario rootdn se le deben asignar los permisos adecuados. El usuario rootdn solo se puede utilizar en el contexto de la configuración y también en la definición del directorio. En este caso un usuario puede autenticarse a si mismo como rootdn con la contraseña usada en la configuración y la contraseña (basada en el directorio) del árbol.

La contraseñas de usuario (independientemente si son para usuarios rootdn u otros) para propósitos de verificación se pueden almacenar como testo en claro o aplicando un hash. Se dispone de varios algoritmos hash, sin embargo no se recomienda el uso de algoritmos débiles (hasta MD5). Actualmente en criptografía se considera que SHA es suficientemente seguro.

En la orden de abajo, se crea un valor hash para una contraseña dada, el resultado de esta orden se puede utilizar en el fichero de configuración slapd.conf o bien en la definición del directorio interno de un usuario:

root #slappasswd
New password: mi-contraseña
Re-enter new password: mi-contraseña
{SSHA}EzP6I82DZRnW+ou6lyiXHGxSpSOw2XO4

Configuración heredada (configuración básica slapd.conf)

Advertencia
Do not use this anymore in 2021. It is also not the foundation to be transformed to LDIF with OpenLDAP tools. It will not be translated correctly.

Ahora edite la configuración LDAP del servidor en /etc/openldap/slapd.conf. El fichero slapd.conf que se muestra es de los fuentes originales de OpenLDAP. Abajo se muestra un fichero ejemplo de configuración que se puede utilizar para reemplazarlo de modo que las cosas comiencen a funcionar.

ARCHIVO /etc/openldap/slapd.conf
include	/etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include	/etc/openldap/schema/misc.schema
 
pidfile  /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
 
## ## ServerID utilizado en caso de replicación
serverID 0 
loglevel 0
 
## ## Sección de certificados y SSL
TLSCipherSuite normal
TLSCACertificateFile /etc/openldap/ssl/ldap.crt
TLSCertificateFile /etc/openldap/ssl/ldap.pem
TLSCertificateKeyFile /etc/openldap/ssl/ldap.key
TLSVerifyClient never
 
## ## Controles de acceso
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
  by self write
  by users read
  by anonymous read
 
## ## Definición de la base de datos
database mdb
suffix "dc=genfic,dc=org"
checkpoint 32 30
maxsize 10485760
#Nota: Es importante definir esto a un valor lo más alto posible,
#(relativo al crecimiento anticipado de los datos a lo largo del tiempo)
#ya que incrementar el tamaño más adelante puede no ser práctico cuando el sistema está bajo una alta carga de trabajo.
 
rootdn "cn=Manager,dc=genfic,dc=org"
## ## rootpwd generado anteriormente a través de la orden slappasswd
rootpw "{SSHA}EzP6I82DZRnW+ou6lyiXHGxSpSOw2XO4" 
directory "/var/lib/openldap-data"
index objectClass eq
 
## ## Sincronización (recuperación desde otro servidor LDAP)
syncrepl rid=000
  provider=ldap://ldap2.genfic.org
  type=refreshAndPersist
  retry="5 5 300 +"
  searchbase="dc=genfic,dc=org"
  attrs="*,+"
  bindmethod="simple"
  binddn="cn=ldapreader,dc=genfic,dc=org"
  credentials="ldapsyncpass"
 
index entryCSN eq
index entryUUID eq
 
mirrormode TRUE
 
overlay syncprov
syncprov-checkpoint 100 10
Nota
Don't forget, the second node must use different value of rid and proper address in provider ldapuri.

Para un análisis más detallado del fichero de configuración, le sugerimos que acceda a la guía del administrador de OpenLDAP, aunque la información mostrada con man 5 slapd.conf puede ser suficiente.

Si no arranca, lo primero que se debe hacer es comprobar el fichero de configuración. Puede hacer esto utilizando la siguiente orden:

user $slaptest -v -d 1 -f /etc/openldap/slapd.conf

Cambie el nivel de depuración (El "-d 1" de arriba) para obtener más información. Si todo va bien se mostrará config file testing succeeded. Si hay un error, slaptest mostrará el número de línea en la cual está el problema (dentro del fichero slapd.conf).

Por defecto slapd escribe los eventos de registro a la instalación local4 de syslog.

Advertencia
Observe que a partir de la versión 2.4.23, OpenLDAP, por defecto, cambió por fin sus ficheros de configuración planos (slapd.conf) a la configuración en línea OLC (OnLineConfiguration también conocida por su estructura cn=config) como su método de configuración por defecto. Una de las ventajas de usar OLC es que el backend dinámico (cn=config) no necesita reiniciar el servidor después de cambiar la configuración. Los usuarios que utilicen el método anterior pueden migrar al nuevo método de configuración mediante slaptest indicando las opciones -f y -F. Tradicionalmente OLC se almacena en un backend con formato ldif (que mantiene las ventajas de la legibilidad por parte de los humanos) en el directorio /etc/openldap/slapd.d. En Gentoo todavía no es necesario convertir la configuración, sin embargo, en el futuro se eliminará el enfoque de documentación actual en este documento.

Migración desde slapd.conf a OLC

Advertencia
The following section is totally unusable and will be improved soon. Instead follow any decent basic LDIF based setup guide tosetup the objectClass: olcGlobal setup objectClass: moduleList, back_mdb.so or back_bdb.la, depending on USE setup objectClass: olcSchemaConfig, nis.ldif and such database config for tree, incl. reader role, denying anonymous reads and so on create a base DN/ objectclass=organization, without it tools like phpldapadmin will not work at all setup organizational units to group objectClass further, sane substructure with Person, Group import relevant Gentoo groups, e.g. wheel, audio, usb, desktop users with these will be rather limited use a tool, even only temporarily, to create one or two more users

Si desea poder cambiar la configuración del servidor OpenLDAP necesita definir al menos el acceso de escritura (write) (o normalmente de gestión manage) a cn=config.

El ejemplo de abajo muestra como conceder acceso de gestión a OLC (base de datos cn=config) al administrador del sistema (usuario root) añadiendo las líneas adecuadas al final del fichero slapd.conf:

ARCHIVO /etc/openldap/slapd.confConceder derechos de gestión de la cuenta root de Linux a cn=config
database config
access to *
    by
dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
    by * none

Entonces invocamos a la utilidad slaptest con las opciones -f y -F para convertir el archivo slapd.conf en un directorio de configuración (slapd.d).

root #mkdir /etc/openldap/slapd.d
root #slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
root #chown -R ldap /etc/openldap/slapd.d

Al lanzar esta orden se transferirá y traducirá la configuración. Después de esto, deberá actualizar la configuración utilizando ficheros ldif especialmente preparados. Si no está familiarizado con el formato de estos ficheros puede editar en primero slapd.conf y después traducir slapd.conf a slapd.d/. No olvide comprobar los permisos sobre los directorios.

Para más indicaciones lea los comentarios en línea dentro de los ficheros generados.

La línea de abajo habilitará el método de configuración slapd.d/.

ARCHIVO /etc/conf.d/slapd
OPTS="-F /etc/openldap/slapd.d -h 'ldaps:// ldap://
ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"

Para terminar, cree la estructura /var/lib/openldap-data:

root #mkdir -p /var/lib/openldap-data
root #chown -R ldap:ldap /var/lib/openldap-data
root #chmod -R 0700 /var/lib/openldap-data

Configuración inicial con OLC

Se entrega una configuración inicial como un volcado de base de datos estándar LDAP disponible como slapd.ldif o config.ldif.

Advertencia
To include additional schemas, flat schema files should be converted into ldif format. Custom scheme must also be converted into ldif format. See openldap.ldif for more detailed description.
Advertencia
{{{1}}}

Se puede cargar (y únicamente cargar, al contrario que las bases de datos LDAP ordinarias) mediante la utilidad slapadd:

root #slapadd -d -1 -F /etc/openldap/slapd.d -n 0 -l /etc/openldap/config.ldif

When using a root account, be sure to correct ownership of the files created by root, as described below in migrate section.

Advertencia
La configuración por defecto no ofrece a nadie los permisos para cambiar la configuración del servidor.

Si necesita permiso para cambiar la base de datos de configuración, deberá ofrecer los permisos apropiados. El ejemplo de abajo muestra cómo se conceden estos privilegios al usuario del sistema root:

ARCHIVO config-access.ldif
# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to *  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage  by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE

Leer man 5 slapd-config para obtener más detalles.

Advertencia
This database configuration must be added between dn: olcDatabase=frontend,cn=config and dn: olcDatabase=mdb,cn=config, because each part requires the previous to exist and creates a default one if not.

Cuando se utilice OLC, no edite jamás los ficheros de configuración. Los ficheros del directorio se pueden utilizar para comprobar la consistencia de la configuración:

root #slaptest -v -d 1 -F /etc/openldap/slapd.d

Mantener el directorio

Ahora que se han completado los pasos de configuración, arrancar slapd:

root #service slapd start

La mayoría de los usuarios también querrán que el demonio OpenLDAP arranque de forma automática:

root #rc-update add slapd

Es posible utilizar el directorio del servidor para autenticar a los usuarios en apache/proftpd/qmail/samba.

El servidor de directorio se puede gestionar con herramientas como net-nds/phpldapadmin, app-admin/diradm y net-nds/jxplorer del repositorio de ebuilds de Gentoo, o app-misc/ldapexplorertool del recubrimiento (overlay) poly-c disponible a través de Layman.

Gestión del servidor con OLC

Nota
Una de las ventajas de utilizar una configuración del estilo OLC es que no se necesita reiniciar el servidor LDAP para aplicar los cambios en la configuración.

Se muestran abajo algunos ejemplos de actualizaciones a la configuración con el estilo OLC.

Por ejemplo, para cambiar la localización del directorio de configuración de OLC (necesario tras cambiar desde un fichero de configuración a un directorio de configuración):

ARCHIVO fix-configs.ldif
dn: cn=config
changetype: modify
delete: olcConfigFile
dn: cn=config
changetype: modify
replace: olcConfigDir
olcConfigDir: /etc/openldap/slapd.d

Para cambiar el nivel del registro usado por la instancia OpenLDAP:

ARCHIVO loglevel.ldif
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats stats2 sync

Para aplicar los cambios, lance la siguiente orden:

root #ldapmodify -Y EXTERNAL -H ldapi:/// -f loglevel.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
Advertencia
En un reinicio, el guión de inicio realiza una comprobación de la actualización de la configuración. La orden ldapmodify utilizada arriba bloque únicamente errores fatales. Para obtener información acerca de errores no fatales utilizando OLC:
root #slaptest -F /etc/openldap/slapd.d
58b7d4c2 olcThreads: value #0: warning, threads=64 larger than twice the default (2*16=32); YMMV.
config file testing succeeded

Registro de OpenLDAP

OpenLDAP produce numerosos eventos de registro, los cuales pueden no ser fáciles de interpretar pero necesarios para propósitos de depuración.

Debido a que, por defecto, OpenLDAP escribe la información sobre los eventos en el registro del sistema, se recomienda reconfigurar el registrador del sistema para dirigir los eventos de OpenLDAP a un fichero de registro dedicado.

Se recomienda utilizar el nivel de registro stats stats2 en OpenLDAP, lo cual resultará en información relacionada con la sesión similar a la siguiente:

root #grep conn=1 /var/log/slapd.log
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 fd=14 ACCEPT from IP=192.168.100.9:55655 (IP=192.168.1.1:389)
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=0 BIND dn="" method=128
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=0 RESULT tag=97 err=0 text=
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SRCH base="ou=People,dc=genfic,dc=org" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=1001))"
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass shadowLastChange shadowMax shadowExpire
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 ENTRY dn="uid=larry,ou=People,dc=genfic,dc=org"
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

Most common errors in server log are err=49:

ARCHIVO /var/log/slapd.log
Aug 10 12:47:27 ldap-2 slapd[32920]: conn=1004 op=0 RESULT tag=97 err=49 text=

Which means «invalid credentials» (i.e. wrong password).

And err=32:

ARCHIVO /var/log/slapd.log
Aug 10 14:15:35 ldap-2 slapd[32966]: conn=1085 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=

Which means «No such object». Usually this error appears when binddn (user) has no permissions on requested object. So either try to do something wrong, or there is a mistake in the set ACLs.

Gestión del acceso (ACLs)

Las autorizaciones y el mecanismo de control de acceso utilizados en OpenLDAP se describen en la página del manual slapd.access. Su sintaxis base es la siguiente:

CÓDIGO Sintaxis ACL en OpenLDAP
access to <qué> [ by <quién> [ <acceso> ] [ <control> ] ]+

La siguiente tabla muestra los niveles de acceso disponibles en OpenLDAP:

Nivel de acceso Privilegios Descripción
none 0 sin acceso
disclose d necesario para información en caso de error
auth dx necesario para autenticación (bind)
compare cdx necesario para comparar
search scdx necesario para aplicar los filtros de búsqueda
read rscdx necesario para leer los resultados de la búsqueda
add|delete} wrscdx necesario para modificar o renombrar
manage mwrscdx necesario para gestionar

Para obtener detalles de los ajustes exactos de los privilegios, leer las páginas del manual y la documentación oficial de OpenLDAP.

Advertencia
Recordar que el usuario rootdn puede leer y escribir cualquier cosa.

Fichero de configuración

Las ACLs se analizan en el orden en el que están dispuestas en la configuración y se aplican basándose en la especificidad (esto significa que, cuando se tiene en cuenta una regla ACL, el resto de las reglas ACL ya no se comprueban). De esta forma, las definiciones más específicas deben ir en primer lugar, antes de listar las más genéricas. Para obtener más información, consultar Access Control Evaluation.

Por ejemplo:

ARCHIVO /etc/openldap/slapd.conf
…
access to attrs=userPassword
         by dn="cn=ldapreader,dc=genfic,dc=org" read
         by self read
         by anonymous auth
         by * none
  
access to dn.base="cn=Subschema" by users read
access to dn.base="" by * read
…


Directorio de configuración

Las ACLs se analizan en el orden en el que están dispuestas en la configuración y se aplican basándose en la especificidad (esto significa que, cuando se tiene en cuenta una regla ACL, el resto de las reglas ACL ya no se comprueban). De esta forma, las definiciones más específicas deben ir en primer lugar, antes de listar las más genéricas. Este orden, cuando se utiliza OLC se gestiona mediante las directivas olcAccess.

Por ejemplo:

ARCHIVO add_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to dn.base="cn=subschema"  by users read
olcAccess: {1}to dn.base="" by * read

El siguiente ejemplo muestra cómo insertar una nueva ACL en la parte superior, haciendo que las entradas olcAccess existentes se desplacen una posición:

ARCHIVO insert_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword  by dn="cn=ldapreader,dc=genfic,dc=org" read by self read by anonymous auth by * none

Para eliminar una ACL:

ARCHIVO delete_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}

Replicación

Alta disponibilidad

Una configuración de alta disponibilidad común en OpenLDAP es utilizar la replicación de cambios a través de múltiples sistemas LDAP.

La replicación dentro de OpenLDAP se realiza en esta guía utilizando una cuenta de replicación específica (ldapreader) la cual ha leído los derechos del servidor LDAP primario y envía los cambios desde el servidor LDAP primario al secundario.

Esta configuración entonces se replica permitiendo al servidor LDAP secundario actuar igual que el primario. Gracias a la estructura interna de OpenLDAP, los cambios no se aplican de nuevo si ya están en la estructura LDAP.

Advertencia
For normal operation of OpenLDAP cluster upstream recommends to use the same version on all nodes.

Configurar la replicación

Para configurar la replicación, en primer lugar realice la configuración de un segundo servidor OpenLDAP, del mismo modo que se ha descrito arriba. Sin embargo, tenga cuidado de que, en el fichero de configuración:

  • El proveedor de la sincronización de la replicación apunta al otro sistema
  • El serverID de cada sistema OpenLDAP es diferente
Nota
El uso de una instalación desde un espejo implica que el servicio OpenLDAP se debería configurar como la instalación de un único servidor, de modo que el valor de serverID en cada uno de los nodos debe ser el mismo. Las instancias se identifican por valores rid, que deben ser únicos.
Synchronisation account

A continuación, cree la cuenta de sincronización. Crearemos un fichero LDIF (el formato utilizado como entrada de datos para los servidores LDAP) y lo añadiremos a cada servidor LDAP:

user $slappasswd -s myreaderpassword
{SSHA}XvbdAv6rdskp9HgFaFL9YhGkJH3HSkiM
ARCHIVO ldapreader.ldif
'"`UNIQ--pre-00000027-QINU`"'
user $ldapadd -x -W -D

"cn=Manager,dc=genfic,dc=org" -f

ldapreader.ldif
Password: ## introduzca la contraseña de administración
Enabling syncprov overlay

Overlay can be linked statically and dynamically. When it is built dynamically, you'll need to load module. For now in Gentoo it's usually built statically. To ensure type:

root #/usr/lib64/openldap/slapd -VVV
@(#) $OpenLDAP: slapd 2.4.44 (Feb 28 2017 10:07:46) $
	@larry:/var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44-abi_x86_64.amd64/servers/slapd
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Included static overlays:
    syncprov
Included static backends:
    config
    ldif
    bdb
    hdb
Load syncprov module (optional)

To load syncprov module, use the following ldif file:

ARCHIVO syncprov-module-load.ldif
#Load the syncprov module.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
Setting up replication for database

Next step, mandatory for everybody, is to setup replication for database (must be done on both nodes):

ARCHIVO syncprov-add-overlay.ldif
# syncrepl Provider for primary db
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpCheckpoint: 100 10
olcSpSessionlog: 100

# Add indexes for replica to the frontend db.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
-
add: olcDbIndex
olcDbIndex: entryUUID eq
Advertencia
One of poorly-documented feature of ldif-backend is that it doesn't permit file deletion. So, you can add overlay, but cannot remove it.
Final configuration

Finally, add replication's definition.

On node 1:

ARCHIVO add-replication-node1.ldif
dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: 
  rid=001 
  provider=ldap://ldap-2.genfic.org 
  binddn="cn=ldapreader,dc=genfic,dc=org" 
  bindmethod=simple 
  credentials="secret" 
  searchbase="dc=genfic,dc=org" 
  type=refreshAndPersist 
  timeout=0 
  network-timeout=0 
  retry="60 +"

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE

secret traditionally means the password string.

On node 2:

ARCHIVO add-replication-node2.ldif
add-replication-node2.ldif 
dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl:
  rid=002
  provider=ldap://ldap-1.genfic.org
  binddn="cn=ldapreader,dc=genfic,dc=org"
  bindmethod=simple
  credentials="secret"
  searchbase="dc=genfic,dc=org"
  type=refreshAndPersist
  timeout=0
  network-timeout=0
  retry="60 +"

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE

The only difference is in server's ident (rid) and provider uri.

Nota
You need to load ldap database only on one node of cluster and should not load on another. The database will be replicated automatically after adding quoted definition.

If LDAP master (mirror node with initially loaded database) is unavailable (slapd daemon not started, or 389/tcp port is blocked by a packet filter) slapd daemon on secondary node fails to start with the following error message:

root #tail -f /var/log/slapd.log
May 14 15:39:29 ldap2 slapd[1749]: olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow
May 14 15:39:29 ldap2 slapd[1749]: config error processing olcDatabase={1}mdb,cn=config: <olcMirrorMode> database is not a shadow
May 14 15:39:29 ldap2 slapd[1749]: slapd stopped.
May 14 15:39:29 ldap2 slapd[1749]: connections_destroy: nothing to destroy.

Almost certainly the database will not fit into default limits. So, you will need to increase ldapreader's limits. For example:

ARCHIVO add_replicator-limits.ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcLimits
olcLimits: dn.exact="cn=ldapreader,dc=genfic,dc=org" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
Advertencia
Database file note: replicated database size may be significantly different with origin. In my case about 300 megabytes ldif-dump is loaded into almost 900 megabytes mdb-data file and replicated in 1.5 gigabyte mdb-data file.

Performance tuning

Default daemon settings significantly limits LDAP server performance.

Symptoms

When server load fits system limit client applications fails with different kind of timeout errors.

In server log this produces error messages like following:

ARCHIVO /var/log/slapd.log
May 17 15:56:11 ldap2 slapd[13834]: fd=76 DENIED from unknown (192.168.210.101)
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.allow: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.deny: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: fd=237 DENIED from unknown (192.168.77.130)
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.allow: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: daemon: accept(8) failed errno=24 (Too many open files)

Increasing OS limits

First, read ldap system user limits:

root #su ldap -c 'ulimit -aHS' -s '/bin/bash'
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 6981
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 6981
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

The first parameter, you need to increase, is the open files limit.

Maximum available value is described in Documentation/sysctl/fs.txt file of kernel documentation:

ARCHIVO /usr/src/linux-4.9.95-gentoo/Documentation/sysctl/fs.txt
nr_open:
This denotes the maximum number of file-handles a process can 
allocate. Default value is 1024*1024 (1048576) which should be
enough for most machines. Actual limit depends on RLIMIT_NOFILE
resource limit.


PAM system limits are stored in /etc/security/limits.conf file or, optionally, in /etc/security/limits.d/ directory. Daemons, started with sys-apps/openrc init system use these parameters (see sys-apps/openrc: start-stop-daemon should use system-services PAM stack for details), so you need just to put in the file:

ARCHIVO /etc/security/limits.conf
ldap           soft    nofile          4096
ldap           hard    nofile          8192

And restart daemon.

Advertencia
For some unknown reasons, upstart init system together with systemd by design ignores system PAM settings i.e. /etc/security/limits.conf file. Users of systemd init in Gentoo please contact me to verify the solution.

The next limitation is sysctl's net.core.somaxconn parameter.

During run time, this value can be updated via:

root #sysctl -w net.core.somaxconn=256
net.core.somaxconn = 256

After verifying new value do not forget to fix it:

ARCHIVO /etc/sysctl.conf
## For LDAP:
net.core.somaxconn = 256

And, possibly, some other application-specific parameters.

Configurar las herramientas cliente de OpenLDAP

Edite el fichero de configuración del cliente LDAP. Este fichero lo lee ldapsearch y otras herramientas de línea de órdenes ldap.

ARCHIVO /etc/openldap/ldap.confAñadir lo siguiente
BASE         dc=genfic, dc=org
URI          ldap://ldap.genfic.org:389/ ldap://ldap1.genfic.org:389/ ldap://ldap2.genfic.org:389/
TLS_REQCERT  allow
TIMELIMIT    2

Puede comprobar si el servidor está corriendo con la siguiente orden:

user $ldapsearch -x -D "cn=Manager,dc=genfic,dc=org" -W

Si obtiene un error, intente añadir -d 255 para incrementar el nivel de información mostrada y solucionar el problema que tenga.

Configuración del cliente para autenticación centralizada

Existen varios métodos y herramientas que se pueden utilizar para realizar una autenticación remota. Algunas distribuciones incluso disponen de su propia herramienta de configuración de fácil uso. Abajo se muestran algunas (el orden no es importante). Es posible combinar a la vez usuarios locales y cuentas autorizadas centralmente. Estos es importante ya que, por ejemplo, si el servidor LDAP no es accesible, todavía se podrá acceder como root.

  • SSSD (Single Sign-on Services Daemon o Demonio para Servicios de Acceso Sencillo). Su principal función es ofrecer acceso a recursos remotos de identidad y autenticación a través de un marco de trabajo común que puede ofrecer caché y soporte fuera de línea al sistema. Ofrece módulos PAM y NSS. Además, en el futuro, ofrecerá soporte para interfaces D-Bus para información extendida de usuario. También ofrece una base de datos mejorada para almacenar usuarios locales así como datos de usuario extendidos.
  • Utilizar pam_ldap para acceder al servidor LDAP y autenticarse. Las contraseñas no se envían por la red en texto claro.
  • NSLCD (Name Service Look up Daemon o Demonio de Consulta al Servicio de Nombres). Similar a SSSD pero más antiguo.
  • NSS (Name Service Switch o Conmutador de Nombres de Servicio) usando el módulo tradicional pam_unix para obtener los hash de las contraseñas a través de la red. Para permitir que los usuarios actualicen sus contraseñas, este servicio se debe combinar con el método pam_ldap.

Los dos primeros métodos se muestran abajo con las opciones de configuración mínimas para que funcionen.

El método de configuración del cliente PAM con SSSD

Advertencia
Untested as of 2021

Este es el método más directo. Los tres ficheros que se necesitan editar se muestran abajo.

ARCHIVO /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = genfic
debug_level = 5

[nss]
filter_users =
root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd

[domain/genfic]
id_provider = ldap
auth_provider = ldap
ldap_search_base = dc=genfic,dc=org
ldap_tls_reqcert = never
# Servidores ldap primario y de respaldo [primario y],[secudnario]
ldap_uri = ldap://X.X.X.X,ldap://X.X.X.X


Añada sss al final tal y como se muestra abajo para permitir que la búsqueda la gestione el servicio de sistema sssd. Una vez haya terminado de editar, arranque el demonio sssd.

ARCHIVO /etc/nsswitch.confEjemplo de nsswitch.conf con soporte SSSD
passwd: files sss
shadow: files sss
group: files sss

netgroup: files sss
automount: files sss
sudoers: files sss

El último fichero es el más crítico. Abra otro terminal de root como respaldo antes de editarlo. Se han añadido las líneas que acaban en code># para permitir la autenticación remota. Observe el uso de pam_mkhomedir.so para poder crear los directorios de inicio de los usuarios.

ARCHIVO /etc/pam.d/system-authHabilitar soporte para pam_sss
#%PAM-1.0
# Este es un fichero autogenerado.
# Los cambios realizados por el usuario se destruirán la próxima vez que se lance authconfig.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass                                                #
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so                          #
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok                                               #
password required pam_deny.so

session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so                                                              #

Ahora intente acceder desde otro equipo.

Nota
SSSD method could be used not only for LDAP-authentication, but also to use AD-authentication.

El método de configuración del cliente PAM con el módulo pam_ldap

Before starting any change to the client side authentication configuration, make sure that the LDAP server can be reached and presents the correct information. The following steps assume a user Bert Ram was created in the LDAP with login name bertram. Exchange accordingly with a user from the LDAP instance. Use the manager role with caution. But at least check with the LDAP read user role and a user that will logon to the client(s) to be configured: 

# Uses the manager role, prompts for Manager's password
# if you can't use the manager role change -D to reader role
ldapsearch -x uid=bertram -H ldaps://ldap.genfic.org -b "dc=genfic,dc=org" -D cn=Manager,dc=genfic,dc=org -W
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Make a member query for the initgroups with the user that will login
# tests also this user's password
ldapsearch -x '({{|}}(&(objectClass=posixAccount)(uid=bertram))({{&}}(objectClass=posixGroup)(memberUid=bertram)))'  -H ldaps://ldap.genfic.org -b "dc=genfic,dc=org" -D "cn=Bert Ram,dc=genfic,dc=org" -W

En primer lugar configuraremos PAM para permitir la autorización LDAP. Instale sys-auth/pam_ldap de modo que PAM ofrezca soporte para la autorización LDAP y sys-auth/nss_ldap de modo que su sistema pueda trabajar con servidores LDAP para información adicional (usado por nsswitch.conf).

Nota
sys-auth/pam_ldap in combination with sys-auth/nss_ldap is an alternative. It requires a globally readable /etc/ldap.conf which is questionable with recent OpenLDAP setups that prohibit anonymous binds. A readable plain text password is as good as anonymous binds. Also code did not change for a long time and some links are dead. Nevertheless it still works. Also ldap.conf on cliet systems may collide with other services.
root #emerge --ask pam_ldap nss_ldap

El último fichero es el más crítico. Abra algunos terminales de root como respaldo antes de editarlo. Se han añadido las líneas que terminan en # para permitir la autenticación remota.

ARCHIVO /etc/pam.d/system-auth
#%PAM-1.0

auth required pam_env.so
auth sufficient pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_ldap.so use_first_pass                                                      #
auth required pam_deny.so

account sufficient pam_ldap.so                                                                  #
account required pam_unix.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password sufficient pam_unix.so try_first_pass use_authtok nullok md5 shadow
password sufficient pam_ldap.so use_authtok use_first_pass                                      #
password required pam_deny.so 

session required pam_limits.so
session required pam_unix.so 
session optional pam_ldap.so                                                                    #

In /etc/nsswitch.conf each line for passwd, group, shadow and initgroups needs to be prepended with ldap:

ARCHIVO /etc/nsswitch.conf
# Many explanations in comments before...

passwd:         db files ldap
group:          db files ldap
shadow:         db files ldap
initgroups:     db [SUCCESS=continue] files ldap
gshadow:        files

# more statements afterwards
Advertencia
If initgroups lacks ldap as source users logging in with LDAP credentials will have only their primary group. All other groups like wheel, audio, video and so on will be missing.

Ahora cambie /etc/ldap.conf para que contenga:

  • URI to contact LDAP server, use TLS/ ldaps:// by any means, otherwise passwords are transferred unencrypted
  • Base (general) to lookup DNs
  • Bind-DN (and secret) since anonymous binds are bad
  • Base per group, passwd and/ or shadow in case your LDAP tree deviates from defaults (as mentioned in the file's comments)
  • optional client certificates if you use mutual TLS
  • mapping for group membership to memberUid if you use primary group with additional groups expressed by membership
Nota
{{{1}}}
Advertencia
Make sure that /etc/nslcd.conf is owned by nslcd and only readable by nslcd through chmod 400.
ARCHIVO /etc/ldap.conf
#host 127.0.0.1
#base dc=padl,dc=com

base dc=genfic,dc=org
#rootbinddn uid=root,ou=People,dc=genfic,dc=org
bind_policy soft
bind_timelimit 2
ldap_version 3
nss_base_group ou=Group,dc=genfic,dc=org
nss_base_hosts ou=Hosts,dc=genfic,dc=org
nss_base_passwd ou=People,dc=genfic,dc=org
nss_base_shadow ou=People,dc=genfic,dc=org 
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid
pam_password exop
scope one
timelimit 2
uri ldap://ldap.genfic.org/ ldap://ldap1.genfic.org
ldap://ldap2.genfic.org

This is just a note and needs distinction between systemd and OpenRC, start nslcd:

root #/etc/init.d/nslcd start

If the daemon started successfully, change to one of the console terminals. Return to the graphical session by pressing Ctrl+Alt+F7. Switch to one of the 6 login consoles by pressing Ctrl+Alt+F1..F6. At the login prompt, try user bertram.

Convertir la datos base de usuario a LDAP

Configurar OpenLDAP para su administración centralizada y la gestión de elementos Linux/Unix comunes, no es fácil. Gracias a algunas herramientas y guiones disponibles en Internet, la migración desde un punto de vista de un sistema de administración simple a un sistema centralizado y gestionado basado en OpenLDAP no es muy complicado.

Vaya a http://www.padl.com/OSS/MigrationTools.html y obtenga los guiones. Necesitará las herramientas de migración y el guión make_master.sh.

Ahora extraiga y copie el guión make_master.sh dentro de la la localización extraída:

root #mktemp -d
/tmp/tmp.zchomocO3Q
root #cd /tmp/tmp.zchomocO3Q
root #tar xvzf /ruta/a/MigrationTools.tgz
root #mv /ruta/a/make_master.sh MigrationTools-47
root #cd MigrationTools-47

El siguiente paso es migrar la información de su sistema a OpenLDAP. Esto se realiza con el guión make_master.sh una vez le haya proporcionado la información referente a la relacionada con su estructura y entorno LDAP.

En el momento de escribir este documento, las herramientas necesarias requieren las siguientes entradas:

Entrada Descripción Ejemplo
LDAP BaseDN La localización base (raíz) de su árbol dc=genfic,dc=org
Dominio de correo electrónico Dominio utilizado en las direcciones de correo electrónico genfic.org
Servidor de correo FQDN se su infraestructura de servidor de correo electrónico smtp.genfic.org
Nombre de dominio raíz LDAP Información de cuenta administrativa de su estructura LDAP cn=Manager,dc=genfic,dc=org
Contraseña del usuario root de LDAP Contraseña para la cuenta de administración citada anteriormente respecto a la orden slappasswd

La herramienta también le preguntará qué cuentas y ajustes desea migrar.

Advertencia
No necesita hacer cambios en pam.d/system-auth

Troubleshooting

Emerge errors after conversion to LDAP

If for any reasons local user accounts (i.e. /etc/passwd /etc/shadow) or groups (i.e. /etc/group) are deleted after converting the file userbase to LDAP, errors may be encountered relating to missing user (or group) while emerging certain packages.

Example of error while emerging www-servers/apache due to missing "apache" local user account: 

Installing build system files
make[1]: Leaving directory '/var/tmp/portage/www-servers/apache-2.4.41/work/httpd-2.4.41'               [ ok ]
chown: invalid user: ?apache:apache?
* ERROR: www-servers/apache-2.4.41::gentoo failed (install phase):
*   fowners failed

In such cases, a workaround involves emerging the package using FEATURES=-network-sandbox. Doing so has potential security consequences so system users should remain in local files.

Agradecimientos

Nos gustaría dar las gracias a Matt Heler por dejarnos su máquina para realizar esta guía. También queremos agradecer a los tíos simpáticos de #ldap (webchat) en Freenode.net.

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Benjamin Coles, Sven Vermeulen (SwifT) , Brandon Hale, Benny Chuang, jokey,
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.

Retrieved from "https://wiki.gentoo.org/index.php?title=Centralized_authentication_using_OpenLDAP/es&oldid=1292509"