Modelo de seguridad de servicios de nombres LDAP

Los servicios de nombres LDAP pueden utilizar el repositorio LDAP de dos formas diferentes. Una es como una fuente del servicio de nombres y el servicio de autenticación. La otra es estrictamente como la fuente de datos de nombres. En esta sección, se tratan los conceptos de identidad de clientes, los métodos de autenticación, los módulos pam_ldap y pam_unix_*, y la gestión de cuentas cuando el repositorio LDAP se utiliza como un servicio de nombres y un servicio de autenticación. En esta sección, también se trata el uso de los servicios de nombres LDAP junto con el entorno de Kerberos (Parte VI, Servicio Kerberos de Administración de Oracle Solaris 11.1: servicios de seguridad) y los módulos pam_krb5(5).

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

Para acceder a la información del repositorio LDAP, los clientes pueden establecer primero la identidad con el servidor de directorios. Esta identidad puede ser anónima o como un host o usuario que es reconocido por el servidor LDAP. En función de la identidad del cliente y la información de control de acceso (ACI) del servidor, el servidor LDAP permitirá que el cliente lea información del directorio. Para obtener más información sobre ACI, consulte la Guía de administración para la versión de Oracle Directory Server Enterprise Edition que está utilizando.

Si la identidad se basa en el host de donde proviene la solicitud, esto indica que está utilizando la autenticación proxy. Una vez que el host se autentica, todos los usuarios en ese host obtienen acceso. Si la identidad se basa en el usuario, esto indica que utiliza la autenticación per-user. Cada usuario en un host debe estar autenticado para obtener acceso.

Si el cliente se conecta de otra forma que no sea anónimo para cualquier solicitud determinada, el cliente debe demostrar su identidad en el servidor mediante un método de autenticación compatible con el cliente y el servidor. Una vez que el cliente estableció su identidad, puede realizar las distintas las solicitudes de LDAP.

Al iniciar sesión en un sistema, el servicio PAM puede utilizar información de la máquina local, del servicio LDAP, de un servidor Kerberos o de una combinación de los tres para decidir si el intento de inicio de sesión se realizará correctamente. Cuando se utiliza el módulo pam_kerb, la decisión de permitir el acceso es determinada por el servidor Kerberos. Cuando se utiliza el módulo pam_ldap, la mitad de la decisión debe proceder del servidor LDAP y la otra mitad proviene del host local. Con información del host local, utilizando los módulos pam_unix_*, la decisión se realiza de forma local.

Al utilizar pam_ldap para iniciar sesión mediante el servicio LDAP, hay una diferencia en cómo acceden al directorio el servicio de nombres y el servicio de autenticación (pam_ldap). El servicio de nombres lee las distintas entradas y sus atributos del directorio según una identidad predefinida. El servicio de autenticación establece si el usuario introdujo la contraseña correcta mediante el nombre y la contraseña del usuario para autenticarse en el servidor LDAP. Consulte la página del comando man pam_ldap(5) para obtener más información sobre el servicio de autenticación.

Cuando se usa Kerberos para realizar la autenticación y cuando la autenticación en servicios de nombres LDAP también está activada (como se requiere para el modo por usuario), Kerberos puede proporcionar funciones duales. Kerberos se autentica en el servidor y la identidad Kerberos para el principal (usuario o un host) se utiliza para autenticarse en el directorio. En este modo, la misma identidad de usuario que se utiliza para autenticarse en el sistema, también se utiliza para autenticarse en el directorio para consultas y actualizaciones. Los administradores pueden utilizar información de control de acceso (ACI) en el directorio para limitar los resultados fuera del servicio de nombres, si lo desean.

Seguridad de la capa de transporte

La seguridad de la capa de transporte (TLS) se puede utilizar para proteger la comunicación entre un cliente LDAP y el servidor de directorios, y proporciona privacidad e integridad de los datos. El protocolo TLS es un superconjunto del protocolo Capa de sockets seguros (SSL). Los servicios de nombres LDAP admiten conexiones TLS. Tenga en cuenta que con SSL agrega carga en el servidor de directorios y el cliente.

Deberá configurar el servidor de directorios para SSL. Para obtener más información sobre la configuración de Oracle Directory Server Enterprise Edition para SSL, consulte la Guía de administración para la versión de Oracle Directory Server Enterprise Edition para que está utilizando. También deberá configurar el cliente LDAP para SSL.

Si utiliza TLS, las bases de datos de seguridad necesarias deben estar instaladas. En concreto, se necesitan el certificado y los archivos clave de la base de datos. Por ejemplo, si utiliza un formato de base de datos más antiguo desde Netscape Communicator, dos archivos, cert7.db y key3.db, son necesarios. O si utiliza un nuevo formato de base de datos desde Mozilla, tres archivos cert8.db, key3.db y secmod.db, son necesarios. El archivo cert7.db o el archivo cert8.db contienen certificados de confianza. El archivo key3.db contiene las claves del cliente. Incluso si el servicio de nombres LDAP no utiliza las claves del cliente, este archivo debe estar presente. El archivo secmod.db contiene el los módulos de seguridad, como el módulo PKCS#11. Este archivo no es necesario si se utiliza el formato antiguo.

Para obtener más información, consulte Configuración de seguridad TLS.

Asignación de niveles de credencial de cliente

Los clientes de servicios de nombres LDAP se autentican en el servidor LDAP de acuerdo con el nivel de credencial de un cliente. Los clientes LDAP pueden tener varios niveles asignados para autenticarse en un servidor de directorios.

• anonymous

• proxy

• proxy anonymous

• self (denominado per-user en este documento)

Nivel de credencial anonymous de LDAP

Si utiliza el acceso anonymous, sólo puede acceder a los datos que están disponibles para todos. En modo anonymous, no se realiza una operación LDAP BIND. También debe tener en cuenta las consecuencias en la seguridad. El acceso anonymous a determinadas partes del directorio implica que cualquier usuario con acceso al directorio tiene acceso de lectura. Si utiliza un nivel de credencial anonymous, debe permitir acceso de lectura a todas las entradas y los atributos de nombres LDAP.

---

Precaución - Nunca se debe permitir la escritura anonymous en un directorio, ya que cualquiera puede cambiar información en el DIT al que tiene acceso de escritura, incluidas las contraseñas de otros usuarios o su propia identidad.

---

Nivel de credencial proxy de LDAP

El cliente se autentica o se enlaza con un único conjunto compartido de credenciales de enlace LDAP, también conocido como cuenta proxy. Esta cuenta proxy puede ser cualquier entrada que puede vincularse al directorio. Esta cuenta proxy necesita acceso suficiente para realizar las funciones del servicio de nombres en el servidor LDAP. La cuenta proxy es un recurso compartido por sistema. Es decir, cada usuario que ha iniciado sesión en un sistema mediante acceso proxy, incluido el usuario root, ve los mismos resultados que todos los demás usuarios de ese sistema. Necesita configurar proxyDN y proxyPassword en cada cliente utilizando el nivel de credencial proxy. La contraseña cifrada proxyPassword se almacena localmente en el cliente. Puede configurar distintos proxies para los diferentes grupos de clientes. Por ejemplo, puede configurar un proxy para todos los clientes de ventas para acceder a los directorios a los que puede acceder toda la compañía y los de ventas, al mismo tiempo que evita que los clientes de ventas accedan a directorios de recursos humanos con información de nómina. O, en los casos más extremos, puede asignar diferentes proxies a cada cliente o asignar un solo proxy para todos los clientes. Una implementación LDAP típica probablemente estará entre los dos extremos. Tenga en cuenta las opciones cuidadosamente. Muy pocos agentes proxy pueden limitar la capacidad para controlar el acceso del usuario a los recursos. Sin embargo, tener demasiados proxy complican la configuración y el mantenimiento del sistema. Necesita otorgar los derechos apropiados para el usuario de proxy, según el entorno. Consulte Almacenamiento de credenciales de clientes LDAP para obtener información acerca de cómo determinar el método de autenticación más adecuado para su configuración.

Si se cambia la contraseña para un usuario de proxy, debe actualizarla en cada cliente que utiliza ese usuario proxy. Si utiliza caducidad de las contraseñas en cuentas LDAP, asegúrese de desactivar la opción para usuarios proxy.

Además, si los clientes utilizan una credencial proxy para autenticarse, el proxyDN debe tener el mismo proxyPassword en todos los servidores.

Nivel de credencial proxy anonymous de LDAP

proxy anonymous es una entrada de varios valores, ya que tiene más de un valor de credenciales definido. Un cliente asignado al nivel proxy anonymous intentará primero autenticarse con su identidad proxy. Si el cliente no puede autenticarse como usuario de proxy por algún motivo (bloqueo de usuario, contraseña caducada, por ejemplo) utilizará el acceso anónimo. Esto podría resultar en un nivel de servicio diferente, según cómo está configurado el directorio.

Autenticación per-user de LDAP

La autenticación por usuario (self) utiliza la identidad de Kerberos (principal) para realizar una consulta por cada usuario o cada sistema al autenticarse en el servidor de directorios. Con autenticación por usuario, el administrador del sistema puede utilizar la instrucción de control de acceso (ACI), las listas de control de acceso (ACL), los roles, los grupos u otros mecanismos de control de acceso al directorio para otorgar o denegar el acceso a los datos del servicio de nombres de usuarios o sistemas específicos.

Para utilizar el modelo de autenticación por usuario, debe implementarse el servicio de inicio de sesión único de Kerberos. Además, uno o más servidores de directorios utilizados en la implementación deben admitir SASL y el mecanismo de autenticación SASL/GSSAPI. Debido a que Kerberos espera utilizar archivos y DNS para consultas de nombre de host, en lugar de LDAP, debe implementar DNS en este entorno. Además, para usar autenticación por usuario, nscd debe estar activado. El daemon nscd no es un componente opcional en esta configuración.

Conmutador enableShadowUpdate

Si el conmutador enableShadowUpdate está establecido en true en el cliente, las credenciales de administrador se utilizarán para actualizar los datos shadow. Los datos shadow se almacenan en la clase de objeto shadowAccount, en el servidor de directorios. Las credenciales de administrador son definidas por los valores de los atributos adminDN y adminPassword, como se describe en Atributos locales del cliente LDAP. Estas credenciales de administración no se utilizan para ningún otro fin.

Las credenciales de administración tienen propiedades similares a las credenciales Proxy. La excepción es que para las credenciales de administración, el usuario debe tener todos los privilegios para la zona o tener un UID eficaz de root para leer o actualizar los datos shadow. Las credenciales de administración se pueden asignar a cualquier entrada que se puede vincular al directorio. Sin embargo, no utilice la misma identidad del gestor de directorios (cn=Directory Manager) del servidor LDAP.

Esta entrada con credenciales de administración debe tener acceso suficiente para leer y escribir los datos shadow en el directorio. Debido a que la entrada es un recurso compartido por sistema, los atributos adminDN y adminPassword, se deben configurar en cada cliente. La contraseña cifrada adminPassword se almacena localmente en el cliente. La contraseña utiliza los mismos métodos de autenticación que se han configurado para el cliente. Las credenciales de administración son usadas por todos los usuarios y los procesos de un sistema determinado para leer y actualizar datos shadow.

Almacenamiento de credenciales de clientes LDAP

Si configura un cliente para que use una identidad proxy, el cliente guarda la información del proxy en el servicio svc:/network/ldap/client. La implementación LDAP actual no almacena credenciales proxy en el perfil de un cliente. Las credenciales proxy establecidas mediante ldapclient durante la inicialización se almacenan en el repositorio SMF. Esto tiene como resultado una mejor seguridad en la información de DN de proxy y contraseña. Consulte el Capítulo 12, Configuración de clientes LDAP (tareas) para obtener información sobre la configuración de perfiles de cliente.

De modo similar, si configura un cliente para activar las actualizaciones de datos shadow, y el nivel de credencial del cliente no es self, el cliente guarda la información en el servicio svc:/network/ldap/client.

Si configura un cliente utilice autenticación por usuario, la identidad Kerberos y la información de ticket Kerberos para cada principal (cada usuario o host) se utilizan durante la autenticación. En este entorno el servidor de directorios asigna el principal de Kerberos para un DN y la credenciales de Kerberos se utilizan para autenticar a ese DN. El servidor de directorios puede, entonces, utilizar sus mecanismos de instrucción de control de acceso (ACI) para permitir o denegar el acceso a los datos del servicio de nombres. En esta situación, el ticket de información Kerberos se utiliza para autenticarse en el servidor de directorios y el sistema no almacena autenticación DN o las contraseñas en el sistema. Por consiguiente, en este tipo de configuración, no es necesario que especifique los atributos adminDN y adminPassword cuando el cliente se inicializa con el comando ldapclient.

Selección de métodos de autenticación para el servicio de nombres LDAP

Al asignar el nivel de credencial proxy o proxy-anonymous a un cliente, también tiene que seleccionar un método para que el proxy se autentique en el servidor de directorios. De manera predeterminada, el método de autenticación es none, que implica el acceso anónimo. El método de autenticación también es posible que tenga una opción de seguridad de transporte asociada.

El método de autenticación, como el nivel de credencial, puede tener varios valores. Por ejemplo, en el perfil de cliente puede especificar que el cliente primero intente vincular con el métodosimple protegido por TLS. Si no funciona, el cliente deberá intentar vincular con el método sasl/digest-MD5. El authenticationMethod sería tls:simple;sasl/digest-MD5.

Los servicios de nombres LDAP admiten algunos mecanismos de Autenticación sencilla y capa de seguridad (SASL). Estos mecanismos permiten un intercambio de contraseña seguro sin necesidad de TLS. Sin embargo, estos mecanismos no proporcionan integridad de los datos o privacidad. Consulte la RFC 2222, para obtener información sobre SASL.

Los siguientes mecanismos de autenticación son compatibles.

• none

  El cliente no se autentica en el directorio. Es equivalente al nivel de credencial anonymous.

• simple

  Si el sistema cliente utiliza el método de autenticación simple, vincula con el servidor enviando la contraseña de usuario sin cifrar. La contraseña está, por lo tanto, sujeta a ser vista a menos que la sesión esté protegida por IPsec. Las ventajas principales de utilizar el método de autenticación simple son que todos los servidores de directorios lo admiten y que es fácil de configurar.

• sasl/digest-MD5

  La contraseña de cliente está protegida durante la autenticación, pero la sesión no está cifrada. Algunos servidores de directorios, incluidos Oracle Directory Server Enterprise Edition, también admiten el método de autenticación sasl/digest-MD5. La principal ventaja de digest-MD5 es que la contraseña no se transmite sin cifrar durante la autenticación y, por lo tanto, es más seguro que el método de autenticación simple. Consulte la RFC 2831 para obtener información sobre digest-MD5. digest-MD5 se considera una mejora de cram-MD5 por su seguridad mejorada.

  Cuando se utiliza sasl/digest-MD5, la autenticación es segura, pero la sesión no está protegida.

  ---

  Nota - Si está utilizando Oracle Directory Server Enterprise Edition, la contraseña se debe almacenar sin cifrar en el directorio.

  ---

• sasl/cram-MD5

  En este caso, la sesión LDAP no está cifrada, pero la contraseña del cliente está protegida durante la autenticación, ya que se realiza mediante sasl/cram-MD5. Este método de autenticación está obsoleto y no debe usarse.

• sasl/GSSAPI

  Este método de autenticación se utiliza junto con el modo de credencial self para activar las consultas por usuario. Un nscd por usuario asignado para poder utilizar las credenciales del cliente se vincula con el servidor de directorios usando el método sasl/GSSAPI y las credenciales de cliente de Kerberos. El acceso se puede controlar en el servidor de directorios por usuario.

• tls:simple

  El cliente se vincula mediante el método simple y la sesión está cifrada. La contraseña está protegida.

• tls:sasl/cram-MD5

  La sesión LDAP está cifrada y el cliente se autentica con el servidor de directorios mediante sasl/cram-MD5.

• tls:sasl/digest-MD5

  La sesión LDAP está cifrada y el cliente se autentica con el servidor de directorios mediante sasl/digest-MD5.

---

Precaución - Oracle Directory Server Enterprise Edition requiere que las contraseñas se almacenen sin cifrar para utilizar digest-MD5. Si el método de autenticación está definido en sasl/digest-MD5 o tls:sasl/digest-MD5, las contraseñas para el usuario proxy deberán almacenarse sin cifrar. Tenga especial cuidado en que el atributo userPassword tenga la ACI adecuada si está almacenado sin cifrar, de modo que no se pueda leer.

---

La siguiente tabla resume los diferentes métodos de autenticación y sus respectivas características.

Tabla 9-4 Métodos de autenticación

Especificación de métodos de autenticación para servicios específicos en LDAP

El método de autenticación se puede especificar para un servicio determinado en el atributo serviceAuthenticationMethod. Los siguientes servicios permiten la selección del método de autenticación:

• passwd-cmd

  Este servicio es utilizado por passwd(1) para cambiar la contraseña de inicio de sesión y los atributos de contraseña.

• keyserv

  Este servicio es utilizado por las utilidades chkey(1) y newkey(1M) para crear y cambiar el par de claves Diffie-Hellman de un usuario.

• pam_ldap

  Este servicio se utiliza para autenticar usuarios con pam_ldap(5).

  pam_ldap admite la gestión de cuentas.

El siguiente ejemplo muestra una sección de un perfil de cliente en el que los usuarios utilizarán sasl/digest-MD5 para autenticarse en el servidor de directorios, pero utilizarán una sesión de SSL para modificar su contraseña.

serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5
serviceAuthenticationMethod=passwd-cmd:tls:simple

Métodos de autenticación conectables

Mediante la estructura PAM, puede elegir entre varios servicios de autenticación, incluidos los módulos pam_unix_*, pam_krb5 y pam_ldap_*.

Si se utiliza el método de autenticación por usuario, pam_krb5, el servicio de autenticación más fuerte de los tres mencionados más arriba, debe estar activado. Consulte pam_krb5(5) y Administración de Oracle Solaris 11.1: servicios de seguridad.

El sistema de autenticación pam_krb5 se puede utilizar incluso si la autenticación por usuario no está activada. Si se utilizan los niveles de credencial de proxy o anonymous para acceder a los datos del servidor de directorios, entonces, no es posible restringir el acceso a los datos del directorio por usuario.

Debido a su mayor flexibilidad, la compatibilidad con métodos de autenticación más seguros y la capacidad para usar la gestión de cuentas, el uso del módulo pam_ldap es preferible al uso de los módulos pam_unix_* cuando se utilizan los métodos de autenticación anonymous o proxy.

Módulos de servicio pam_unix_*

Si no ha cambiado el archivo /etc/pam.conf, la autenticación UNIX está activada de manera predeterminada.

A continuación, se muestra una lista de los módulos que proporcionan el equivalente al módulo pam_unix original.

Los módulos pam_unix_* siguen el modelo tradicional de autenticación UNIX, como se describe en la siguiente lista.

1. El cliente recupera la contraseña cifrada del usuario del servicio de nombres.

2. Se le pedirá al usuario la contraseña de usuario.

3. La contraseña de usuario está cifrada.

4. El cliente compara las dos contraseñas cifradas para determinar si el usuario debe autenticarse.

Adicionalmente, hay dos restricciones cuando se usan los módulos pam_unix_*.

• La contraseña se debe almacenar en formato UNIX crypt y no con otros métodos de cifrado, incluido sin cifrar.

• El atributo userPassword debe ser legible por el servicio de nombres.

  Por ejemplo, si define el nivel de credencial en anonymous, todos los usuarios deben poder leer el atributo userPassword. De manera similar, si define el nivel de credencial en proxy, el usuario proxy debe poder leer el atributo userPassword.

Módulo de servicio Kerberos

Consulte la página del comando man pam_krb5(5) y Administración de Oracle Solaris 11.1: servicios de seguridad.

Módulo de servicio LDAP

Al implementar la autenticación LDAP, el usuario se enlaza al servidor LDAP mediante el método de autenticación definido en el parámetro serviceAuthenticationMethod de pam_ldap si existe uno. De lo contrario, se utiliza authenticationMethod.

Si pam_ldap puede vincularse al servidor con la identidad del usuario y contraseña proporcionados, autentifica al usuario.

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

pam_ldap no lee el atributo userPassword. Por lo tanto, no es necesario otorgar acceso para leer el atributo userPassword, a menos que haya otros clientes que utilicen la autenticación UNIX. Además, pam_ldap no admite el método de autenticación none. Por lo tanto, debe definir los atributos serviceAuthenticationMethod o authenticationMethod para que los clientes puedan usar pam_ldap. Consulte la página del comando man pam_ldap(5) para obtener más información.

---

Precaución - Si se utiliza el método de autenticación simple, el atributo userPassword puede ser leído en la transferencia por terceros.

---

En la tabla siguiente, se resumen las diferencias principales entre los mecanismos de autenticación.

Tabla 9-5 Comportamiento de autenticación en LDAP

PAM y cambio de contraseñas

Utilice el comando passwd para cambiar una contraseña. Si el conmutador enableShadowUpdate no está establecido en true, el atributo userPassword debe poder ser escrito por el usuario. Si el conmutador enableShadowUpdate se establece en true, las credenciales de administración debe poder actualizar el atributo userPassword. Recuerde que el serviceAuthenticationMethod para passwd-cmd sustituye el authenticationMethod de esta operación. En función del método de autenticación que se utiliza, la contraseña actual se puede transmitir sin cifrar.

En el caso de la autenticación UNIX, el nuevo atributo userPassword se cifra usando el formato crypt de UNIX y se etiqueta antes de ser escrito en LDAP. Por lo tanto, la nueva contraseña se cifra en la transferencia, independientemente del método de autenticación utilizado para vincular con el servidor. Consulte la página del comando man pam_authtok_store(5) para obtener más información.

Si el conmutador enableShadowUpdate está establecido en true, los módulos pam_unix_* también actualizan la información shadow relacionada cuando se cambia la contraseña de usuario. Los módulos pam_unix_* actualizan los mismos campos shadow en los archivos shadow locales que los módulos actualizan cuando se cambia la contraseña de usuario local.

pam_ldap ya no admite la actualización de la contraseña. El pam_authtok_store con la opción server_policy ahora reemplaza la capacidad de actualización de contraseña de pam_ldap. Al utilizar pam_authtok_store, la nueva contraseña se envía al servidor LDAP sin cifrar. Por lo tanto, para garantizar la privacidad, utilice TLS. Si TLS no se utiliza, la nueva userPassword puede ser espiada. Si establece una contraseña sin etiqueta con Oracle Directory Server Enterprise Edition, el software cifra la contraseña mediante el atributo passwordStorageScheme. Para obtener más información acerca de passwordStorageScheme, consulte la sección sobre la gestión de cuentas de usuario en la Guía de administración para la versión de Oracle Directory Server Enterprise Edition que está utilizando.

Gestión de cuentas de LDAP

Si selecciona pam_krb5 como su sistema de gestión de cuenta y contraseña, el entorno Kerberos gestionará todas la cuentas, las contraseñas, el bloqueo de cuentas y otros detalles de gestión de cuentas. Consulte la página del comando man pam_krb5(5) y Administración de Oracle Solaris 11.1: servicios de seguridad.

Si no utiliza pam_krb5, los servicios de nombres LDAP se pueden configurar para aprovechar el soporte de la directiva de bloqueo de contraseña y cuenta en Oracle Directory Server Enterprise Edition. Puede configurar pam_ldap(5) para admitir la gestión de cuentas de usuario. passwd(1) aplica reglas de sintaxis de contraseña establecidas por la política de contraseñas de Oracle Directory Server Enterprise Edition cuando se utiliza con la configuración de PAM adecuada.

Las siguientes funciones de gestión de cuentas se admiten mediante pam_ldap(5). Estas funciones dependen de la configuración de la directiva de bloqueo de contraseña y cuenta de Oracle Directory Server Enterprise Edition. Puede activar las funciones que desee.

• Notificación de fecha de la contraseña y caducidad

  Los usuarios deben cambiar sus contraseñas en función de la programación. Una contraseña caduca si no se cambia en el tiempo configurado. Una contraseña caducada hace que la autenticación del usuario falle.

  Los usuarios ven un mensaje de advertencia siempre que inician sesión en el período de advertencia de caducidad. El mensaje especifica el número de días u horas que faltan para que caduque la contraseña.

• Comprobación de la sintaxis de la contraseña

  Las nuevas contraseñas deben cumplir con los requisitos de longitud mínima de la contraseña. Además, una contraseña no puede coincidir con el valor de los atributos uid, cn, sn o mail en la entrada de directorio del usuario.

• Comprobación de contraseñas en el historial

  Los usuarios no pueden reutilizar las contraseñas. Si un usuario intenta cambiar la contraseña por otra que se utilizó previamente, passwd(1) falla. Los administradores de LDAP pueden configurar la cantidad de contraseñas que se mantienen en la lista de historial del servidor.

• Bloqueo de cuenta de usuario

  Es posible bloquear una cuenta de usuario después de una determinada cantidad de fallas de autenticación repetidas. Un usuario también puede estar bloqueado si un administrador inactiva su cuenta. La autenticación seguirá fallando hasta que pase el tiempo de bloqueo de la cuenta o que el administrador vuelva a activarla.

Antes de configurar la contraseña y la política de bloqueo de cuentas en Oracle Directory Server Enterprise Edition, asegúrese de que todos los hosts utilicen el cliente LDAP “más reciente” con la gestión de cuentas pam_ldap.

Además, asegúrese de que los clientes tengan un archivo pam.conf(4) configurado adecuadamente. De lo contrario, los servicios de nombres LDAP no funcionarán si caduca la contraseña proxy o de usuario.

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

Gestión de cuentas de LDAP con los módulos pam_unix_*

Si el conmutador enableShadowUpdate está establecido en true en el cliente, la funcionalidad de gestión de cuentas disponible para cuentas locales también está disponible para cuentas LDAP. La funcionalidad incluye la fecha de la contraseña, el vencimiento y la notificación de la cuenta, el inicio de sesión fallido del bloqueo de cuenta, etc. Además, ahora las opciones -dluNfnwx para el comando passwd se admiten en LDAP. Por lo tanto, todas las funciones del comando passwd y los módulos pam_unix_* en el servicio de nombres de los archivos se pueden usar en el servicio de nombres LDAP. El conmutador enableShadowUpdate ofrece una manera de implementar la gestión de cuentas de forma coherente para usuarios que están definidos en los archivos y en el ámbito LDAP.

Para evitar que los usuarios modifiquen sus propios datos de gestión de cuentas y, por lo tanto, eludan la directiva de contraseñas, el servidor LDAP está configurado para impedir al usuario el acceso de escritura a sus propios datos shadow en el servidor. Un administrador con credenciales de administración realiza las actualizaciones de datos shadow para un sistema cliente. Una configuración de ese tipo, sin embargo, entra en conflicto con el módulo pam_ldap, que requiere que las contraseñas puedan ser modificadas por los usuarios. Por lo tanto, la gestión de cuentas de pam_ldap y los módulos pam_unix_* son incompatibles.

---

Precaución - No utilice los módulos pam_ldap y los módulos pam_unix_* en el mismo dominio de nombres LDAP. Todos los clientes utilizan el módulo pam_ldap o todos los clientes utilizan los módulos pam_unix_*. Esta limitación podría indicar que usted necesita un servidor LDAP dedicado. Por ejemplo, una aplicación web o de correo electrónico puede esperar que los usuarios cambien sus propias contraseñas en el servidor LDAP.

---

La implementación de enableShadowUpdate también requiere que la credencial de administrador (adminDN y adminPassword) se almacene localmente en cada cliente. Esta información se almacena en el servicio svc:/network/ldap/client.

A diferencia de cuando se usa pam_ldap para la gestión de cuentas, el uso de los módulos pam_unix_* para la gestión de cuentas no requiere un cambio en el archivo /etc/pam.conf. El archivo /etc/pam.conf predeterminado es suficiente.