Red Hat Training

A Red Hat training course is available for RHEL 8

Configurar y gestionar la gestión de identidades

Red Hat Enterprise Linux 8

Configuración, gestión y mantenimiento de la gestión de identidades en Red Hat Enterprise Linux 8

Resumen

Esta colección de documentación proporciona instrucciones sobre cómo configurar, gestionar y mantener eficazmente la Gestión de Identidades en Red Hat Enterprise Linux 8.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a sustituir el lenguaje problemático en nuestro código, documentación y propiedades web. Estamos empezando con estos cuatro términos: maestro, esclavo, lista negra y lista blanca. Debido a la enormidad de este esfuerzo, estos cambios se implementarán gradualmente a lo largo de varias versiones próximas. Para más detalles, consulte el mensaje de nuestro CTO Chris Wright.

Proporcionar comentarios sobre la documentación de Red Hat

Agradecemos su opinión sobre nuestra documentación. Por favor, díganos cómo podemos mejorarla. Para ello:

  • Para comentarios sencillos sobre pasajes concretos:

    1. Asegúrese de que está viendo la documentación en el formato Multi-page HTML. Además, asegúrese de ver el botón Feedback en la esquina superior derecha del documento.
    2. Utilice el cursor del ratón para resaltar la parte del texto que desea comentar.
    3. Haga clic en la ventana emergente Add Feedback que aparece debajo del texto resaltado.
    4. Siga las instrucciones mostradas.
  • Para enviar comentarios más complejos, cree un ticket de Bugzilla:

    1. Vaya al sitio web de Bugzilla.
    2. Como componente, utilice Documentation.
    3. Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s) parte(s) pertinente(s) de la documentación.
    4. Haga clic en Submit Bug.

Capítulo 1. Inicio de sesión en la Gestión de Identidades desde la línea de comandos

La gestión de identidades (IdM) utiliza el protocolo Kerberos para soportar el inicio de sesión único. El inicio de sesión único significa que el usuario introduce el nombre de usuario y la contraseña correctos una sola vez y, a continuación, accede a los servicios de IdM sin que el sistema le pida las credenciales de nuevo.

Importante

En IdM, el demonio de servicios de seguridad del sistema (SSSD) obtiene automáticamente un ticket de concesión (TGT) para un usuario después de que éste inicie correctamente la sesión en el entorno de escritorio de un equipo cliente de IdM con el correspondiente nombre de entidad de seguridad de Kerberos. Esto significa que después de iniciar la sesión, el usuario no tiene que utilizar la utilidad kinit para acceder a los recursos de IdM.

Si ha borrado la caché de credenciales de Kerberos o su TGT de Kerberos ha caducado, deberá solicitar un ticket de Kerberos manualmente para acceder a los recursos de IdM. En las siguientes secciones se presentan las operaciones básicas de usuario cuando se utiliza Kerberos en IdM.

1.1. Utilizando kinit para iniciar sesión en IdM manualmente

Este procedimiento describe el uso de la utilidad kinit para autenticarse en un entorno de gestión de identidades (IdM) de forma manual. La utilidad kinit obtiene y almacena en caché un ticket Kerberos (TGT) en nombre de un usuario IdM.

Nota

Utilice este procedimiento sólo si ha destruido su TGT inicial de Kerberos o si ha caducado. Como usuario de IdM, al iniciar la sesión en su máquina local también está iniciando automáticamente la sesión en IdM. Esto significa que, después de iniciar la sesión, no es necesario utilizar la utilidad kinit para acceder a los recursos de IdM.

Procedimiento

  1. Para conectarse a IdM

    • bajo el nombre de usuario del usuario que ha iniciado la sesión en el sistema local, utilice kinit sin especificar un nombre de usuario. Por ejemplo, si está conectado como example_user en el sistema local:

      [example_user@server ~]$ kinit
      Password for example_user@EXAMPLE.COM:
      [example_user@server ~]$

      Si el nombre de usuario del usuario local no coincide con ninguna entrada de usuario en IdM, el intento de autenticación falla:

      [example_user@server ~]$ kinit
      kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    • utilizando una entidad de seguridad Kerberos que no se corresponde con su nombre de usuario local, pase el nombre de usuario requerido a la utilidad kinit. Por ejemplo, para iniciar sesión como el usuario admin:

      [example_user@server ~]$ kinit admin
      Password for admin@EXAMPLE.COM:
      [example_user@server ~]$
  2. Opcionalmente, para verificar que el inicio de sesión fue exitoso, utilice la utilidad klist para mostrar el TGT en caché. En el siguiente ejemplo, la caché contiene un ticket para la entidad de seguridad example_user, lo que significa que en este host concreto, sólo example_user puede acceder actualmente a los servicios de IdM:

    $ klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: example_user@EXAMPLE.COM
    
    Valid starting     	Expires            	Service principal
    11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

1.2. Destrucción del ticket Kerberos activo de un usuario

Esta sección describe cómo borrar la caché de credenciales que contiene el ticket Kerberos activo del usuario.

Procedimiento

  1. Para destruir su ticket de Kerberos:

    [ejemplo_usuario@servidor ~]$ kdestroy
  2. Opcionalmente, para comprobar que el ticket de Kerberos ha sido destruido:

    [example_user@server ~]$ klist
    klist: Credentials cache keyring 'persistent:0:0' not found

1.3. Configuración de un sistema externo para la autenticación Kerberos

Esta sección describe cómo configurar un sistema externo para que los usuarios de Identity Management (IdM) puedan iniciar sesión en IdM desde el sistema externo utilizando sus credenciales de Kerberos.

Habilitar la autenticación Kerberos en sistemas externos es especialmente útil cuando su infraestructura incluye varios reinos o dominios superpuestos. También es útil si el sistema no se ha inscrito en ningún dominio de IdM a través de ipa-client-install.

Para habilitar la autenticación Kerberos en IdM desde un sistema que no es miembro del dominio IdM, defina un archivo de configuración Kerberos específico para IdM en el sistema externo.

Requisitos previos

  • El paquete krb5-workstation está instalado en el sistema externo.

    Para saber si el paquete está instalado, utilice el siguiente comando de la CLI:

    # yum list installed krb5-workstation
    Installed Packages
    krb5-workstation.x86_64    1.16.1-19.el8     @BaseOS

Procedimiento

  1. Copie el archivo /etc/krb5.conf del servidor IdM al sistema externo. Por ejemplo:

    # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
    Aviso

    No sobrescriba el archivo krb5.conf existente en el sistema externo.

  2. En el sistema externo, configure la sesión de terminal para que utilice el archivo de configuración IdM Kerberos copiado:

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

    La variable KRB5_CONFIG sólo existe temporalmente hasta que se cierra la sesión. Para evitar esta pérdida, exporte la variable con un nombre de archivo diferente.

  3. Copie los fragmentos de configuración de Kerberos del directorio /etc/krb5.conf.d/ al sistema externo.

Los usuarios del sistema externo ya pueden utilizar la utilidad kinit para autenticarse en el servidor IdM.

Recursos adicionales

  • Para más detalles sobre Kerberos, consulte las páginas de manual krb5.conf(5), kinit(1), klist(1), y kdestroy(1).

Capítulo 2. Ver, iniciar y detener los servicios de Gestión de Identidades

Los servidores de gestión de identidades (IdM) son sistemas Red Hat Enterprise Linux que funcionan como controladores de dominio (DC). Una serie de servicios diferentes se ejecutan en los servidores IdM, sobre todo el servidor de directorio, la autoridad de certificación (CA), DNS y Kerberos.

2.1. Los servicios de IdM

2.1.1. Lista de servicios alojados en servidores IdM

La mayoría de los siguientes servicios no son estrictamente necesarios para ser instalados en el servidor de IdM. Por ejemplo, puede instalar servicios como una autoridad de certificados (CA) o un servidor DNS en un servidor externo fuera del dominio de IdM.

Kerberos
los servicios krb5kdc y kadmin

IdM utiliza el protocolo Kerberos para soportar el inicio de sesión único. Con Kerberos, los usuarios sólo tienen que presentar el nombre de usuario y la contraseña correctos una vez y pueden acceder a los servicios de IdM sin que el sistema les pida las credenciales de nuevo.

Kerberos se divide en dos partes:

  • El servicio krb5kdc es el servicio de autenticación Kerberos y el demonio del Centro de Distribución de Claves (KDC).
  • El servicio kadmin es el programa de administración de la base de datos Kerberos.

Para obtener información sobre cómo autenticarse mediante Kerberos en IdM, consulte Inicio de sesión en Identity Management desde la línea de comandos e Inicio de sesión en IdM en la interfaz web: Uso de un ticket de Kerberos .

Servidor de directorio LDAP
el servicio dirsrv

La instancia de IdM LDAP directory server almacena toda la información de IdM, como la información relacionada con Kerberos, cuentas de usuario, entradas de host, servicios, políticas, DNS y otros. La instancia del servidor de directorio LDAP se basa en la misma tecnología que Red Hat Directory Server. Sin embargo, está ajustada a las tareas específicas de IdM.

Autoridad de certificación
el servicio pki-tomcatd

El certificate authority (CA) integrado se basa en la misma tecnología que Red Hat Certificate System. pki es la interfaz de línea de comandos para acceder a los servicios de Certificate System.

También puede instalar el servidor sin la CA integrada si crea y proporciona todos los certificados necesarios de forma independiente.

Para más información, consulte Planificación de sus servicios de CA.

Sistema de nombres de dominio (DNS)
el servicio named

IdM utiliza DNS para el descubrimiento dinámico de servicios. La utilidad de instalación del cliente IdM puede utilizar la información del DNS para configurar automáticamente la máquina cliente. Una vez que el cliente está inscrito en el dominio IdM, utiliza el DNS para localizar los servidores y servicios IdM dentro del dominio. La implementación BIND (Berkeley Internet Name Domain) de los protocolos DNS (Domain Name System) en Red Hat Enterprise Linux incluye el servidor DNS named. named-pkcs11 es una versión del servidor DNS BIND construida con soporte nativo para el estándar criptográfico PKCS#11.

Para más información, consulte Planificación de los servicios DNS y los nombres de host.

Servidor HTTP Apache
el servicio httpd

Apache HTTP web server proporciona la interfaz web de IdM y también gestiona la comunicación entre la autoridad de certificación y otros servicios de IdM.

Samba / Winbind
smb y winbind servicios

Samba implementa el protocolo Server Message Block (SMB), también conocido como el protocolo Common Internet File System (CIFS), en Red Hat Enterprise Linux. A través del servicio smb, el protocolo SMB le permite acceder a los recursos de un servidor, tales como archivos compartidos e impresoras compartidas. Si ha configurado una confianza con un entorno de Directorio Activo (AD), el servicio `Winbind` gestiona la comunicación entre los servidores IdM y los servidores AD.

Autenticación por contraseña única (OTP)
los servicios de ipa-otpd

Las contraseñas de un solo uso (OTP) son contraseñas generadas por un token de autenticación para una sola sesión, como parte de la autenticación de dos factores. La autenticación OTP se implementa en Red Hat Enterprise Linux a través del servicio ipa-otpd.

Para obtener más información, consulte Inicio de sesión en la interfaz web de gestión de identidades mediante contraseñas de un solo uso.

OpenDNSSEC
el servicio ipa-dnskeysyncd

OpenDNSSEC es un gestor de DNS que automatiza el proceso de seguimiento de las claves de las extensiones de seguridad de DNS (DNSSEC) y la firma de las zonas. El servicio ipa-dnskeysyncd gestiona la sincronización entre el servidor de directorio IdM y OpenDNSSEC.

The Identity Management Server: Unifying Services

2.1.2. Lista de servicios alojados por los clientes de IdM

  • System Security Services Daemon: el servicio sssd

El System Security Services Daemon (SSSD) es la aplicación del lado del cliente que gestiona la autenticación del usuario y el almacenamiento en caché de las credenciales. El almacenamiento en caché permite al sistema local continuar con las operaciones normales de autenticación si el servidor de IdM no está disponible o si el cliente se desconecta.

Para más información, vea Cómo entender el SSSD y sus beneficios.

  • Certmonger: el servicio certmonger

El servicio certmonger supervisa y renueva los certificados en el cliente. Puede solicitar nuevos certificados para los servicios del sistema.

Para más información, consulte Obtención de un certificado IdM para un servicio mediante certmonger.

Interactions Between IdM Services

2.2. Ver el estado de los servicios IdM

Para ver el estado de los servicios de IdM que están configurados en su servidor de IdM, ejecute el comando ipactl status:

[root@server ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

La salida del comando ipactl status en su servidor depende de su configuración de IdM. Por ejemplo, si una implementación de IdM no incluye un servidor DNS, el servicio named no está presente en la lista.

Nota

No se puede utilizar la interfaz web de IdM para ver el estado de todos los servicios de IdM que se ejecutan en un servidor de IdM concreto. Los servicios kerberizados que se ejecutan en diferentes servidores se pueden ver en la pestaña IdentityServices de la interfaz web de IdM.

Puede iniciar o detener todo el servidor, o sólo un servicio individual.

Para iniciar, detener o reiniciar todo el servidor IdM, consulte:

Para iniciar, detener o reiniciar un servicio IdM individual, consulte:

Para visualizar la versión del software IdM, véase:

2.3. Iniciar y detener el servidor de Gestión de Identidades completo: la utilidad ipactl

Utilice la utilidad ipactl para detener, iniciar o reiniciar todo el servidor IdM junto con todos los servicios instalados. El uso de la utilidad ipactl garantiza que todos los servicios se detengan, inicien o reinicien en el orden adecuado. No es necesario tener un ticket Kerberos válido para ejecutar los comandos de ipactl.

ipactl comandos

Para iniciar todo el servidor IdM:

# ipactl start

Para detener todo el servidor IdM:

# ipactl stop

Para reiniciar todo el servidor IdM:

# ipactl restart

Para mostrar el estado de todos los servicios que componen el IdM:

# ipactl status
Importante

No se puede utilizar la interfaz web de IdM para realizar los comandos de ipactl.

2.4. Iniciar y detener un servicio de gestión de identidades individual: la utilidad systemctl

Por lo general, no se recomienda modificar manualmente los archivos de configuración de IdM. Sin embargo, ciertas situaciones requieren que un administrador realice una configuración manual de servicios específicos. En tales situaciones, utilice la utilidad systemctl para detener, iniciar o reiniciar un servicio IdM individual.

Por ejemplo, utilice systemctl después de personalizar el comportamiento del servidor de directorio, sin modificar los demás servicios de IdM:

# systemctl restart dirsrv@REALM-NAME.service

Además, al desplegar inicialmente un fideicomiso IdM con Active Directory, modifique el archivo /etc/sssd/sssd.conf, añadiendo:

  • parámetros específicos para ajustar las opciones de configuración del tiempo de espera en un entorno en el que los servidores remotos tienen una alta latencia
  • parámetros específicos para ajustar la afinidad de sitios de Active Directory
  • anulaciones para ciertas opciones de configuración que no son proporcionadas por la configuración global de IdM

Para aplicar los cambios realizados en el archivo /etc/sssd/sssd.conf:

# systemctl restart sssd.service

La ejecución de systemctl restart sssd.service es necesaria porque el demonio de servicios de seguridad del sistema (SSSD) no relee ni aplica automáticamente su configuración.

Tenga en cuenta que para los cambios que afectan a los rangos de identidad de IdM, se recomienda reiniciar el servidor por completo.

Importante

Para reiniciar varios servicios de dominio IdM, utilice siempre ipactl. Debido a las dependencias entre los servicios instalados con el servidor IdM, el orden en que se inician y se detienen es fundamental. La utilidad ipactl garantiza que los servicios se inicien y detengan en el orden adecuado.

Comandos útiles de systemctl

Para iniciar un servicio IdM concreto:

# systemctl start name.service

Para detener un servicio IdM concreto:

# systemctl stop name.service

Para reiniciar un servicio IdM concreto:

# systemctl restart name.service

Para ver el estado de un servicio IdM concreto:

# systemctl status name.service
Importante

No puede utilizar la interfaz web de IdM para iniciar o detener los servicios individuales que se ejecutan en los servidores de IdM. Sólo puede utilizar la interfaz web para modificar la configuración de un servicio Kerberizado navegando a IdentityServices y seleccionando el servicio.

2.5. Métodos para mostrar la versión del software IdM

Puedes mostrar el número de versión de IdM con:

  • la IdM WebUI
  • ipa comandos
  • rpm comandos

Visualización de la versión a través de la WebUI

En la IdM WebUI, la versión del software se puede mostrar eligiendo About en el menú de nombre de usuario en la parte superior derecha.

Checking IdM Software Version
Visualización de la versión con los comandos ipa

Desde la línea de comandos, utilice el comando ipa --version.

[root@server ~]# ipa --version
VERSION: 4.8.0, API_VERSION: 2.233
Visualización de la versión con los comandos rpm

Si los servicios de IdM no funcionan correctamente, puede utilizar la utilidad rpm para determinar el número de versión del paquete ipa-server que está instalado actualmente.

[root@server ~]# rpm -q ipa-server
ipa-server-4.8.0-11.module+el8.1.0+4247+9f3fd721.x86_64

Capítulo 3. Introducción a las utilidades de la línea de comandos de IdM

En las siguientes secciones se describen los aspectos básicos del uso de las utilidades de la línea de comandos de Gestión de Identidades (IdM).

Requisitos previos

3.1. ¿Qué es la interfaz de línea de comandos IPA?

La interfaz de línea de comandos (CLI) de IPA es la interfaz de línea de comandos básica para la administración de la gestión de identidades (IdM).

Soporta una gran cantidad de subcomandos que se utilizan para gestionar el IdM, como el comando ipa user-add para añadir un nuevo usuario.

IPA CLI le permite:

  • Añadir, gestionar o eliminar usuarios, grupos, hosts y otros objetos de la red.
  • Gestionar los certificados.
  • Entradas de búsqueda.
  • Mostrar y listar objetos.
  • Establezca los derechos de acceso.
  • Obtenga ayuda con la sintaxis correcta del comando.

3.2. Qué es la ayuda del IPA

La ayuda de IPA es un sistema de documentación integrado para el servidor IdM.

La interfaz de línea de comandos (CLI) de IPA genera los temas de ayuda disponibles de los módulos plugin de IdM cargados. Si quieres ejecutar la ayuda de IPA con éxito, necesitas:

  • Tener un servidor IdM instalado y en funcionamiento.
  • Estar autenticado con un ticket Kerberos válido.

Al ejecutar el comando ipa help sin opciones, se muestra información sobre el uso básico de la ayuda y los ejemplos de comandos más comunes.

La ejecución de help con opciones tiene la siguiente sintaxis:

$ ipa help [TOPIC | COMMAND | topics | commands]
  • []- Los corchetes significan que todos los parámetros son opcionales y que puedes escribir sólo ipa help y el comando se ejecutará.
  • |- El carácter pipa significa or. Por lo tanto, puede utilizar TOPIC o COMMAND o temas o comandos con el comando básico ipa help.
  • topics- Puede ejecutar el comando ipa help topics y se ejecutará correctamente. El comando muestra una lista de temas que están cubiertos por la ayuda de IPA, por ejemplo, user, cert, server y muchos otros.
  • TOPIC- El TOPIC con mayúsculas significa variable, por lo tanto, puede utilizar el tema particular, por ejemplo, ipa help user
  • commands- Puede ejecutar el comando ipa help commands y se ejecutará correctamente. El comando muestra una lista de comandos que están cubiertos por la ayuda de IPA, por ejemplo, user-add, ca-enable, server-show y muchos otros.
  • COMMAND- El COMMAND con mayúsculas significa variable, por lo tanto, puede utilizar el comando particular, por ejemplo, ipa help user-add

3.3. Uso de los temas de ayuda de IPA

El siguiente procedimiento le ayudará a entender el uso de la ayuda de IPA en la interfaz de línea de comandos.

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Introduzca ipa help topics para mostrar una lista de temas cubiertos por la ayuda.

    $ ipa help topics
  3. Seleccione uno de los temas y cree un comando de acuerdo con el siguiente patrón: ipa help [topic_name], en lugar de la cadena topic_name, añada uno de los temas que enumeró en el paso anterior.

    En el ejemplo, utilizamos el siguiente tema user

    $ ipa help user
  4. Si el comando de ayuda IPA es demasiado largo y no puede ver todo el texto, utilice la siguiente sintaxis:

    $ ipa help user | less

    A continuación, puede desplazarse hacia abajo y leer toda la ayuda.

La CLI de IPA muestra una página de ayuda para el tema user. Después de leer el resumen, puede ver muchos ejemplos con patrones para trabajar con los comandos del tema.

3.4. Uso de los comandos de ayuda de IPA

El siguiente procedimiento le ayudará a entender la creación de los comandos de ayuda de IPA en la interfaz de línea de comandos.

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Introduzca ipa help commands para mostrar una lista de comandos cubiertos por la ayuda.

    $ ipa help commands
  3. Seleccione uno de los comandos y cree un comando de ayuda según el siguiente patrón: ipa help <COMMAND>, en lugar de la cadena <COMMAND>, añada uno de los comandos que enumeró en el paso anterior.

    $ ipa help user-add

Recursos adicionales

  • Para más detalles, consulte la página man ipa.

3.5. Estructura de los comandos IPA

La CLI de IPA distingue los siguientes tipos de comandos:

  • Comandos incorporados: los comandos incorporados están disponibles en el servidor IdM.
  • Comandos proporcionados por el plug-in

La estructura de los comandos IPA permite gestionar varios tipos de objetos. Por ejemplo:

  • Usuarios,
  • Anfitriones,
  • Registros DNS,
  • Certificados,

y muchos otros.

Para la mayoría de estos objetos, la CLI de IPA incluye comandos para:

  • Añadir (add)
  • Modificar (mod)
  • Borrar (del)
  • Buscar (find)
  • Pantalla (show)

Los comandos tienen la siguiente estructura:

ipa user-add, ipa user-mod, ipa user-del, ipa user-find, ipa user-show

ipa host-add, ipa host-mod, ipa host-del, ipa host-find, ipa host-show

ipa dnsrecord-add, ipa dnsrecord-mod, ipa dnsrecord-del, ipa dnsrecord-find, ipa dnrecord-show

Puede crear un usuario con el comando ipa user-add [options], donde [options] es opcional. Si utiliza sólo el comando ipa user-add, el script le pide los detalles uno por uno.

Para modificar un objeto existente, es necesario definir el objeto, por lo que el comando incluye también el objeto: ipa user-mod USER_NAME [options].

3.6. Uso de un comando IPA para añadir una cuenta de usuario a IdM

A continuación se describe la adición de un nuevo usuario a la base de datos de gestión de identidades (IdM) mediante la línea de comandos.

Requisitos previos

  • Es necesario tener privilegios de administrador para añadir cuentas de usuario al servidor IdM.

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Introduzca el comando para añadir un nuevo usuario:

    $ ipa user-add

    El comando ejecuta un script donde se pueden añadir los datos básicos necesarios para crear una cuenta de usuario.

  3. En el campo First name:, introduzca el nombre del nuevo usuario y pulse la tecla Enter.
  4. En el campo Last name:, introduzca el apellido del nuevo usuario y pulse la tecla Enter.
  5. En User login [suggested user name]: introduzca el nombre de usuario o simplemente pulse la tecla Enter si el nombre de usuario sugerido le sirve.

    El nombre de usuario debe ser único para toda la base de datos IdM. Si se produce un error que indica que el usuario ya existe, hay que empezar desde el principio con el comando ipa user-add y probar con otro nombre de usuario.

Después de añadir con éxito el nombre de usuario, la cuenta de usuario se ha añadido a la base de datos de IdM y la interfaz de línea de comandos (CLI) de IPA imprime en la salida el siguiente registro:

----------------------
Added user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Full name: Example User
Display name: Example User
Initials: EU
Home directory: /home/euser
GECOS: Example User
Login shell: /bin/sh
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: False
Member of groups: ipausers
Kerberos keys available: False

Como puede ver, no se ha establecido una contraseña para la cuenta de usuario. Si desea añadir también la contraseña, utilice el comando ipa user-add con la siguiente sintaxis:

$ ipa user-add --first=Example --last=User --password

La IPA CLI le pide entonces que añada o confirme un nombre de usuario y una contraseña.

Si el usuario ya ha sido creado, puede añadir sólo la contraseña con el comando `ipa user-mod`.

Recursos adicionales

Para obtener más información sobre los parámetros, introduzca el siguiente comando de ayuda en la línea de comandos:

$ ipa help user-add

3.7. Uso de un comando IPA para modificar una cuenta de usuario en IdM

Puede cambiar muchos parámetros para cada cuenta de usuario. Por ejemplo, puede añadir una nueva contraseña al usuario.

La sintaxis de los comandos básicos es diferente de la sintaxis de user-add, ya que es necesario definir la cuenta de usuario existente para la que se desea realizar cambios, por ejemplo, añadir una contraseña.

Requisitos previos

  • Es necesario tener privilegios de administrador para modificar las cuentas de usuario en el servidor IdM.

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Introduzca el comando para añadir una contraseña:

    $ ipa user-mod euser --password

    El comando ejecuta un script en el que se puede añadir la nueva contraseña.

  3. Introduzca la nueva contraseña y pulse la tecla Enter.

Después de que usted agregó exitosamente el nombre de usuario, la cuenta de usuario ha sido agregada a la base de datos de IdM y el CLI de IPA imprime en la salida el siguiente registro:

----------------------
Modified user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Home directory: /home/euser
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: True
Member of groups: ipausers
Kerberos keys available: True

La contraseña del usuario está ahora establecida para la cuenta y el usuario puede iniciar sesión en IdM.

Recursos adicionales

Para obtener más información sobre los parámetros, introduzca el siguiente comando de ayuda en la línea de comandos:

$ ipa help user-mod

3.8. Cómo suministrar una lista de valores a las utilidades de IdM

La gestión de identidades (IdM) almacena los valores de los atributos multivaluados en listas.

IdM admite los siguientes métodos de suministro de listas multivaluadas:

  • Utilizar el mismo argumento de línea de comandos varias veces dentro de la misma invocación de comandos:

    $ ipa permission-add --right=read --permissions=write --permissions=delete ...
  • Alternativamente, puede encerrar la lista entre llaves, en cuyo caso el shell realiza la expansión:

    $ ipa permission-add --right={read,write,delete} ...

Los ejemplos anteriores muestran un comando permission-add que añade permisos a un objeto. El objeto no se menciona en el ejemplo. En lugar de …​ debe añadir el objeto para el que desea añadir permisos.

Cuando se actualizan estos atributos multivaluados desde la línea de comandos, IdM sobrescribe completamente la lista anterior de valores con una nueva lista. Por lo tanto, cuando se actualiza un atributo multivaluado, se debe especificar toda la nueva lista, no sólo un único valor que se desee añadir.

En el comando anterior, la lista de permisos incluye lectura, escritura y eliminación. Cuando decida actualizar la lista con el comando permission-mod debe añadir todos los valores, de lo contrario se borrarán los que no se mencionan.

Example 1:- El comando ipa permission-mod actualiza todos los permisos añadidos previamente.

$ ipa permission-mod --right=read --right=write --right=delete ...

o

$ ipa permission-mod --right={read,write,delete} ...

Example 2- El comando ipa permission-mod borra el argumento --right=delete porque no está incluido en el comando:

$ ipa permission-mod --right=read --right=write ...

o

$ ipa permission-mod --right={read,write} ...

3.9. Cómo utilizar los caracteres especiales con las utilidades del IdM

Cuando pase argumentos de la línea de comandos que incluyan caracteres especiales a los comandos de ipa, escape estos caracteres con una barra invertida (\). Por ejemplo, los caracteres especiales más comunes son los paréntesis angulares (< y >), el ampersand (&), el asterisco (*) o la barra vertical (|).

Por ejemplo, para escapar de un asterisco (*):

$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg

Los comandos que contienen caracteres especiales sin esconder no funcionan como se espera porque el shell no puede analizar correctamente dichos caracteres.

Capítulo 4. Búsqueda de entradas de Gestión de Identidades desde la línea de comandos

Las siguientes secciones describen cómo utilizar los comandos IPA, que le ayudan a encontrar o mostrar objetos.

4.1. Resumen de la lista de entradas de IdM

En esta sección se describen los comandos de ipa *-find, que pueden ayudarle a buscar un tipo concreto de entradas de IdM.

Para listar todos los comandos de find, utilice el siguiente comando de ayuda ipa:

$ ipa help commands | grep find

Es posible que tenga que comprobar si un usuario concreto está incluido en la base de datos de IdM. Para ello, puede listar todos los usuarios con el siguiente comando:

$ ipa user-find

Para listar los grupos de usuarios cuyos atributos especificados contienen una palabra clave:

$ ipa group-find keyword

Por ejemplo, el comando ipa group-find admin lista todos los grupos cuyos nombres o descripciones incluyen la cadena admin:

----------------
3 groups matched
----------------
   Group name: admins
   Description: Account administrators group
   GID: 427200002

   Group name: editors
   Description: Limited admins who can edit other users
   GID: 427200002

   Group name: trust admins
   Description: Trusts administrators group

Al buscar grupos de usuarios, también puede limitar los resultados de la búsqueda a los grupos que contengan un usuario concreto:

$ ipa group-find --user=user_name

Para buscar grupos que no contengan un determinado usuario:

$ ipa group-find --no-user=user_name

4.2. Mostrar detalles de una entrada en particular

Utilice el comando ipa *-show para mostrar los detalles de una entrada IdM concreta.

Procedimiento

  • Para mostrar detalles sobre un host llamado server.example.com:

    $ ipa host-show server.example.com
    
    Host name: server.example.com
    Principal name: host/server.example.com@EXAMPLE.COM
    ...

4.3. Ajustar el tamaño de la búsqueda y el límite de tiempo

Algunas consultas, como la solicitud de una lista de usuarios de IdM, pueden devolver un número muy elevado de entradas. Si se ajustan estas operaciones de búsqueda, se puede mejorar el rendimiento general del servidor al ejecutar los comandos de ipa *-find, como ipa user-find, y al mostrar las listas correspondientes en la interfaz web.

Límite de tamaño de la búsqueda

Define el número máximo de entradas devueltas para una solicitud enviada al servidor desde la CLI de un cliente o desde un navegador que accede a la interfaz web de IdM.

Por defecto: 100 entradas.

Límite de tiempo de búsqueda

Define el tiempo máximo (en segundos) que el servidor espera para realizar las búsquedas. Una vez que la búsqueda alcanza este límite, el servidor detiene la búsqueda y devuelve las entradas descubiertas en ese tiempo.

Por defecto: 2 segundos.

Si estableces los valores en -1, IdM no aplicará ningún límite al buscar.

Importante

Establecer límites de tamaño o tiempo de búsqueda demasiado altos puede afectar negativamente al rendimiento del servidor.

4.3.1. Ajustar el tamaño de la búsqueda y el límite de tiempo en la línea de comandos

El siguiente texto describe el ajuste de los límites de tamaño y tiempo de búsqueda en la línea de comandos:

  • A nivel mundial
  • Para una entrada específica

Procedimiento

  1. Para mostrar el tiempo de búsqueda actual y los límites de tamaño en la CLI, utilice el comando ipa config-show:

    $ ipa config-show
    
    Search time limit: 2
    Search size limit: 100
  2. Para ajustar los límites globalmente para todas las consultas, utilice el comando ipa config-mod y añada las opciones --searchrecordslimit y --searchtimelimit. Por ejemplo:

    $ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
  3. Para ajustar los límites sólo para una consulta específica, añada las opciones --sizelimit o --timelimit al comando. Por ejemplo:
$ ipa user-find --sizelimit=200 --timelimit=120

4.3.2. Ajustar el tamaño y el límite de tiempo de la búsqueda en la interfaz web

El siguiente texto describe el ajuste de los límites de tamaño y tiempo de la búsqueda en la interfaz web de IdM:

  • A nivel mundial
  • Para una entrada específica

Procedimiento

Para ajustar los límites globalmente para todas las consultas:

  1. Inicie sesión en la interfaz web de IdM.
  2. Haga clic en IPA Server.

    web ui ipaserver

  3. En la pestaña IPA Server, haga clic en Configuration.
  4. Establezca los valores necesarios en el área Search Options.

    Los valores por defecto son:

    • Límite de tamaño de la búsqueda: 100 entradas
    • Límite de tiempo de búsqueda: 2 segundos
  5. Haga clic en Save en la parte superior de la página.

    límites de búsqueda en la web ui

Después de guardar los valores, busque una entrada y verifique el resultado.

Capítulo 5. Acceso a la interfaz web de IdM en un navegador web

Las siguientes secciones ofrecen una visión general de la interfaz web de IdM (Gestión de identidades) y describen cómo acceder a ella.

5.1. ¿Qué es la interfaz web de IdM?

La interfaz web de IdM (Identity Management) es una aplicación web para la administración de IdM, una alternativa gráfica a las herramientas de línea de comandos de IdM.

Puedes acceder a la interfaz web de IdM como:

  • IdM users: Un conjunto limitado de operaciones en función de los permisos concedidos al usuario en el servidor IdM. Básicamente, los usuarios activos de IdM pueden iniciar sesión en el servidor IdM y configurar su propia cuenta. No pueden cambiar la configuración de otros usuarios ni la del servidor IdM.
  • Administrators: Derechos de acceso total al servidor IdM.
  • Active Directory users: Un conjunto de operaciones en función de los permisos concedidos al usuario. Los usuarios de Active Directory ya pueden ser administradores de la Gestión de Identidades. Para obtener más detalles, consulte Habilitación de los usuarios de AD para administrar IdM.

5.2. Navegadores web compatibles con el acceso a la interfaz web

IdM (Identity Management) admite los siguientes navegadores para conectarse a la interfaz web:

  • Mozilla Firefox 38 y posteriores
  • Google Chrome 46 y posteriores

5.3. Acceso a la interfaz web

El siguiente procedimiento describe el primer inicio de sesión en la interfaz web de IdM (Identity Management) con una contraseña.

Después del primer inicio de sesión, puedes configurar tu servidor IdM para autenticarte con él:

Procedimiento

  1. Escriba una URL del servidor IdM en la barra de direcciones del navegador. El nombre será similar al siguiente ejemplo:

    https://server.example.com

    Sólo tienes que cambiar server.example.com con un nombre DNS de tu servidor IdM.

    Esto abre la pantalla de inicio de sesión de IdM Web UI en su navegador.

    pantalla de acceso a la web ui

    • Si el servidor no responde o la pantalla de inicio de sesión no se abre, comprueba la configuración de DNS del servidor IdM al que te estás conectando.
    • Si utiliza un certificado autofirmado, el navegador emite una advertencia. Compruebe el certificado y acepte la excepción de seguridad para proceder al inicio de sesión.

      Para evitar excepciones de seguridad, instale un certificado firmado por una autoridad de certificación.

  2. En la pantalla de inicio de sesión de la interfaz web, introduzca las credenciales de la cuenta de administrador que añadió durante la instalación del servidor IdM.

    Para más detalles, consulte Instalación de un servidor de gestión de identidades: Con DNS integrado, con una CA integrada.

    También puede introducir las credenciales de su cuenta personal si ya están introducidas en el servidor IdM.

    web ui login passwd

  3. Haga clic en Iniciar sesión.

Después de iniciar la sesión con éxito, puede empezar a configurar el servidor IdM.

usuarios de la web ui

Capítulo 6. Inicio de sesión en IdM en la interfaz web: Uso de un ticket Kerberos

Las siguientes secciones describen la configuración inicial de su entorno para permitir el inicio de sesión de Kerberos en la interfaz web de IdM y el acceso a IdM mediante la autenticación de Kerberos.

Requisitos previos

6.1. Autenticación Kerberos en la gestión de identidades

La Gestión de Identidades (IdM) utiliza el protocolo Kerberos para soportar el inicio de sesión único. La autenticación de inicio de sesión único le permite proporcionar el nombre de usuario y la contraseña correctos una sola vez, y luego puede acceder a los servicios de gestión de identidades sin que el sistema le pida las credenciales de nuevo.

El servidor de IdM proporciona la autenticación Kerberos inmediatamente después de la instalación si los ajustes de DNS y de certificado se han configurado correctamente. Para obtener más detalles, consulte Instalación de Identity Management.

Para utilizar la autenticación Kerberos en los hosts, instale:

6.2. Utilizando kinit para iniciar sesión en IdM manualmente

Este procedimiento describe el uso de la utilidad kinit para autenticarse en un entorno de gestión de identidades (IdM) de forma manual. La utilidad kinit obtiene y almacena en caché un ticket Kerberos (TGT) en nombre de un usuario IdM.

Nota

Utilice este procedimiento sólo si ha destruido su TGT inicial de Kerberos o si ha caducado. Como usuario de IdM, al iniciar la sesión en su máquina local también está iniciando automáticamente la sesión en IdM. Esto significa que, después de iniciar la sesión, no es necesario utilizar la utilidad kinit para acceder a los recursos de IdM.

Procedimiento

  1. Para conectarse a IdM

    • bajo el nombre de usuario del usuario que ha iniciado la sesión en el sistema local, utilice kinit sin especificar un nombre de usuario. Por ejemplo, si está conectado como example_user en el sistema local:

      [example_user@server ~]$ kinit
      Password for example_user@EXAMPLE.COM:
      [example_user@server ~]$

      Si el nombre de usuario del usuario local no coincide con ninguna entrada de usuario en IdM, el intento de autenticación falla:

      [example_user@server ~]$ kinit
      kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    • utilizando una entidad de seguridad Kerberos que no se corresponde con su nombre de usuario local, pase el nombre de usuario requerido a la utilidad kinit. Por ejemplo, para iniciar sesión como el usuario admin:

      [example_user@server ~]$ kinit admin
      Password for admin@EXAMPLE.COM:
      [example_user@server ~]$
  2. Opcionalmente, para verificar que el inicio de sesión fue exitoso, utilice la utilidad klist para mostrar el TGT en caché. En el siguiente ejemplo, la caché contiene un ticket para la entidad de seguridad example_user, lo que significa que en este host concreto, sólo example_user puede acceder actualmente a los servicios de IdM:

    $ klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: example_user@EXAMPLE.COM
    
    Valid starting     	Expires            	Service principal
    11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

6.3. Configurar el navegador para la autenticación Kerberos

Para habilitar la autenticación con un ticket Kerberos, es posible que necesite una configuración del navegador.

Los siguientes pasos le ayudarán a soportar la negociación de Kerberos para acceder al dominio IdM.

Cada navegador soporta Kerberos de forma diferente y necesita una configuración distinta. La interfaz web de IdM incluye directrices para los siguientes navegadores:

  • Firefox
  • Cromo

Procedimiento

  1. Abra el cuadro de diálogo de inicio de sesión de IdM Web UI en su navegador web.
  2. Haga clic en el enlace para la configuración del navegador en la pantalla de inicio de sesión de la interfaz web.

    enlace de configuración del navegador ipa

  3. Siga los pasos de la página de configuración.

    página de configuración del navegador ipa

Después de la configuración, vuelva a la interfaz web de IdM y haga clic en Log in.

6.4. Inicio de sesión en la interfaz web mediante un ticket Kerberos

Este procedimiento describe el inicio de sesión en la interfaz web de IdM mediante un ticket de concesión de tickets (TGT) de Kerberos.

El TGT caduca a una hora predefinida. El intervalo de tiempo predeterminado es de 24 horas y se puede cambiar en la interfaz web de IdM.

Una vez transcurrido el intervalo de tiempo, deberá renovar el billete:

  • Utilizando el comando kinit.
  • Uso de las credenciales de inicio de sesión de IdM en el diálogo de inicio de sesión de la interfaz web.

Procedimiento

  • Abra la interfaz web de IdM.

    Si la autenticación Kerberos funciona correctamente y tiene un ticket válido, se autenticará automáticamente y se abrirá la interfaz web.

    Si el ticket está caducado, es necesario autenticarse primero con las credenciales. Sin embargo, la próxima vez la interfaz web de IdM se abrirá automáticamente sin abrir el diálogo de inicio de sesión.

    Si ve un mensaje de error Authentication with Kerberos failed, verifique que su navegador está configurado para la autenticación Kerberos. Consulte Sección 6.3, “Configurar el navegador para la autenticación Kerberos”.

    firefox kerb auth failed

6.5. Configuración de un sistema externo para la autenticación Kerberos

Esta sección describe cómo configurar un sistema externo para que los usuarios de Identity Management (IdM) puedan iniciar sesión en IdM desde el sistema externo utilizando sus credenciales de Kerberos.

Habilitar la autenticación Kerberos en sistemas externos es especialmente útil cuando su infraestructura incluye varios reinos o dominios superpuestos. También es útil si el sistema no se ha inscrito en ningún dominio de IdM a través de ipa-client-install.

Para habilitar la autenticación Kerberos en IdM desde un sistema que no es miembro del dominio IdM, defina un archivo de configuración Kerberos específico para IdM en el sistema externo.

Requisitos previos

  • El paquete krb5-workstation está instalado en el sistema externo.

    Para saber si el paquete está instalado, utilice el siguiente comando de la CLI:

    # yum list installed krb5-workstation
    Installed Packages
    krb5-workstation.x86_64    1.16.1-19.el8     @BaseOS

Procedimiento

  1. Copie el archivo /etc/krb5.conf del servidor IdM al sistema externo. Por ejemplo:

    # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
    Aviso

    No sobrescriba el archivo krb5.conf existente en el sistema externo.

  2. En el sistema externo, configure la sesión de terminal para que utilice el archivo de configuración IdM Kerberos copiado:

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

    La variable KRB5_CONFIG sólo existe temporalmente hasta que se cierra la sesión. Para evitar esta pérdida, exporte la variable con un nombre de archivo diferente.

  3. Copie los fragmentos de configuración de Kerberos del directorio /etc/krb5.conf.d/ al sistema externo.
  4. Configure el navegador en el sistema externo, como se describe en Sección 6.3, “Configurar el navegador para la autenticación Kerberos”.

Los usuarios del sistema externo ya pueden utilizar la utilidad kinit para autenticarse en el servidor IdM.

6.6. Inicio de sesión en la interfaz web para usuarios de Active Directory

Para habilitar el inicio de sesión de la interfaz web para los usuarios de Active Directory, defina una anulación de ID para cada usuario de Active Directory en la vista de confianza predeterminada. Por ejemplo:

[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com

Capítulo 7. Inicio de sesión en la interfaz web de gestión de identidades mediante contraseñas de un solo uso

El acceso a la interfaz web de IdM puede asegurarse mediante varios métodos. El básico es la autenticación por contraseña.

Para aumentar la seguridad de la autenticación con contraseña, se puede añadir un segundo paso y exigir contraseñas de un solo uso (OTP) generadas automáticamente. El uso más común es combinar la contraseña conectada con la cuenta de usuario y una contraseña de un solo uso limitada en el tiempo y generada por un token de hardware o software.

Las siguientes secciones le ayudarán a:

  • Entender cómo funciona la autenticación OTP en IdM.
  • Configure la autenticación OTP en el servidor IdM.
  • Crea tokens OTP y sincronízalos con la aplicación FreeOTP en tu teléfono.
  • Autenticarse en la interfaz web de IdM con la combinación de la contraseña de usuario y la contraseña de un solo uso.
  • Vuelva a sincronizar los tokens en la interfaz web.

7.1. Requisitos previos

7.2. Autenticación por contraseña de un solo uso (OTP) en la gestión de identidades

Las contraseñas de un solo uso aportan un paso adicional a la seguridad de su autenticación. La autenticación utiliza su contraseña una contraseña de un solo uso generada automáticamente.

Para generar contraseñas de un solo uso, se puede utilizar un token de hardware o de software. IdM admite tanto tokens de software como de hardware.

La gestión de identidades admite los siguientes dos mecanismos estándar de OTP:

  • El algoritmo HMAC-Based One-Time Password (HOTP) se basa en un contador. HMAC son las siglas de Hashed Message Authentication Code.
  • El algoritmo Time-Based One-Time Password (TOTP) es una extensión de HOTP para soportar el factor móvil basado en el tiempo.
Importante

IdM no admite inicios de sesión OTP para usuarios de confianza de Active Directory.

7.3. Activación de la contraseña única en la interfaz web

La interfaz web de IdM permite configurar el dispositivo de hardware o software para generar contraseñas de un solo uso.

La contraseña única se introduce justo después de la contraseña habitual en el campo dedicado en el diálogo de inicio de sesión.

Sólo los administradores pueden habilitar la autenticación OTP en la configuración del usuario.

Requisitos previos

  • Privilegios de la administración

Procedimiento

  1. Inicie sesión en la interfaz web de IdM con su nombre de usuario y contraseña.
  2. Abra la pestaña Identity → Users → Active users.

    usuarios de la web ui

  3. Haga clic en su nombre de usuario para abrir la configuración del mismo.
  4. En la página User authentication types, seleccione Two factor authentication (password OTP).
  5. Haga clic en Save.

En este punto, la autenticación OTP está habilitada en el servidor IdM.

Ahora usted o los propios usuarios deben asignar un nuevo ID de token a la cuenta de usuario.

7.4. Añadir tokens OTP en la interfaz web

La siguiente sección le ayuda a añadir tokens a la interfaz web de IdM y a su generador de tokens de software.

Requisitos previos

  • Cuenta de usuario activa en el servidor IdM.
  • El administrador ha habilitado la OTP para la cuenta de usuario concreta en la interfaz web de IdM.
  • Un dispositivo de software que genera tokens OTP, por ejemplo FreeOTP.

Procedimiento

  1. Inicie sesión en la interfaz web de IdM con su nombre de usuario y contraseña.
  2. Para crear el token en su teléfono móvil, abra la pestaña Authentication → OTP Tokens.
  3. Haga clic en Add.

    ficha de tokens de la web ui

  4. En el cuadro de diálogo Add OTP token, deje todo sin rellenar y haga clic en Add.

    En esta etapa, el servidor de IdM crea un token con parámetros predeterminados en el servidor y abre una página con un código QR.

  5. Copie el código QR en su teléfono móvil.
  6. Haga clic en OK para cerrar el código QR.

Ahora puedes generar contraseñas de un solo uso e iniciar sesión con ellas en la interfaz web de IdM.

token freeotp

7.5. Acceder a la interfaz web con una contraseña única

Este procedimiento describe el primer inicio de sesión en la interfaz web de IdM utilizando una contraseña de un solo uso (OTP).

Requisitos previos

  • Configuración de OTP habilitada en el servidor de gestión de identidades para la cuenta de usuario que está utilizando para la autenticación OTP. Tanto los administradores como los propios usuarios pueden habilitar la OTP.

    Para activar la configuración OTP, véase Sección 7.3, “Activación de la contraseña única en la interfaz web”

  • Un dispositivo de hardware o software que genera tokens OTP configurados.

Procedimiento

  1. En la pantalla de inicio de sesión de Gestión de identidades, introduzca su nombre de usuario o un nombre de usuario de la cuenta de administrador del servidor IdM.
  2. Añada la contraseña para el nombre de usuario introducido anteriormente.
  3. Genere una contraseña única en su dispositivo.
  4. Introduzca la contraseña única justo después de la contraseña (sin espacio).
  5. Haga clic en Log in.

    Si la autenticación falla, sincronice los tokens OTP.

    Si su CA utiliza un certificado autofirmado, el navegador emite una advertencia. Compruebe el certificado y acepte la excepción de seguridad para proceder al inicio de sesión.

    Si la interfaz web de IdM no se abre, verifique la configuración de DNS de su servidor de gestión de identidades.

Una vez iniciada la sesión con éxito, aparece la interfaz web de IdM.

usuarios de la web ui

7.6. Sincronización de tokens OTP mediante la interfaz web

Si el inicio de sesión con OTP (One Time Password) falla, los tokens OTP no se sincronizan correctamente.

El siguiente texto describe la resincronización de fichas.

Requisitos previos

  • Se abrió una pantalla de inicio de sesión.
  • Un dispositivo generador de tokens OTP configurado.

Procedimiento

  1. En la pantalla de inicio de sesión de IdM Web UI, haga clic en Sync OTP Token.

    web ui login otp link

  2. En la pantalla de inicio de sesión, introduzca su nombre de usuario y la contraseña de Gestión de Identidades.
  3. Genere una contraseña única e introdúzcala en el campo First OTP.
  4. Genere otra contraseña única e introdúzcala en el campo Second OTP.
  5. Opcionalmente, introduzca el ID del token.

    web ui login otp configuración

  6. Haga clic en Sync OTP Token.

Una vez realizada la sincronización con éxito, puede iniciar sesión en el servidor IdM.

7.7. Cambiar las contraseñas caducadas

Los administradores de la Gestión de Identidades pueden obligarle a cambiar su contraseña en el siguiente inicio de sesión. Esto significa que no podrá iniciar sesión con éxito en la interfaz web de IdM hasta que cambie la contraseña.

La caducidad de la contraseña puede producirse durante el primer acceso a la interfaz web.

Si aparece el diálogo de caducidad de la contraseña, siga las instrucciones del procedimiento.

Requisitos previos

  • Se abrió una pantalla de inicio de sesión.
  • Cuenta activa en el servidor IdM.

Procedimiento

  1. En la pantalla de inicio de sesión de caducidad de la contraseña, introduzca el nombre de usuario.
  2. Añada la contraseña para el nombre de usuario introducido anteriormente.
  3. En el campo OTP, genere una contraseña de un solo uso, si utiliza la autenticación de contraseña de un solo uso.

    Si no tiene activada la autenticación OTP, deje el campo vacío.

  4. Introduzca la nueva contraseña dos veces para verificarla.
  5. Haga clic en Reset Password.

    web ui passwd expiración

Después de cambiar la contraseña con éxito, aparece el diálogo de inicio de sesión habitual. Inicie la sesión con la nueva contraseña.

Capítulo 8. Configuración de los ajustes globales de IdM mediante los playbooks de Ansible

Con el módulo de Ansible config, puede recuperar y establecer parámetros de configuración global para la gestión de identidades (IdM).

Este capítulo incluye las siguientes secciones:

8.1. Recuperación de la configuración de IdM mediante un playbook de Ansible

El siguiente procedimiento describe cómo se puede utilizar un playbook de Ansible para recuperar información sobre la configuración global actual de IdM.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina el servidor de IdM del que desea recuperar la configuración de IdM en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que recupere los datos de server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  2. Abra el archivo /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml Ansible playbook para editarlo:

    ---
    - name: Playbook to handle global IdM configuration
      hosts: ipaserver
      become: no
      gather_facts: no
    
      tasks:
      - name: Query IPA global configuration
        ipaconfig:
          ipaadmin_password: Secret123
        register: serverconfig
    
      - debug:
          msg: "{{ serverconfig }}"
  3. Adapte el archivo cambiando lo siguiente:

    • La contraseña del administrador de IdM.
    • Otros valores, si es necesario.
  4. Guarda el archivo.
  5. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml
    [...]
    TASK [debug]
    ok: [server.idm.example.com] => {
        "msg": {
            "ansible_facts": {
                "discovered_interpreter_
            },
            "changed": false,
            "config": {
                "ca_renewal_master_server": "server.idm.example.com",
                "configstring": [
                    "AllowNThash",
                    "KDC:Disable Last Success"
                ],
                "defaultgroup": "ipausers",
                "defaultshell": "/bin/bash",
                "emaildomain": "idm.example.com",
                "enable_migration": false,
                "groupsearch": [
                    "cn",
                    "description"
                ],
                "homedirectory": "/home",
                "maxhostname": "64",
                "maxusername": "64",
                "pac_type": [
                    "MS-PAC",
                    "nfs:NONE"
                ],
                "pwdexpnotify": "4",
                "searchrecordslimit": "100",
                "searchtimelimit": "2",
                "selinuxusermapdefault": "unconfined_u:s0-s0:c0.c1023",
                "selinuxusermaporder": [
                    "guest_u:s0$xguest_u:s0$user_
                ],
                "usersearch": [
                    "uid",
                    "givenname",
                    "sn",
                    "telephonenumber",
                    "ou",
                    "title"
                ]
            },
            "failed": false
        }
    }

8.2. Configuración del servidor maestro de renovación de CA de IdM mediante un libro de jugadas de Ansible

En un despliegue de gestión de identidades (IdM) que utiliza una autoridad de certificación (CA) integrada, el servidor maestro de renovación de CA mantiene y renueva los certificados del sistema IdM. Garantiza que los despliegues de IdM no se interrumpan.

Para obtener más detalles sobre la función del maestro de renovación de CA de IdM, consulte Uso del maestro de renovación de CA de IdM.

El siguiente procedimiento describe cómo puede utilizar un libro de jugadas de Ansible para configurar el servidor maestro de renovación de CA de IdM.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.

Procedimiento

  1. Opcional: Identificar el maestro de renovación de la CA de IdM actual:

    $ ipa config-show | grep 'CA renewal master'
      IPA CA renewal master: server.idm.example.com
  2. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  3. Abra el archivo /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml Ansible playbook para editarlo:

    ---
    - name: Playbook to handle global DNS configuration
      hosts: ipaserver
      become: no
      gather_facts: no
    
      tasks:
      - name: set ca_renewal_master_server
        ipaconfig:
          ipaadmin_password: SomeADMINpassword
          ca_renewal_master_server: carenewal.idm.example.com
  4. Adapte el archivo cambiando:

    • La contraseña del administrador de IdM establecida por la variable ipaadmin_password.
    • El nombre del servidor CA maestro establecido por la variable ca_renewal_master_server.
  5. Guarda el archivo.
  6. Ejecute el playbook de Ansible. Especifique el archivo del libro de jugadas y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml

Pasos de verificación

Puede verificar que el maestro de renovación de la CA ha sido cambiado:

  1. Inicie sesión en ipaserver como administrador de IdM:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicita la identidad del servidor CA maestro de IdM:

    $ ipa config-show | grep ‘CA renewal master’
    IPA CA renewal master:  carenewal.idm.example.com

    La salida muestra que el servidor carenewal.idm.example.com es el nuevo maestro de renovación de CA.

8.3. Configurar el shell por defecto para los usuarios de IdM utilizando un playbook de Ansible

El shell es un programa que acepta e interpreta comandos. Hay varios shells disponibles en Red Hat Enterprise Linux (RHEL), como bash, sh, ksh, zsh, fish, y otros. Bash, o /bin/bash, es un shell popular en la mayoría de los sistemas Linux, y normalmente es el shell por defecto para las cuentas de usuario en RHEL.

El siguiente procedimiento describe cómo se puede utilizar un playbook de Ansible para configurar sh, un shell alternativo, como el shell por defecto para los usuarios de IdM.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.

Procedimiento

  1. Opcional: Utilice el libro de jugadas de Ansible retrieve-config.yml para identificar el shell actual para los usuarios de IdM. Consulte Recuperación de la configuración de IdM mediante un libro de jugadas de Ansible para obtener más detalles.
  2. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  3. Abra el archivo /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml Ansible playbook para editarlo:

    ---
    - name: Playbook to ensure some config options are set
      hosts: ipaserver
      become: true
    
      tasks:
      # Set defaultlogin and maxusername
      - ipaconfig:
          ipaadmin_password: Secret123
          defaultshell: /bin/bash
          maxusername: 64
  4. Adapte el archivo cambiando lo siguiente:

    • La contraseña del administrador de IdM establecida por la variable ipaadmin_password.
    • El shell por defecto de los usuarios de IdM establecido por la variable defaultshell en /bin/sh.
  5. Guarda el archivo.
  6. Ejecute el playbook de Ansible. Especifique el archivo del libro de jugadas y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml

Pasos de verificación

Puedes comprobar que el shell de usuario por defecto se ha cambiado iniciando una nueva sesión en IdM:

  1. Inicie sesión en ipaserver como administrador de IdM:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Muestra el shell actual:

    [admin@server /]$ echo "$SHELL"
    /bin/sh

    El usuario conectado está utilizando el shell sh.

Recursos adicionales

  • Puedes ver ejemplos de playbooks de Ansible para configurar los ajustes globales de IdM y una lista de posibles variables en el archivo README-config.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/.
  • Puedes ver ejemplos de playbooks de Ansible para varias operaciones relacionadas con la configuración de IdM en el directorio /usr/share/doc/ansible-freeipa/playbooks/config.

Capítulo 9. Gestión de cuentas de usuario mediante la línea de comandos

Este capítulo incluye una descripción básica del ciclo de vida del usuario en IdM (Identity Management). Las siguientes secciones le muestran cómo:

  • Crear cuentas de usuario
  • Activar las cuentas de usuario de la etapa
  • Conservar las cuentas de usuario
  • Eliminar las cuentas de usuario activas, de etapa o conservadas
  • Restaurar las cuentas de usuario conservadas

9.1. Ciclo de vida del usuario

IdM (Identity Management) admite tres estados de cuenta de usuario:

  • Stage los usuarios no pueden autenticarse. Este es un estado inicial. Algunas de las propiedades de la cuenta de usuario requeridas para los usuarios activos no pueden establecerse, por ejemplo, la pertenencia a un grupo.
  • Active los usuarios pueden autenticarse. Todas las propiedades requeridas de la cuenta de usuario deben ser establecidas en este estado.
  • Preserved son antiguos usuarios activos que se consideran inactivos y no pueden autenticarse en el IdM. Los usuarios preservados conservan la mayoría de las propiedades de la cuenta que tenían como usuarios activos, pero no forman parte de ningún grupo de usuarios.

84 Ciclo de vida de RHEL IdM 0420

Puede eliminar las entradas de usuarios de forma permanente de la base de datos de IdM.

Importante

Las cuentas de usuario borradas no se pueden restaurar. Cuando se elimina una cuenta de usuario, toda la información asociada a la cuenta se pierde permanentemente.

Un nuevo administrador sólo puede ser creado por un usuario con derechos de administrador, como el usuario administrador por defecto. Si se eliminan accidentalmente todas las cuentas de administrador, el Administrador de directorios debe crear un nuevo administrador manualmente en el Servidor de directorios.

Aviso

No elimine el usuario admin. Como admin es un usuario predefinido requerido por IdM, esta operación causa problemas con ciertos comandos. Si desea definir y utilizar un usuario administrador alternativo, desactive el usuario predefinido admin con ipa user-disable admin después de haber concedido permisos de administrador al menos a un usuario diferente.

9.2. Añadir usuarios mediante la línea de comandos

Puedes añadir el usuario como:

  • Active- cuentas de usuario que pueden ser utilizadas activamente por sus usuarios.
  • Stage- los usuarios no pueden utilizar estas cuentas. Utilízalo si quieres preparar nuevas cuentas de usuario. Cuando los usuarios estén listos para usar sus cuentas, entonces puedes activarlos.

El siguiente procedimiento describe cómo añadir usuarios activos al servidor IdM con el comando ipa user-add.

Del mismo modo, puede crear cuentas de usuario de escenario con el comando ipa stageuser-add.

Nota

IdM asigna automáticamente un ID de usuario único (UID) a las nuevas cuentas de usuario. También puede hacerlo manualmente, sin embargo, el servidor no valida si el número UID es único. Debido a esto, varias entradas de usuario podrían tener el mismo número de identificación asignado. Red Hat recomienda evitar tener múltiples entradas con el mismo UID.

Requisitos previos

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Añade el nombre de usuario, el nombre y el apellido del usuario y, opcionalmente, puedes añadir su dirección de correo electrónico.

    $ ipa user-add user_login --first=nombre --last=apellido --email=dirección de correo electrónico

    IdM admite nombres de usuario que pueden describirse mediante la siguiente expresión regular:

    [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
    Nota

    Los nombres de usuario que terminan con el signo de dólar ($) son compatibles con las máquinas Samba 3.x.

    Si añades un nombre de usuario que contiene caracteres en mayúsculas, IdM convierte automáticamente el nombre en minúsculas al guardarlo. Por lo tanto, IdM siempre requiere introducir los nombres de usuario en minúsculas al iniciar la sesión. Además, no es posible añadir nombres de usuario que sólo se diferencien en el tipo de letra, como user y User.

    La longitud máxima por defecto de los nombres de usuario es de 32 caracteres. Para cambiarlo, utilice el comando ipa config-mod --maxusername. Por ejemplo, para aumentar la longitud máxima del nombre de usuario a 64 caracteres:

    $ ipa config-mod --maxusername=64
     Maximum username length: 64
     ...

    El comando ipa user-add incluye muchos parámetros. Para enumerarlos todos, utilice el comando ipa help:

    $ ipa help user-add

    Para más detalles sobre el comando ipa help, consulte Qué es la ayuda IPA.

Puede verificar si la nueva cuenta de usuario se ha creado con éxito haciendo un listado de todas las cuentas de usuario de IdM:

$ ipa $ ipa user-find

Este comando lista todas las cuentas de usuario con detalles.

9.3. Activación de usuarios mediante la línea de comandos

Para activar una cuenta de usuario moviéndola de estado a activo, utilice el comando ipa stageuser-activate.

Requisitos previos

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Active la cuenta de usuario con el siguiente comando:

    $ ipa stageuser-activate user_login
    -------------------------
    Stage user user_login activated
    -------------------------
    ...

Puede verificar si la nueva cuenta de usuario se ha creado con éxito haciendo un listado de todas las cuentas de usuario de IdM:

$ ipa $ ipa user-find

Este comando lista todas las cuentas de usuario con detalles.

9.4. Conservación de los usuarios mediante la línea de comandos

Para conservar una cuenta de usuario, utilice los comandos ipa user-del o ipa stageuser-del.

Requisitos previos

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Conserve la cuenta de usuario con el siguiente comando:

    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------

9.5. Eliminación de usuarios mediante la línea de comandos

IdM (Identity Management) le permite eliminar usuarios de forma permanente. Se pueden eliminar:

  • Usuarios activos con el siguiente comando ipa user-del
  • Los usuarios del escenario con el siguiente comando ipa stageuser-del
  • Preserva a los usuarios con el siguiente comando ipa user-del

Al eliminar varios usuarios, utilice la opción --continue para forzar que el comando continúe independientemente de los errores. Un resumen de las operaciones exitosas y fallidas se imprime en el flujo de salida estándar stdout cuando el comando se completa.

$ ipa user-del --continue user1 user2 user3

Si no se utiliza --continue, el comando procede a eliminar usuarios hasta que encuentra un error, tras lo cual se detiene y sale.

Requisitos previos

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Elimine la cuenta de usuario con el siguiente comando:

    $ ipa user-del user_login
    --------------------
    Deleted user "user_login"
    --------------------

La cuenta de usuario ha sido eliminada definitivamente del IdM.

9.6. Restauración de usuarios mediante la línea de comandos

Se puede restaurar a los usuarios conservados:

  • Usuarios activos ipa user-undel
  • Usuarios del escenario ipa user-stage

La restauración de una cuenta de usuario no restaura todos los atributos anteriores de la cuenta. Por ejemplo, la contraseña del usuario no se restaura y debe establecerse de nuevo.

Requisitos previos

Procedimiento

  1. Abra el terminal y conéctese al servidor IdM.
  2. Active la cuenta de usuario con el siguiente comando:

    $ ipa user-undel user_login
    ------------------------------
    Undeleted user account "user_login"
    ------------------------------

    Como alternativa, puede restaurar las cuentas de los usuarios como si se tratara de una etapa:

    $ ipa user-stage user_login
    ------------------------------
    Staged user account "user_login"
    ------------------------------

Puede verificar si la nueva cuenta de usuario se ha creado con éxito haciendo un listado de todas las cuentas de usuario de IdM:

$ ipa $ ipa user-find

Este comando lista todas las cuentas de usuario con detalles.

Capítulo 10. Gestión de cuentas de usuario mediante la interfaz web de IdM

La gestión de identidades (IdM) ofrece varias etapas que pueden ayudarle a gestionar diversas situaciones de la vida laboral de los usuarios:

Crear una cuenta de usuario

Crear una cuenta de usuario por etapas antes de que un empleado comience su carrera en su empresa y estar preparado de antemano para el día en que el empleado aparezca en la oficina y quiera activar la cuenta.

Puede omitir este paso y crear la cuenta de usuario activa directamente. El procedimiento es similar a la creación de una cuenta de usuario de etapa.

Activar una cuenta de usuario
Activar la cuenta el primer día laborable del empleado.
Desactivar una cuenta de usuario
Si el usuario se va de baja por paternidad durante un par de meses, tendrá que desactivar la cuenta temporalmente.
Habilitar una cuenta de usuario
Cuando el usuario regrese, tendrá que volver a habilitar la cuenta.
Conservar una cuenta de usuario
Si el usuario quiere dejar la empresa, tendrá que eliminar la cuenta con la posibilidad de restaurarla porque la gente puede volver a la empresa después de algún tiempo.
Restaurar una cuenta de usuario
Dos años después, el usuario ha vuelto y hay que restaurar la cuenta conservada.
Eliminar una cuenta de usuario
Si el empleado es despedido, se eliminará la cuenta sin una copia de seguridad.

10.1. Ciclo de vida del usuario

IdM (Identity Management) admite tres estados de cuenta de usuario:

  • Stage los usuarios no pueden autenticarse. Este es un estado inicial. Algunas de las propiedades de la cuenta de usuario requeridas para los usuarios activos no pueden establecerse, por ejemplo, la pertenencia a un grupo.
  • Active los usuarios pueden autenticarse. Todas las propiedades requeridas de la cuenta de usuario deben ser establecidas en este estado.
  • Preserved son antiguos usuarios activos que se consideran inactivos y no pueden autenticarse en el IdM. Los usuarios preservados conservan la mayoría de las propiedades de la cuenta que tenían como usuarios activos, pero no forman parte de ningún grupo de usuarios.

84 Ciclo de vida de RHEL IdM 0420

Puede eliminar las entradas de usuarios de forma permanente de la base de datos de IdM.

Importante

Las cuentas de usuario borradas no se pueden restaurar. Cuando se elimina una cuenta de usuario, toda la información asociada a la cuenta se pierde permanentemente.

Un nuevo administrador sólo puede ser creado por un usuario con derechos de administrador, como el usuario administrador por defecto. Si se eliminan accidentalmente todas las cuentas de administrador, el Administrador de directorios debe crear un nuevo administrador manualmente en el Servidor de directorios.

Aviso

No elimine el usuario admin. Como admin es un usuario predefinido requerido por IdM, esta operación causa problemas con ciertos comandos. Si desea definir y utilizar un usuario administrador alternativo, desactive el usuario predefinido admin con ipa user-disable admin después de haber concedido permisos de administrador al menos a un usuario diferente.

10.2. Añadir usuarios en la interfaz web

Normalmente, es necesario crear una nueva cuenta de usuario antes de que un nuevo empleado comience a trabajar. Dicha cuenta de etapa no es accesible y hay que activarla más tarde.

Nota

También puede crear una cuenta de usuario activo directamente. Para añadir un usuario activo, siga el siguiente procedimiento y añada la cuenta de usuario en la pestaña Active users.

Requisitos previos

  • Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.

Procedimiento

  1. Inicie sesión en la interfaz web de IdM.

    Para obtener más información, consulte Acceso a la interfaz web de IdM en un navegador web.

  2. Vaya a la pestaña Users → Stage Users.

    Como alternativa, puede añadir la cuenta de usuario en Users → Active users, sin embargo, no puede añadir grupos de usuarios a la cuenta.

  3. Haga clic en el icono Add.
  4. En el cuadro de diálogo Add stage user, introduzca First name y Last name del nuevo usuario.
  5. Opcional] En el campo User login, añada un nombre de usuario.

    Si lo dejas vacío, el servidor IdM crea el nombre de usuario con el siguiente patrón: La primera letra del nombre y el apellido. El nombre de inicio de sesión completo puede tener hasta 32 caracteres.

  6. Opcional] En el menú desplegable GID, seleccione los grupos en los que debe incluirse el usuario.
  7. [Opcional] En los campos Password y Verify password,
  8. Haga clic en el botón Add.

    idm user add stage

En este punto, puede ver la cuenta de usuario en la tabla Stage Users.

etapa de usuarios de idm

Nota

Si hace clic en el nombre del usuario, puede editar la configuración avanzada, como añadir un número de teléfono, una dirección o una ocupación.

10.3. Activación de los usuarios de la etapa en la interfaz web de IdM

Una cuenta de usuario de escenario debe activarse antes de que el usuario pueda iniciar sesión en IdM y antes de que pueda añadirse a un grupo de IdM. Esta sección describe cómo activar las cuentas de usuario de escenario.

Requisitos previos

  • Privilegios de administrador para gestionar la interfaz web de IdM o el rol de administrador de usuarios.
  • Al menos una cuenta de usuario escalonada en IdM.

Procedimiento

  1. Inicie sesión en la interfaz web de IdM.

    Para obtener más información, consulte Acceso a la interfaz web de IdM en un navegador web.

  2. Vaya a la pestaña Users → Stage users.
  3. Haga clic en la casilla de la cuenta de usuario que desea activar.
  4. Haga clic en el botón Activate.

    etapa de usuarios de idm

  5. En el cuadro de diálogo Confirmation, haga clic en el botón OK.

Si la activación tiene éxito, la interfaz web de IdM muestra una confirmación verde de que el usuario ha sido activado y la cuenta de usuario se ha trasladado a Active users. La cuenta está activa y el usuario puede autenticarse en el dominio IdM y en la interfaz web IdM. En el primer inicio de sesión se pide al usuario que cambie su contraseña.

usuarios de idm etapa activada

Nota

En esta fase, puede añadir la cuenta de usuario activa a los grupos de usuarios.

10.4. Desactivación de las cuentas de usuario en la interfaz web

Puede desactivar las cuentas de usuario activas. Al desactivar una cuenta de usuario se desactiva la cuenta, por lo tanto, las cuentas de usuario no se pueden utilizar para autenticar y utilizar los servicios de IdM, como Kerberos, ni realizar ninguna tarea.

Las cuentas de usuario deshabilitadas siguen existiendo dentro de IdM y toda la información asociada permanece inalterada. A diferencia de las cuentas de usuario conservadas, las cuentas de usuario desactivadas permanecen en estado activo y pueden ser miembros de grupos de usuarios.

Nota

Después de desactivar una cuenta de usuario, cualquier conexión existente seguirá siendo válida hasta que el vale TGT de Kerberos del usuario y los demás vales caduquen. Una vez que el ticket caduque, el usuario no podrá renovarlo.

Requisitos previos

  • Privilegios de administrador para gestionar la interfaz web de IdM o el rol de administrador de usuarios.

Procedimiento

  1. Inicie sesión en la interfaz web de IdM.

    Para obtener más información, consulte Acceso a la interfaz web de IdM en un navegador web.

  2. Vaya a la pestaña Users → Active users.
  3. Haga clic en la casilla de las cuentas de usuario que desee desactivar.
  4. Haga clic en el botón Disable.

    los usuarios de idm se desactivan

  5. En el cuadro de diálogo Confirmation, haga clic en el botón OK.

Si el procedimiento de desactivación ha sido exitoso, puede verificarlo en la columna Estado de la tabla Active users.

usuarios de idm deshabilitados

10.5. Activación de las cuentas de usuario en la interfaz web

Con IdM se pueden habilitar las cuentas de usuario activas deshabilitadas. Al habilitar una cuenta de usuario se activa la cuenta deshabilitada.

Requisitos previos

  • Privilegios de administrador para gestionar la interfaz web de IdM o el rol de administrador de usuarios.

Procedimiento

  1. Inicie sesión en la interfaz web de IdM.
  2. Vaya a la pestaña Users → Active users.
  3. Haga clic en la casilla de las cuentas de usuario que desee habilitar.
  4. Haga clic en el botón Enable.

    los usuarios de idm se desactivan

  5. En el cuadro de diálogo Confirmation, haga clic en el botón OK.

Si el cambio se ha realizado con éxito, puede comprobarlo en la columna Estado de la tabla Active users.

10.6. Conservación de los usuarios activos en la interfaz web de IdM

La conservación de las cuentas de usuario le permite eliminar las cuentas de la ficha Active users, pero manteniendo estas cuentas en IdM.

Conserve la cuenta de usuario si el empleado deja la empresa. Si desea desactivar las cuentas de usuario durante un par de semanas o meses (permiso parental, por ejemplo), desactive la cuenta. Para más detalles, consulte Sección 10.4, “Desactivación de las cuentas de usuario en la interfaz web”. Las cuentas preservadas no están activas y los usuarios no pueden utilizarlas para acceder a su red interna, sin embargo, la cuenta permanece en la base de datos con todos los datos.

Puede volver a mover las cuentas restauradas al modo activo.

Nota

La lista de usuarios en estado conservado puede proporcionar un historial de cuentas de usuario anteriores.

Requisitos previos

  • Privilegios de administrador para gestionar la interfaz web de IdM (gestión de identidades) o el rol de administrador de usuarios.

Procedimiento

  1. Inicie sesión en la interfaz web de IdM.

    Para obtener más información, consulte Acceso a la interfaz web de IdM en un navegador web.

  2. Vaya a la pestaña Users → Active users.
  3. Haga clic en la casilla de las cuentas de usuario que desee conservar.
  4. Haga clic en el botón Delete.

    usuarios de idm activos eliminar

  5. En el cuadro de diálogo Remove users, cambie el botón de opción Delete mode por preserve.
  6. Haga clic en el botón Delete.

    usuarios de idm que conservan

Como resultado, la cuenta de usuario se traslada a Preserved users.

Si necesita restaurar los usuarios conservados, consulte la sección Restauración de usuarios en la interfaz web de IdM.

10.7. Restauración de usuarios en la interfaz web de IdM

La gestión de identidades (IdM) permite restaurar las cuentas de usuario conservadas en el estado activo.

Requisitos previos

  • Privilegios de administrador para gestionar la interfaz web de IdM o el rol de administrador de usuarios.

Procedimiento

  1. Inicie sesión en la interfaz web de IdM.

    Para obtener más información, consulte Acceso a la interfaz web de IdM en un navegador web.

  2. Vaya a la pestaña Users → Preserved users.
  3. Haga clic en la casilla de las cuentas de usuario que desee restaurar.
  4. Haga clic en el botón Restore.

    restauración de usuarios de idm preservada

  5. En el cuadro de diálogo Confirmation, haga clic en el botón OK.

La interfaz web de IdM muestra una confirmación verde y mueve las cuentas de usuario a la pestaña Active users.

10.8. Eliminación de usuarios en la interfaz web de IdM

El borrado de usuarios es una operación irreversible, que hace que las cuentas de usuario se eliminen permanentemente de la base de datos de IdM, incluyendo la pertenencia a grupos y las contraseñas. Cualquier configuración externa para el usuario, como la cuenta del sistema y el directorio de inicio, no se elimina, pero ya no es accesible a través de IdM.

Se puede borrar:

  • Usuarios activos: la interfaz web de IdM le ofrece las opciones:

  • Usuarios de la etapa: puedes eliminar los usuarios de la etapa de forma permanente.
  • Usuarios conservados: puede eliminar los usuarios conservados de forma permanente.

El siguiente procedimiento describe la eliminación de usuarios activos. Del mismo modo, puede eliminar las cuentas de usuario en:

  • La pestaña Stage users
  • La pestaña Preserved users

Requisitos previos

  • Privilegios de administrador para gestionar la interfaz web de IdM o el rol de administrador de usuarios.

Procedimiento

  1. Inicie sesión en la interfaz web de IdM.

    Para obtener más información, consulte Acceso a la interfaz web de IdM en un navegador web.

  2. Vaya a la pestaña Users → Active users.

    También puede eliminar la cuenta de usuario en Users → Stage users o Users → Preserved users.

  3. Haga clic en el icono Delete.
  4. En el cuadro de diálogo Remove users, cambie el botón de opción Delete mode por delete.
  5. Haga clic en el botón Delete.

Las cuentas de los usuarios han sido eliminadas permanentemente de IdM.

Capítulo 11. Gestión de las cuentas de usuario mediante los playbooks de Ansible

Puede gestionar los usuarios en IdM utilizando los libros de juego de Ansible. Este capítulo describe el uso de los playbooks de Ansible para las siguientes operaciones:

11.1. Garantizar la presencia de un usuario de IdM mediante un playbook de Ansible

El siguiente procedimiento describe cómo asegurar la presencia de un usuario en IdM mediante un playbook de Ansible.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • El paquete ansible-freeipa está instalado en el controlador Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Crea un archivo Ansible playbook con los datos del usuario cuya presencia en IdM quieres asegurar. Para simplificar este paso, puedes copiar y modificar el ejemplo del archivo /usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml. Por ejemplo, para crear un usuario llamado idm_user y añadir Password123 como contraseña del usuario:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create user idm_user
        ipauser:
          ipaadmin_password: MySecret123
          name: idm_user
          first: Alice
          last: Acme
          uid: 1000111
          gid: 10011
          phone: "+555123457"
          email: idm_user@acme.com
          passwordexpiration: "2023-01-19 23:59:59"
          password: "Password123"
          update_password: on_create

    Debe utilizar las siguientes opciones para añadir un usuario:

    • name: el nombre de usuario
    • first: la cadena del nombre
    • last: la cadena de apellidos

    Para ver la lista completa de opciones de usuario disponibles, consulte el archivo /usr/share/doc/ansible-freeipa/README-user.md Markdown.

    Nota

    Si utiliza la opción update_password: on_create, Ansible sólo crea la contraseña del usuario cuando crea el usuario. Si el usuario ya está creado con una contraseña, Ansible no genera una nueva contraseña.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml

Pasos de verificación

  • Puede verificar si la nueva cuenta de usuario existe en IdM utilizando el comando ipa user-show:

    1. Entre en ipaserver como administrador:

      $ ssh admin@server.idm.example.com
      Password:
      [admin@server /]$
    2. Solicitar un ticket Kerberos para el administrador:

      $ kinit admin
      Password for admin@IDM.EXAMPLE.COM:
    3. Solicite información sobre idm_user:

      $ ipa user-show idm_user
        User login: idm_user
        First name: Alice
        Last name: Acme
        ....

    El usuario llamado idm_user está presente en IdM.

11.2. Garantizar la presencia de varios usuarios de IdM mediante los playbooks de Ansible

El siguiente procedimiento describe cómo garantizar la presencia de varios usuarios en IdM mediante un libro de jugadas de Ansible.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Crea un archivo Ansible playbook con los datos de los usuarios cuya presencia quieres asegurar en IdM. Para simplificar este paso, puedes copiar y modificar el ejemplo del archivo /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml. Por ejemplo, para crear los usuarios idm_user_1, idm_user_2, y idm_user_3, y añadir Password123 como contraseña de idm_user_1:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create user idm_users
        ipauser:
          ipaadmin_password: MySecret123
          users:
          - name: idm_user_1
            first: Alice
            last: Acme
            uid: 10001
            gid: 10011
            phone: "+555123457"
            email: idm_user@acme.com
            passwordexpiration: "2023-01-19 23:59:59"
            password: "Password123"
          - name: idm_user_2
            first: Bob
            last: Acme
            uid: 100011
            gid: 10011
          - name: idm_user_3
            first: Eve
            last: Acme
            uid: 1000111
            gid: 10011
    Nota

    Si no se especifica la opción update_password: on_create, Ansible restablece la contraseña del usuario cada vez que se ejecuta el libro de jugadas: si el usuario ha cambiado la contraseña desde la última vez que se ejecutó el libro de jugadas, Ansible restablece la contraseña.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml

Pasos de verificación

  • Puede verificar si la cuenta de usuario existe en IdM utilizando el comando ipa user-show:

    1. Entre en ipaserver como administrador:

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. Mostrar información sobre idm_user_1:

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    El usuario llamado idm_user_1 está presente en IdM.

11.3. Garantizar la presencia de múltiples usuarios de IdM desde un archivo JSON utilizando playbooks de Ansible

El siguiente procedimiento describe cómo se puede asegurar la presencia de varios usuarios en IdM utilizando un playbook de Ansible. Los usuarios se almacenan en un archivo JSON.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo Ansible playbook con las tareas necesarias. Haz referencia al archivo JSON con los datos de los usuarios cuya presencia quieres asegurar. Para simplificar este paso, puede copiar y modificar el ejemplo del archivo /usr/share/doc/ansible-freeipa/ensure-users-present-ymlfile.yml:

    ---
    - name: Ensure users' presence
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Include users.json
        include_vars:
          file: users.json
    
      - name: Users present
        ipauser:
          ipaadmin_password: MySecret123
          users: "{{ users }}"
  3. Cree el archivo users.json y añada los usuarios de IdM en él. Para simplificar este paso, puedes copiar y modificar el ejemplo del archivo /usr/share/doc/ansible-freeipa/playbooks/user/users.json. Por ejemplo, para crear los usuarios idm_user_1, idm_user_2, y idm_user_3, y añadir Password123 como contraseña de idm_user_1:

    {
      "users": [
       {
        "name": "idm_user_1",
        "first": "Alice",
        "last": "Acme",
        "password": "Password123"
       },
       {
        "name": "idm_user_2",
        "first": "Bob",
        "last": "Acme"
       },
       {
        "name": "idm_user_3",
        "first": "Eve",
        "last": "Acme"
       }
      ]
    }
  4. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-users-present-jsonfile.yml

Pasos de verificación

  • Puede verificar si las cuentas de usuario están presentes en IdM utilizando el comando ipa user-show:

    1. Entre en ipaserver como administrador:

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. Mostrar información sobre idm_user_1:

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    El usuario llamado idm_user_1 está presente en IdM.

11.4. Garantizar la ausencia de usuarios que utilicen los playbooks de Ansible

El siguiente procedimiento describe cómo se puede utilizar un libro de jugadas de Ansible para garantizar que determinados usuarios estén ausentes de IdM.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo playbook de Ansible con los usuarios cuya ausencia de IdM desea asegurar. Para simplificar este paso, puedes copiar y modificar el ejemplo del archivo /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml. Por ejemplo, para eliminar los usuarios idm_user_1, idm_user_2, y idm_user_3:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Delete users idm_user_1, idm_user_2, idm_user_3
        ipauser:
          ipaadmin_password: MySecret123
          users:
          - name: idm_user_1
          - name: idm_user_2
          - name: idm_user_3
          state: absent
  3. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml

Pasos de verificación

Puede comprobar que las cuentas de usuario no existen en IdM utilizando el comando ipa user-show:

  1. Entre en ipaserver como administrador:

    $ ssh administrator@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicite información sobre idm_user_1:

    $ ipa user-show idm_user_1
    ipa: ERROR: idm_user_1: user not found

    El usuario llamado idm_user_1 no existe en IdM.

Recursos adicionales

  • Puedes ver ejemplos de playbooks de Ansible para otras acciones relacionadas con los usuarios de IdM como conservar, eliminar, habilitar, deshabilitar, desbloquear y deshacer usuarios en el archivo Markdown README-user.md disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipauser.
  • También puede ver ejemplos de playbooks de Ansible en el directorio /usr/share/doc/ansible-freeipa/playbooks/user.

Capítulo 12. Gestión de grupos de usuarios en IdM CLI

Este capítulo presenta la gestión de grupos de usuarios mediante la CLI de IdM.

Un grupo de usuarios es un conjunto de usuarios con privilegios, políticas de contraseña y otras características comunes.

Un grupo de usuarios en la gestión de identidades (IdM) puede incluir:

  • Usuarios de IdM
  • otros grupos de usuarios de IdM
  • usuarios externos, que son usuarios que existen fuera de IdM

12.1. Los diferentes tipos de grupos en IdM

IdM admite los siguientes tipos de grupos:

Grupos POSIX (por defecto)

Los grupos POSIX admiten atributos POSIX de Linux para sus miembros. Tenga en cuenta que los grupos que interactúan con Active Directory no pueden utilizar atributos POSIX.

Los atributos POSIX identifican a los usuarios como entidades separadas. Ejemplos de atributos POSIX relevantes para los usuarios incluyen uidNumber, un número de usuario (UID), y gidNumber, un número de grupo (GID).

Grupos no POSIX

Los grupos no POSIX no soportan los atributos POSIX. Por ejemplo, estos grupos no tienen definido un GID.

Todos los miembros de este tipo de grupo deben pertenecer al dominio IdM.

Grupos externos

Utilice los grupos externos para añadir miembros de grupos que existen en un almacén de identidades fuera del dominio de IdM, como por ejemplo

  • Un sistema local
  • Un dominio de Active Directory
  • Un servicio de directorio

Los grupos externos no soportan los atributos POSIX. Por ejemplo, estos grupos no tienen un GID definido.

Tabla 12.1. Grupos de usuarios creados por defecto

Nombre del grupoMiembros del grupo por defecto

ipausers

Todos los usuarios de IdM

admins

Usuarios con privilegios administrativos, incluido el usuario por defecto admin

editors

Este es un grupo heredado que ya no tiene privilegios especiales

trust admins

Usuarios con privilegios para gestionar los fideicomisos de Active Directory

Cuando se añade un usuario a un grupo de usuarios, el usuario obtiene los privilegios y las políticas asociadas al grupo. Por ejemplo, para conceder privilegios administrativos a un usuario, añádalo al grupo admins.

Aviso

No elimine el grupo admins. Como admins es un grupo predefinido requerido por IdM, esta operación causa problemas con ciertos comandos.

Además, IdM crea user private groups por defecto cada vez que se crea un nuevo usuario en IdM. Para obtener más información sobre los grupos privados, consulte Añadir usuarios sin grupo privado.

12.2. Miembros directos e indirectos del grupo

Los atributos de grupo de usuarios en IdM se aplican tanto a los miembros directos como a los indirectos: cuando el grupo B es miembro del grupo A, todos los usuarios del grupo B se consideran miembros indirectos del grupo A.

Por ejemplo, en el siguiente diagrama:

  • El usuario 1 y el usuario 2 son direct members del grupo A.
  • Los usuarios 3, 4 y 5 son indirect members del grupo A.

Figura 12.1. Afiliación directa e indirecta al grupo

84 RHEL IdM 0420 user group

Si establece una política de contraseñas para el grupo de usuarios A, la política también se aplica a todos los usuarios del grupo B.

12.3. Añadir un grupo de usuarios mediante la CLI de IdM

Esta sección describe cómo añadir un grupo de usuarios mediante la CLI de IdM.

Requisitos previos

Procedimiento

  • Añade un grupo de usuarios utilizando el comando ipa group-add group_name comando. Por ejemplo, para crear el grupo_a:

    $ ipa group-add group_a
    ---------------------
    Added group "group_a"
    ---------------------
      Group name: group_a
      GID: 1133400009

    Por defecto, ipa group-add añade un grupo de usuarios POSIX. Para especificar un tipo de grupo diferente, añada opciones a ipa group-add:

    Puede especificar un GID personalizado al añadir un grupo de usuarios utilizando la opción --gid=custom_GID opción. Si lo hace, tenga cuidado de evitar conflictos de ID. Si no se especifica un GID personalizado, IdM asigna automáticamente un GID del rango de ID disponibles.

12.4. Búsqueda de grupos de usuarios mediante la CLI de IdM

Esta sección describe cómo buscar grupos de usuarios existentes mediante la CLI de IdM.

Procedimiento

  • Muestra todos los grupos de usuarios utilizando el comando ipa group-find. Para especificar un tipo de grupo, añada opciones a ipa group-find:

    • Muestra todos los grupos POSIX utilizando el comando ipa group-find --posix.
    • Muestra todos los grupos no POSIX utilizando el comando ipa group-find --nonposix.
    • Muestra todos los grupos externos utilizando el comando ipa group-find --external.

      Para más información sobre los diferentes tipos de grupos, véase Los diferentes tipos de grupos en IdM.

12.5. Eliminación de un grupo de usuarios mediante la CLI de IdM

Esta sección describe cómo eliminar un grupo de usuarios mediante la CLI de IdM. Tenga en cuenta que la eliminación de un grupo no elimina los miembros del grupo de IdM.

Requisitos previos

Procedimiento

  • Elimine un grupo de usuarios mediante el comando ipa group-del group_name comando. Por ejemplo, para eliminar el grupo_a:

    $ ipa group-del group_a
    --------------------------
    Deleted group "group_a"
    --------------------------

12.6. Añadir un miembro a un grupo de usuarios mediante la CLI de IdM

Esta sección describe cómo añadir un miembro a un grupo de usuarios mediante la CLI de IdM. Se pueden añadir tanto usuarios como grupos de usuarios como miembros de un grupo de usuarios. Para obtener más información, consulte Los diferentes tipos de grupos en Id M y Miembros directos e indirectos del grupo.

Requisitos previos

Procedimiento

  • Añade un miembro a un grupo de usuarios mediante el comando ipa group-add-member.

    Especifique el tipo de miembro utilizando estas opciones:

    • --users añade un usuario IdM
    • --external añade un usuario que existe fuera del dominio IdM, en el formato de DOMAIN\user_name o user_name@domain
    • --groups añade un grupo de usuarios de IdM

    Por ejemplo, para añadir el grupo_b como miembro del grupo_a:

    $ ipa group-add-member group_a --groups=group_b
    Group name: group_a
    GID: 1133400009
    Member users: user_a
    Member groups: group_b
    Indirect Member users: user_b
    -------------------------
    Number of members added 1
    -------------------------

    Los miembros del grupo_b son ahora miembros indirectos del grupo_a.

Importante

Cuando añada un grupo como miembro de otro grupo, no cree grupos recursivos. Por ejemplo, si el grupo A es miembro del grupo B, no añada el grupo B como miembro del grupo A. Los grupos recursivos pueden provocar un comportamiento imprevisible.

Nota

Después de añadir un miembro a un grupo de usuarios, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de gestión de identidades. Esto se debe a que cuando cualquier host resuelve usuarios, grupos y netgroups, el System Security Services Daemon (SSSD) busca primero en su caché y realiza búsquedas en el servidor sólo para los registros que faltan o han caducado.

12.7. Añadir usuarios sin grupo privado de usuarios

Por defecto, IdM crea grupos privados de usuarios (UPG) cada vez que se crea un nuevo usuario en IdM. Los UPG son un tipo de grupo específico:

  • La UPG tiene el mismo nombre que el usuario recién creado.
  • El usuario es el único miembro del UPG. El UPG no puede contener ningún otro miembro.
  • El GID del grupo privado coincide con el UID del usuario.

Sin embargo, es posible añadir usuarios sin crear una UPG.

12.7.1. Usuarios sin grupo privado de usuarios

Si un grupo NIS u otro grupo del sistema ya utiliza el GID que se asignaría a un grupo privado de usuarios, es necesario evitar crear una UPG.

Puede hacerlo de dos maneras:

En ambos casos, IdM requerirá que se especifique un GID al añadir nuevos usuarios, de lo contrario la operación fallará. Esto se debe a que IdM requiere un GID para el nuevo usuario, pero el grupo de usuarios por defecto ipausers es un grupo no POSIX y por lo tanto no tiene un GID asociado. El GID que se especifica no tiene por qué corresponder a un grupo ya existente.

Nota

La especificación del GID no crea un nuevo grupo. Sólo establece el atributo GID para el nuevo usuario, porque el atributo es requerido por IdM.

12.7.2. Añadir un usuario sin un grupo privado de usuarios cuando los grupos privados están habilitados globalmente

Puede añadir un usuario sin crear un grupo privado de usuarios (GUP), incluso cuando los GUP están habilitados en el sistema. Esto requiere establecer manualmente un GID para el nuevo usuario. Para más detalles sobre por qué es necesario esto, consulte Sección 12.7.1, “Usuarios sin grupo privado de usuarios”.

Procedimiento

  • Para evitar que IdM cree una UPG, añada la opción --noprivate al comando ipa user-add.

    Tenga en cuenta que para que el comando tenga éxito, debe especificar un GID personalizado. Por ejemplo, para añadir un nuevo usuario con GID 10000:

    $ ipa user-add jsmith --first=John --last=Smith --noprivate --gid 10000

12.7.3. Desactivar los grupos privados de usuarios de forma global para todos los usuarios

Puede desactivar los grupos privados de usuarios (UPG) de forma global. Esto impide la creación de UPGs para todos los nuevos usuarios. Los usuarios existentes no se ven afectados por este cambio.

Procedimiento

  1. Obtener privilegios de administrador:

    $ kinit admin
  2. IdM utiliza el complemento de entradas gestionadas del servidor de directorio para gestionar las UPG. Enumera las instancias del plug-in:

    $ ipa-managed-entries --list
  3. Para garantizar que IdM no cree UPG, desactive la instancia del complemento responsable de gestionar los grupos privados de usuarios:

    $ ipa-managed-entries -e "UPG Definition" disable
    Disabling Plugin
    Nota

    Para volver a habilitar la instancia UPG Definition más adelante, utilice el comando ipa-managed-entries -e "UPG Definition" enable.

  4. Reinicie el servidor de directorio para cargar la nueva configuración.

    $ sudo systemctl restart dirsrv.target

    Para añadir un usuario después de que se hayan desactivado los grupos privados de usuarios, es necesario especificar un GID. Para obtener más información, consulte Añadir un usuario cuando los grupos privados de usuarios están desactivados globalmente

Pasos de verificación

  • Para comprobar si las UPGs están globalmente deshabilitadas, utilice de nuevo el comando disable:

    $ ipa-managed-entries -e "UPG Definition" disable
    Plugin already disabled

12.7.4. Añadir un usuario cuando los grupos privados de usuarios están desactivados globalmente

Cuando los grupos privados de usuarios (UPG) están deshabilitados globalmente, IdM no asigna un GID a un nuevo usuario automáticamente. Para añadir un usuario con éxito, debe asignar un GID manualmente o mediante una regla de automembresía. Para obtener más detalles sobre el motivo de este proceso, consulte Sección 12.7.1, “Usuarios sin grupo privado de usuarios”.

Requisitos previos

Procedimiento

  • Para asegurarse de que la adición de un nuevo usuario tiene éxito cuando se desactiva la creación de UPGs, elija una de las siguientes opciones:

    • Especifique un GID personalizado al añadir un nuevo usuario. El GID no tiene que corresponder a un grupo de usuarios ya existente.

      Por ejemplo, al añadir un usuario desde la línea de comandos, añada la opción --gid al comando ipa user-add.

    • Utilice una regla de automembresía para añadir el usuario a un grupo existente con un GID.

12.8. Adición de usuarios o grupos como administradores miembros de un grupo de usuarios de IdM mediante la CLI de IdM

En esta sección se describe cómo añadir usuarios o grupos como administradores miembros a un grupo de usuarios IdM mediante la CLI de IdM. Los miembros administradores pueden añadir usuarios o grupos a los grupos de usuarios de IdM, pero no pueden cambiar los atributos de un grupo.

Requisitos previos

  • Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
  • Debes tener el nombre del usuario o grupo que vas a añadir como gestor de miembros y el nombre del grupo que quieres que gestione.

Procedimiento

  • Añade un usuario como gestor de miembros a un grupo de usuarios IdM mediante el comando ipa group-add-member-manager.

    Por ejemplo, para añadir el usuario test como miembro gestor de group_a:

    $ ipa group-add-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    El usuario test ahora puede gestionar a los miembros de group_a.

  • Añade un grupo como gestor de miembros a un grupo de usuarios IdM mediante el comando ipa group-add-member-manager.

    Por ejemplo, para añadir el grupo group_admins como miembro gestor de group_a:

    $ ipa group-add-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    El grupo group_admins ahora puede gestionar a los miembros de group_a.

Nota

Después de añadir un gestor de miembros a un grupo de usuarios, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de gestión de identidades.

Pasos de verificación

  • Usando el comando ipa group-show para verificar que el usuario y el grupo fueron agregados como miembros administradores.

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test

Recursos adicionales

  • Consulte ipa group-add-member-manager --help para más detalles.

12.9. Visualización de los miembros del grupo mediante la CLI de IdM

Esta sección describe cómo ver los miembros de un grupo mediante la CLI de IdM. Puede ver los miembros directos e indirectos del grupo. Para obtener más información, consulte Miembros directos e indirectos del grupo.

Procedimiento:

  • Para listar los miembros de un grupo, utilice el comando ipa group-show group_name comando. Por ejemplo:

    $ ipa group-show group_a
      ...
      Member users: user_a
      Member groups: group_b
      Indirect Member users: user_b
    Nota

    La lista de miembros indirectos no incluye a los usuarios externos de los dominios de confianza de Active Directory. Los objetos de usuario de confianza de Active Directory no son visibles en la interfaz de Gestión de identidades porque no existen como objetos LDAP dentro de Gestión de identidades.

12.10. Eliminación de un miembro de un grupo de usuarios mediante la CLI de IdM

Esta sección describe cómo eliminar un miembro de un grupo de usuarios mediante la CLI de IdM.

Requisitos previos

Procedimiento

  1. Optional. Utilice el comando ipa group-show para confirmar que el grupo incluye al miembro que desea eliminar.
  2. Eliminar un miembro de un grupo de usuarios mediante el comando ipa group-remove-member.

    Especifique los miembros a eliminar utilizando estas opciones:

    • --users elimina un usuario de IdM
    • --external elimina un usuario que existe fuera del dominio IdM, en el formato de DOMAIN\user_name o user_name@domain
    • --groups elimina un grupo de usuarios de IdM

    Por ejemplo, para eliminar user1, user2, y group1 de un grupo llamado group_name:

    $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

12.11. Eliminación de usuarios o grupos como administradores miembros de un grupo de usuarios de IdM mediante la CLI de IdM

En esta sección se describe cómo eliminar usuarios o grupos como administradores miembros de un grupo de usuarios IdM mediante la CLI de IdM. Los miembros administradores pueden eliminar usuarios o grupos de los grupos de usuarios de IdM, pero no pueden cambiar los atributos de un grupo.

Requisitos previos

  • Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
  • Debes tener el nombre del usuario administrador de miembros existente o del grupo que estás eliminando y el nombre del grupo que están administrando.

Procedimiento

  • Elimine a un usuario como gestor miembro de un grupo de usuarios IdM mediante el comando ipa group-remove-member-manager.

    Por ejemplo, para eliminar el usuario test como miembro gestor de group_a:

    $ ipa group-remove-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    ---------------------------
    Number of members removed 1
    ---------------------------

    El usuario test ya no puede gestionar a los miembros de group_a.

  • Elimine un grupo como gestor de miembros de un grupo de usuarios IdM mediante el comando ipa group-remove-member-manager.

    Por ejemplo, para eliminar el grupo group_admins como gestor de miembros de group_a:

    $ ipa group-remove-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    ---------------------------
    Number of members removed 1
    ---------------------------

    El grupo group_admins ya no puede gestionar a los miembros de group_a.

Nota

Después de eliminar un gestor de miembros de un grupo de usuarios, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de Gestión de identidades.

Pasos de verificación

  • Usando el comando ipa group-show para verificar que el usuario y el grupo fueron removidos como miembros administradores.

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009

Recursos adicionales

  • Consulte ipa group-remove-member-manager --help para más detalles.

Capítulo 13. Gestión de grupos de usuarios en la interfaz web de IdM

Este capítulo presenta la gestión de grupos de usuarios mediante la interfaz web de IdM.

Un grupo de usuarios es un conjunto de usuarios con privilegios, políticas de contraseña y otras características comunes.

Un grupo de usuarios en la gestión de identidades (IdM) puede incluir:

  • Usuarios de IdM
  • otros grupos de usuarios de IdM
  • usuarios externos, que son usuarios que existen fuera de IdM

13.1. Los diferentes tipos de grupos en IdM

IdM admite los siguientes tipos de grupos:

Grupos POSIX (por defecto)

Los grupos POSIX admiten atributos POSIX de Linux para sus miembros. Tenga en cuenta que los grupos que interactúan con Active Directory no pueden utilizar atributos POSIX.

Los atributos POSIX identifican a los usuarios como entidades separadas. Ejemplos de atributos POSIX relevantes para los usuarios incluyen uidNumber, un número de usuario (UID), y gidNumber, un número de grupo (GID).

Grupos no POSIX

Los grupos no POSIX no soportan los atributos POSIX. Por ejemplo, estos grupos no tienen definido un GID.

Todos los miembros de este tipo de grupo deben pertenecer al dominio IdM.

Grupos externos

Utilice los grupos externos para añadir miembros de grupos que existen en un almacén de identidades fuera del dominio de IdM, como por ejemplo

  • Un sistema local
  • Un dominio de Active Directory
  • Un servicio de directorio

Los grupos externos no soportan los atributos POSIX. Por ejemplo, estos grupos no tienen un GID definido.

Tabla 13.1. Grupos de usuarios creados por defecto

Nombre del grupoMiembros del grupo por defecto

ipausers

Todos los usuarios de IdM

admins

Usuarios con privilegios administrativos, incluido el usuario por defecto admin

editors

Este es un grupo heredado que ya no tiene privilegios especiales

trust admins

Usuarios con privilegios para gestionar los fideicomisos de Active Directory

Cuando se añade un usuario a un grupo de usuarios, el usuario obtiene los privilegios y las políticas asociadas al grupo. Por ejemplo, para conceder privilegios administrativos a un usuario, añádalo al grupo admins.

Aviso

No elimine el grupo admins. Como admins es un grupo predefinido requerido por IdM, esta operación causa problemas con ciertos comandos.

Además, IdM crea user private groups por defecto cada vez que se crea un nuevo usuario en IdM. Para obtener más información sobre los grupos privados, consulte Añadir usuarios sin grupo privado.

13.2. Miembros directos e indirectos del grupo

Los atributos de grupo de usuarios en IdM se aplican tanto a los miembros directos como a los indirectos: cuando el grupo B es miembro del grupo A, todos los usuarios del grupo B se consideran miembros indirectos del grupo A.

Por ejemplo, en el siguiente diagrama:

  • El usuario 1 y el usuario 2 son direct members del grupo A.
  • Los usuarios 3, 4 y 5 son indirect members del grupo A.

Figura 13.1. Afiliación directa e indirecta al grupo

84 RHEL IdM 0420 user group

Si establece una política de contraseñas para el grupo de usuarios A, la política también se aplica a todos los usuarios del grupo B.

13.3. Añadir un grupo de usuarios mediante la interfaz web de IdM

Esta sección describe cómo añadir un grupo de usuarios mediante la interfaz web de IdM.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.

Procedimiento

  1. Haga clic en Identity → Groups, y seleccione User Groups en la barra lateral izquierda.
  2. Haga clic en Add para empezar a añadir el grupo.
  3. Rellene la información sobre el grupo. Para obtener más información sobre los tipos de grupos de usuarios, consulte Los diferentes tipos de grupos en IdM.

    Puede especificar un GID personalizado para el grupo. Si lo hace, tenga cuidado de evitar conflictos de ID. Si no se especifica un GID personalizado, IdM asigna automáticamente un GID del rango de ID disponibles.

    user group add dialog
  4. Haga clic en Add para confirmar.

13.4. Eliminación de un grupo de usuarios mediante la interfaz web de IdM

Esta sección describe cómo eliminar un grupo de usuarios mediante la interfaz web de IdM. Tenga en cuenta que la eliminación de un grupo no elimina los miembros del grupo de IdM.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.

Procedimiento

  1. Haga clic en Identity → Groups y seleccione User Groups.
  2. Seleccione el grupo que desea eliminar.
  3. Haga clic en Delete.
  4. Haga clic en Delete para confirmar.

13.5. Añadir un miembro a un grupo de usuarios mediante la interfaz web de IdM

Puede añadir tanto usuarios como grupos de usuarios como miembros de un grupo de usuarios. Para obtener más información, consulte Los diferentes tipos de grupo en IdM y Miembros directos e indirectos del grupo.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.

Procedimiento

  1. Haga clic en Identity → Groups y seleccione User Groups en la barra lateral izquierda.
  2. Haga clic en el nombre del grupo.
  3. Seleccione el tipo de miembro del grupo que desea añadir: Users, User Groups, o External.

    groups add member updated
  4. Haga clic en Add.
  5. Seleccione la casilla junto a uno o más miembros que desee añadir.
  6. Haga clic en la flecha hacia la derecha para mover los miembros seleccionados al grupo.

    groups add member dialog
  7. Haga clic en Add para confirmar.

13.6. Añadir usuarios o grupos como administradores miembros de un grupo de usuarios de IdM mediante la interfaz web

En esta sección se describe cómo añadir usuarios o grupos como administradores de miembros a un grupo de usuarios IdM mediante la interfaz web. Los gestores de miembros pueden añadir usuarios o grupos a los grupos de usuarios de IdM, pero no pueden cambiar los atributos de un grupo.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debes tener el nombre del usuario o grupo que vas a añadir como gestor de miembros y el nombre del grupo que quieres que gestione.

Procedimiento

  1. Haga clic en Identity → Groups y seleccione User Groups en la barra lateral izquierda.
  2. Haga clic en el nombre del grupo.
  3. Seleccione el tipo de gestor de miembros del grupo que desea añadir: Users o User Groups.

    groups add member manager
  4. Haga clic en Add.
  5. Seleccione la casilla junto a uno o más miembros que desee añadir.
  6. Haga clic en la flecha hacia la derecha para mover los miembros seleccionados al grupo.

    groups add member managers users
  7. Haga clic en Add para confirmar.
Nota

Después de añadir un gestor de miembros a un grupo de usuarios, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de gestión de identidades.

Pasos de verificación

  • Compruebe que el usuario o grupo de usuarios recién añadido se ha añadido a la lista de usuarios o grupos de usuarios del administrador de miembros:

    groups member manager added

Recursos adicionales

  • Para más información, consulte ipa group-add-member-manager --help.

13.7. Visualización de los miembros del grupo mediante la interfaz web de IdM

Esta sección describe cómo ver los miembros de un grupo mediante la interfaz web de IdM. Puede ver los miembros directos e indirectos del grupo. Para obtener más información, consulte Miembros directos e indirectos del grupo.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.

Procedimiento

  1. Seleccione Identity → Groups.
  2. Seleccione User Groups en la barra lateral izquierda.
  3. Haga clic en el nombre del grupo que desea ver.
  4. Cambia entre Direct Membership y Indirect Membership.

    groups menu clean

13.8. Eliminación de un miembro de un grupo de usuarios mediante la interfaz web de IdM

Esta sección describe cómo eliminar un miembro de un grupo de usuarios mediante la interfaz web de IdM.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.

Procedimiento

  1. Haga clic en Identity → Groups y seleccione User Groups en la barra lateral izquierda.
  2. Haga clic en el nombre del grupo.
  3. Seleccione el tipo de miembro del grupo que desea eliminar: Users, User Groups, o External.

    groups add member updated
  4. Seleccione la casilla junto al miembro que desea eliminar.
  5. Haga clic en Delete.
  6. Haga clic en Delete para confirmar.

13.9. Eliminación de usuarios o grupos como administradores miembros de un grupo de usuarios de IdM mediante la interfaz web

En esta sección se describe cómo eliminar usuarios o grupos como administradores de miembros de un grupo de usuarios IdM mediante la interfaz web. Los administradores de miembros pueden eliminar usuarios o grupos de los grupos de usuarios de IdM, pero no pueden cambiar los atributos de un grupo.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debes tener el nombre del usuario administrador de miembros existente o del grupo que estás eliminando y el nombre del grupo que están administrando.

Procedimiento

  1. Haga clic en Identity → Groups y seleccione User Groups en la barra lateral izquierda.
  2. Haga clic en el nombre del grupo.
  3. Seleccione el tipo de gestor de socios que desea eliminar: Users o User Groups.

    groups add member manager
  4. Seleccione la casilla junto al gestor de miembros que desea eliminar.
  5. Haga clic en Delete.
  6. Haga clic en Delete para confirmar.
Nota

Después de eliminar un gestor de miembros de un grupo de usuarios, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de Gestión de identidades.

Pasos de verificación

  • Compruebe que el usuario o grupo de usuarios ha sido eliminado de la lista de usuarios o grupos de usuarios del administrador de miembros:

    groups member manager removed

Recursos adicionales

  • Consulte ipa group-add-member-manager --help para más detalles.

Capítulo 14. Gestión de grupos de usuarios con Ansible Playbooks

En esta sección se presenta la gestión de grupos de usuarios mediante los playbooks de Ansible, incluyendo lo siguiente:

14.1. Garantizar la presencia de los grupos de IdM y de los miembros de los grupos mediante los playbooks de Ansible

El siguiente procedimiento describe cómo garantizar la presencia de los grupos de IdM y de los miembros de los grupos -tanto de los usuarios como de los grupos de usuarios- mediante un libro de jugadas de Ansible.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria de usuarios y grupos:

    ---
    - name: Playbook to handle groups
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create group ops with gid 1234
        ipagroup:
          ipaadmin_password: MySecret123
          name: ops
          gidnumber: 1234
    
      - name: Create group sysops
        ipagroup:
          ipaadmin_password: MySecret123
          name: sysops
          user:
          - idm_user
    
      - name: Create group appops
        ipagroup:
          ipaadmin_password: MySecret123
          name: appops
    
      - name: Add group members sysops and appops to group ops
        ipagroup:
          ipaadmin_password: MySecret123
          name: ops
          group:
          - sysops
          - appops
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-group-members.yml

Pasos de verificación

Puede verificar si el grupo ops contiene sysops y appops como miembros directos y idm_user como miembro indirecto utilizando el comando ipa group-show:

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar información sobre ops:

    ipaserver]$ ipa group-show ops
      Group name: ops
      GID: 1234
      Member groups: sysops, appops
      Indirect Member users: idm_user

    Los grupos appops y sysops -este último incluye al usuario idm_user - existen en IdM.

Recursos adicionales

  • Para obtener más información sobre cómo garantizar la presencia de grupos de usuarios mediante Ansible, consulte el archivo /usr/share/doc/ansible-freeipa/README-group.md Markdown.

14.2. Garantizar la presencia de los gestores de miembros en los grupos de usuarios de IdM mediante los libros de juego de Ansible

El siguiente procedimiento describe cómo garantizar la presencia de los administradores de miembros de IdM -tanto usuarios como grupos de usuarios- mediante un libro de jugadas de Ansible.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
  • Debes tener el nombre del usuario o grupo que vas a añadir como gestor de miembros y el nombre del grupo que quieres que gestione.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria para la gestión de usuarios y miembros de grupos:

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure user test is present for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_user: test
    
      - name: Ensure group_admins is present for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_group: group_admins
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-user-groups.yml

Pasos de verificación

Puede verificar si el grupo group_a contiene test como gestor de miembros y group_admins es un gestor de miembros de group_a utilizando el comando ipa group-show:

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar información sobre managergroup1:

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009
      Membership managed by groups: group_admins
      Membership managed by users: test

Recursos adicionales

  • Véase ipa host-add-member-manager --help.
  • Consulte la página de manual ipa.

14.3. Garantizar la ausencia de gestores de miembros en los grupos de usuarios de IdM mediante libros de juego de Ansible

El siguiente procedimiento describe cómo garantizar la ausencia de administradores de miembros de IdM -tanto usuarios como grupos de usuarios- mediante un libro de jugadas de Ansible.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
  • Debes tener el nombre del usuario administrador de miembros existente o del grupo que estás eliminando y el nombre del grupo que están administrando.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria para la gestión de usuarios y miembros de grupos:

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager user and group members are absent for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_user: test
          membermanager_group: group_admins
          action: member
          state: absent
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-are-absent.yml

Pasos de verificación

Puede verificar si el grupo group_a no contiene test como gestor de miembros y group_admins como gestor de miembros de group_a utilizando el comando ipa group-show:

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar información sobre el grupo_a:

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009

Recursos adicionales

  • Véase ipa host-remove-member-manager --help.
  • Consulte la página de manual ipa.

Capítulo 15. Automatización de la pertenencia a un grupo mediante la CLI de IdM

El uso de la pertenencia automática a grupos le permite asignar usuarios y hosts a grupos automáticamente en función de sus atributos. Por ejemplo, puede:

  • Divida las entradas de usuarios de los empleados en grupos en función del responsable, la ubicación o cualquier otro atributo.
  • Dividir los anfitriones en función de su clase, ubicación o cualquier otro atributo.
  • Añadir todos los usuarios o todos los hosts a un único grupo global.

Este capítulo abarca los siguientes temas:

15.1. Ventajas de la afiliación automática al grupo

El uso de la afiliación automática de usuarios le permite:

  • Reduce the overhead of manually managing group memberships

    Ya no es necesario asignar manualmente cada usuario y host a los grupos.

  • Improve consistency in user and host management

    Los usuarios y los hosts se asignan a grupos en función de criterios estrictamente definidos y evaluados automáticamente.

  • Simplify the management of group-based settings

    Se definen varias configuraciones para los grupos y luego se aplican a los miembros individuales del grupo, por ejemplo, reglas de sudo, automontaje o control de acceso. Añadir usuarios y hosts a los grupos automáticamente facilita la gestión de estos ajustes.

15.2. Reglas de los miembros automáticos

Al configurar la pertenencia automática a un grupo, el administrador define las reglas de automembresía. Una regla de automembresía se aplica a un usuario específico o a un grupo de destino del host. No puede aplicarse a más de un grupo a la vez.

Después de crear una regla, el administrador le añade condiciones. Éstas especifican qué usuarios o hosts se incluyen o excluyen del grupo de destino:

  • Inclusive conditions

    Cuando una entrada de usuario o host cumple una condición de inclusión, se incluirá en el grupo de destino.

  • Exclusive conditions

    Cuando una entrada de usuario o host cumple una condición de exclusividad, no se incluirá en el grupo de destino.

Las condiciones se especifican como expresiones regulares en el formato de expresiones regulares compatibles con Perl (PCRE). Para más información sobre PCRE, consulte la página man de pcresyntax(3).

Nota

IdM evalúa las condiciones exclusivas antes que las inclusivas. En caso de conflicto, las condiciones exclusivas tienen prioridad sobre las inclusivas.

Una regla de automembresía se aplica a cada entrada creada en el futuro. Estas entradas se añadirán automáticamente al grupo de destino especificado. Si una entrada cumple las condiciones especificadas en varias reglas de automembresía, se añadirá a todos los grupos correspondientes.

Las entradas existentes son not afectadas por la nueva regla. Si desea modificar las entradas existentes, consulte Aplicación de reglas de automembresía a las entradas existentes mediante la CLI de IdM.

15.3. Añadir una regla de automembresía utilizando la CLI de IdM

En esta sección se describe la adición de una regla de miembros automáticos mediante la CLI de IdM. Para obtener información sobre las reglas de miembros automáticos, consulte Reglas de miembros automáticos.

Después de añadir una regla de miembro automático, puede añadirle condiciones mediante el procedimiento descrito en Añadir una condición a una regla de miembro automático.

Nota

Las entradas existentes son not afectadas por la nueva regla. Si desea modificar las entradas existentes, consulte Aplicación de reglas de automembresía a las entradas existentes mediante la CLI de IdM.

Requisitos previos

Procedimiento

  1. Introduzca el comando ipa automember-add para añadir una regla de automembresía.
  2. Cuando se le pida, especifique:

    • Automember rule. Este es el nombre del grupo de destino.
    • Grouping Type. Esto especifica si la regla se dirige a un grupo de usuarios o a un grupo de hosts. Para dirigirse a un grupo de usuarios, introduzca group. Para dirigirse a un grupo de hosts, introduzca hostgroup.

    Por ejemplo, para añadir una regla de automembresía para un grupo de usuarios llamado user_group:

    $ ipa automember-add
    Automember Rule: user_group
    Grouping Type: group
    --------------------------------
    Added automember rule "user_group"
    --------------------------------
        Automember Rule: user_group

Pasos de verificación

15.4. Cómo añadir una condición a una regla de automembresía mediante la CLI de IdM

En esta sección se describe cómo añadir una condición a una regla de miembros automáticos mediante la CLI de IdM. Para obtener información sobre las reglas de miembros automáticos, consulte Reglas de miembros automáticos.

Requisitos previos

Procedimiento

  1. Defina una o más condiciones inclusivas o exclusivas utilizando el comando ipa automember-add-condition.
  2. Cuando se le pida, especifique:

    • Automember rule. Este es el nombre de la regla de destino. Para más detalles, consulte las reglas de Automember.
    • Attribute Key. Especifica el atributo de entrada al que se aplicará el filtro. Por ejemplo, uid para los usuarios.
    • Grouping Type. Esto especifica si la regla se dirige a un grupo de usuarios o a un grupo de hosts. Para dirigirse a un grupo de usuarios, introduzca group. Para dirigirse a un grupo de hosts, introduzca hostgroup.
    • Inclusive regex y Exclusive regex. Estos especifican una o más condiciones como expresiones regulares. Si sólo desea especificar una condición, pulse Enter cuando se le pida la otra.

    Por ejemplo, la siguiente condición se dirige a todos los usuarios con cualquier valor (.*) en su atributo de inicio de sesión de usuario (uid).

    $ ipa automember-add-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    ----------------------------------
    Added condition(s) to "user_group"
    ----------------------------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of conditions added 1
    ----------------------------

    Como otro ejemplo, puede utilizar una regla de automembresía para dirigirse a todos los usuarios de Windows sincronizados desde Active Directory (AD). Para ello, cree una condición que se dirija a todos los usuarios con ntUser en su atributo objectClass, que es compartido por todos los usuarios de AD:

    $ ipa automember-add-condition
    Automember Rule: ad_users
    Attribute Key: objectclass
    Grouping Type: group
    [Inclusive Regex]: ntUser
    [Exclusive Regex]:
    -------------------------------------
    Added condition(s) to "ad_users"
    -------------------------------------
      Automember Rule: ad_users
      Inclusive Regex: objectclass=ntUser
    ----------------------------
    Number of conditions added 1
    ----------------------------

Pasos de verificación

15.5. Visualización de las reglas existentes de los miembros automáticos mediante la CLI de IdM

Esta sección describe cómo ver las reglas existentes de los miembros automáticos utilizando la CLI de IdM.

Requisitos previos

Procedimiento

  1. Introduzca el comando ipa automember-find.
  2. Cuando se le solicite, especifique la dirección Grouping type:

    • Para seleccionar un grupo de usuarios, introduzca group.
    • Para apuntar a un grupo de hosts, introduzca hostgroup.

      Por ejemplo:

    $ ipa automember-find
    Grouping Type: group
    ---------------
    1 rules matched
    ---------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of entries returned 1
    ----------------------------

15.6. Eliminación de una regla de automembresía mediante la CLI de IdM

En esta sección se describe cómo eliminar una regla de automembresía mediante la CLI de IdM.

Al eliminar una regla de miembro automático también se eliminan todas las condiciones asociadas a la regla. Para eliminar sólo condiciones específicas de una regla, consulte Eliminación de una condición de una regla de miembros automáticos mediante la CLI de IdM.

Requisitos previos

Procedimiento

  1. Introduzca el comando ipa automember-del.
  2. Cuando se le pida, especifique:

    • Automember rule. Esta es la regla que desea eliminar.
    • Grouping rule. Esto especifica si la regla que desea eliminar es para un grupo de usuarios o un grupo de hosts. Introduzca group o hostgroup.

15.7. Eliminación de una condición de una regla de autómatas mediante la CLI de IdM

Esta sección describe cómo eliminar una condición específica de una regla de automembresía.

Requisitos previos

Procedimiento

  1. Introduzca el comando ipa automember-remove-condition.
  2. Cuando se le pida, especifique:

    • Automember rule. Es el nombre de la regla de la que se quiere eliminar una condición.
    • Attribute Key. Este es el atributo de entrada de destino. Por ejemplo, uid para los usuarios.
    • Grouping Type. Esto especifica si la condición que desea eliminar es para un grupo de usuarios o un grupo de hosts. Introduzca group o hostgroup.
    • Inclusive regex y Exclusive regex. En ellos se especifican las condiciones que desea eliminar. Si sólo quiere especificar una condición, pulse Enter cuando se le pida la otra.

      Por ejemplo:

    $ ipa automember-remove-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    -----------------------------------
    Removed condition(s) from "user_group"
    -----------------------------------
      Automember Rule: user_group
    ------------------------------
    Number of conditions removed 1
    ------------------------------

15.8. Aplicación de reglas de automembresía a las entradas existentes mediante la CLI de IdM

Las reglas de Automember se aplican automáticamente a las entradas de usuarios y hosts creadas después de añadir las reglas. No se aplican de forma retroactiva a las entradas que existían antes de que se añadieran las reglas.

Para aplicar las reglas de automember a las entradas previamente añadidas, tienes que reconstruir manualmente la membresía automática. La reconstrucción de la membresía automática reevalúa todas las reglas de automember existentes y las aplica a todas las entradas de usuarios o hosts, o a entradas específicas.

Nota

Reconstrucción de la membresía automática does not eliminar las entradas de usuarios o hosts de los grupos, incluso si las entradas ya no coinciden con las condiciones de inclusión del grupo. Para eliminarlas manualmente, consulte Cómo eliminar un miembro de un grupo de usuarios mediante la CLI de IdM o Cómo eliminar miembros de grupos de hosts de IdM mediante la CLI.

Requisitos previos

Procedimiento

  • Para reconstruir la afiliación automática, introduzca el comando ipa automember-rebuild. Utiliza las siguientes opciones para especificar las entradas a las que dirigirte:

    • Para reconstruir la afiliación automática de todos los usuarios, utilice la opción --type=group:

      $ ipa automember-rebuild --type=group
      --------------------------------------------------------
      Automember rebuild task finished. Processed (9) entries.
      --------------------------------------------------------
    • Para reconstruir la afiliación automática de todos los hosts, utilice la opción --type=hostgroup.
    • Para reconstruir la membresía automática para un usuario o usuarios específicos, utilice la --users=target_user opción:

      $ ipa automember-rebuild --users=target_user1 --users=target_user2
      --------------------------------------------------------
      Automember rebuild task finished. Processed (2) entries.
      --------------------------------------------------------
    • Para reconstruir la membresía automática para un host o hosts específicos, utilice la opción --hosts=client.idm.example.com opción.

15.9. Configuración de un grupo de miembros automáticos por defecto mediante la CLI de IdM

Cuando se configura un grupo de miembros automáticos por defecto, las nuevas entradas de usuarios o hosts que no coinciden con ninguna regla de miembros automáticos se añaden automáticamente a este grupo por defecto.

Requisitos previos

Procedimiento

  1. Introduzca el comando ipa automember-default-group-set para configurar un grupo de automembresía por defecto.
  2. Cuando se le pida, especifique:

    • Default (fallback) Group, que especifica el nombre del grupo de destino.
    • Grouping Type, que especifica si el objetivo es un grupo de usuarios o un grupo de hosts. Para dirigirse a un grupo de usuarios, introduzca group. Para dirigirse a un grupo de hosts, introduzca hostgroup.

      Por ejemplo:

      $ ipa automember-default-group-set
      Default (fallback) Group: default_user_group
      Grouping Type: group
      ---------------------------------------------------
      Set default (fallback) group for automember "default_user_group"
      ---------------------------------------------------
        Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
    Nota

    Para eliminar el grupo actual de miembros automáticos por defecto, introduzca el comando ipa automember-default-group-remove.

Pasos de verificación

  • Para verificar que el grupo está configurado correctamente, introduzca el comando ipa automember-default-group-show. El comando muestra el grupo actual por defecto de los miembros automáticos. Por ejemplo:

    $ ipa automember-default-group-show
    Grouping Type: group
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com

Capítulo 16. Automatización de la pertenencia a un grupo mediante la interfaz web de IdM

El uso de la pertenencia automática a grupos le permite asignar usuarios y hosts a grupos automáticamente en función de sus atributos. Por ejemplo, puede:

  • Divida las entradas de usuarios de los empleados en grupos en función del responsable, la ubicación o cualquier otro atributo.
  • Dividir los anfitriones en función de su clase, ubicación o cualquier otro atributo.
  • Añadir todos los usuarios o todos los hosts a un único grupo global.

Este capítulo abarca los siguientes temas:

16.1. Ventajas de la afiliación automática al grupo

El uso de la afiliación automática de usuarios le permite:

  • Reduce the overhead of manually managing group memberships

    Ya no es necesario asignar manualmente cada usuario y host a los grupos.

  • Improve consistency in user and host management

    Los usuarios y los hosts se asignan a grupos en función de criterios estrictamente definidos y evaluados automáticamente.

  • Simplify the management of group-based settings

    Se definen varias configuraciones para los grupos y luego se aplican a los miembros individuales del grupo, por ejemplo, reglas de sudo, automontaje o control de acceso. Añadir usuarios y hosts a los grupos automáticamente facilita la gestión de estos ajustes.

16.2. Reglas de los miembros automáticos

Al configurar la pertenencia automática a un grupo, el administrador define las reglas de automembresía. Una regla de automembresía se aplica a un usuario específico o a un grupo de destino del host. No puede aplicarse a más de un grupo a la vez.

Después de crear una regla, el administrador le añade condiciones. Éstas especifican qué usuarios o hosts se incluyen o excluyen del grupo de destino:

  • Inclusive conditions

    Cuando una entrada de usuario o host cumple una condición de inclusión, se incluirá en el grupo de destino.

  • Exclusive conditions

    Cuando una entrada de usuario o host cumple una condición de exclusividad, no se incluirá en el grupo de destino.

Las condiciones se especifican como expresiones regulares en el formato de expresiones regulares compatibles con Perl (PCRE). Para más información sobre PCRE, consulte la página man de pcresyntax(3).

Nota

IdM evalúa las condiciones exclusivas antes que las inclusivas. En caso de conflicto, las condiciones exclusivas tienen prioridad sobre las inclusivas.

Una regla de automembresía se aplica a cada entrada creada en el futuro. Estas entradas se añadirán automáticamente al grupo de destino especificado. Si una entrada cumple las condiciones especificadas en varias reglas de automembresía, se añadirá a todos los grupos correspondientes.

Las entradas existentes se ven afectadas por la nueva regla en not. Si desea modificar las entradas existentes, consulte Aplicación de reglas de automembresía a las entradas existentes mediante la interfaz web de IdM.

16.3. Añadir una regla de automembresía mediante la interfaz web de IdM

En esta sección se describe la adición de una regla de miembros automáticos mediante la interfaz web de IdM. Para obtener información sobre las reglas de automembresía, consulte Reglas de automembresía.

Nota

Las entradas existentes se ven afectadas por la nueva regla en not. Si desea modificar las entradas existentes, consulte Aplicación de reglas de automembresía a las entradas existentes mediante la interfaz web de IdM.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.
  • El grupo de destino de la nueva regla existe en IdM.

Procedimiento

  1. Haga clic en Identity → Automember, y seleccione User group rules o Host group rules.
  2. Haga clic en Add.
  3. En el campo Automember rule, seleccione el grupo al que se aplicará la regla. Este es el nombre del grupo de destino.

    automember rule add
  4. Haga clic en Add para confirmar.
  5. Opcional: Puede añadir condiciones a la nueva regla mediante el procedimiento descrito en Añadir una condición a una regla de miembro automático mediante la interfaz web de IdM.

16.4. Cómo añadir una condición a una regla de miembro automático mediante la interfaz web de IdM

En esta sección se describe cómo añadir una condición a una regla de miembros automáticos mediante la interfaz web de IdM. Para obtener información sobre las reglas de miembros automáticos, consulte Reglas de miembros automáticos.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.
  • La regla de destino existe en IdM.

Procedimiento

  1. Haga clic en Identity → Automember, y seleccione User group rules o Host group rules.
  2. Haga clic en la regla a la que desea añadir una condición.
  3. En las secciones Inclusive o Exclusive, haga clic en Añadir.

    automember condition add
  4. En el campo Attribute, seleccione el atributo requerido, por ejemplo uid.
  5. En el campo Expression, defina una expresión regular.
  6. Haga clic en Add.

    Por ejemplo, la siguiente condición se dirige a todos los usuarios con cualquier valor (.*) en su atributo de identificación de usuario (uid).

    automember add

16.5. Visualización de las reglas y condiciones existentes de los miembros automáticos mediante la interfaz web de IdM

Esta sección describe cómo ver las reglas y condiciones existentes de los miembros automáticos mediante la interfaz web de IdM.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.

Procedimiento

  1. Haga clic en Identity → Automember, y seleccione User group rules o Host group rules para ver las reglas respectivas de los miembros automáticos.
  2. Es opcional: Haga clic en una regla para ver las condiciones de esa regla en las secciones Inclusive o Exclusive.

    automember conditions

16.6. Eliminación de una regla de automembresía mediante la interfaz web de IdM

En esta sección se describe cómo eliminar una regla de miembro automático mediante la interfaz web de IdM.

Al eliminar una regla de miembro automático también se eliminan todas las condiciones asociadas a la regla. Para eliminar sólo condiciones específicas de una regla, consulte Eliminar una condición de una regla de miembros automáticos mediante la interfaz web de IdM.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.

Procedimiento

  1. Haga clic en Identity → Automember, y seleccione User group rules o Host group rules para ver las reglas respectivas de los miembros automáticos.
  2. Seleccione la casilla junto a la regla que desea eliminar.
  3. Haga clic en Delete.

    automember rule delete
  4. Haga clic en Delete para confirmar.

16.7. Eliminación de una condición de una regla de miembro automático mediante la interfaz web de IdM

En esta sección se describe cómo eliminar una condición específica de una regla de miembro automático mediante la interfaz web de IdM.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.

Procedimiento

  1. Haga clic en Identity → Automember, y seleccione User group rules o Host group rules para ver las reglas respectivas de los miembros automáticos.
  2. Haga clic en una regla para ver las condiciones de esa regla en las secciones Inclusive o Exclusive.
  3. Seleccione la casilla junto a las condiciones que desea eliminar.
  4. Haga clic en Delete.

    automember condition remove
  5. Haga clic en Delete para confirmar.

16.8. Aplicación de reglas de automembresía a las entradas existentes mediante la interfaz web de IdM

Las reglas de Automember se aplican automáticamente a las entradas de usuarios y hosts creadas después de añadir las reglas. No se aplican de forma retroactiva a las entradas que existían antes de que se añadieran las reglas.

Para aplicar las reglas de automember a las entradas previamente añadidas, tienes que reconstruir manualmente la membresía automática. La reconstrucción de la membresía automática reevalúa todas las reglas de automember existentes y las aplica a todas las entradas de usuarios o hosts, o a entradas específicas.

Nota

Reconstrucción de la membresía automática does not eliminar las entradas de usuarios o hosts de los grupos, incluso si las entradas ya no coinciden con las condiciones de inclusión del grupo. Para eliminarlas manualmente, consulte Cómo eliminar un miembro de un grupo de usuarios mediante la interfaz web de IdM o Cómo eliminar miembros de un grupo de hosts en la interfaz web de IdM.

16.8.1. Reconstrucción de la afiliación automática para todos los usuarios o hosts

Esta sección describe cómo reconstruir la membresía automática para todas las entradas de usuarios o hosts.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.

Procedimiento

  1. Seleccione IdentityUsers o Hosts.
  2. Haga clic en ActionsRebuild auto membership.

    automember rebuild

16.8.2. Reconstrucción de la membresía automática para un solo usuario o anfitrión

Esta sección describe cómo reconstruir la membresía automática para una entrada específica de usuario o host.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.

Procedimiento

  1. Seleccione IdentityUsers o Hosts.
  2. Haga clic en el nombre de usuario o de host deseado.
  3. Haga clic en ActionsRebuild auto membership.

    automember rebuild single

16.9. Configuración de un grupo de usuarios por defecto mediante la interfaz web de IdM

Cuando se configura un grupo de usuarios por defecto, las nuevas entradas de usuarios que no coinciden con ninguna regla de automembresía se añaden automáticamente a este grupo por defecto.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.
  • El grupo de usuarios de destino que desea establecer como predeterminado existe en IdM.

Procedimiento

  1. Haga clic en Identity → Automember, y seleccione User group rules.
  2. En el campo Default user group, seleccione el grupo que desea establecer como grupo de usuarios por defecto.

    Setting a default user group

16.10. Configuración de un grupo de hosts por defecto mediante la interfaz web de IdM

Cuando se configura un grupo de hosts por defecto, las nuevas entradas de hosts que no coinciden con ninguna regla de automembresía se añaden automáticamente a este grupo por defecto.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM.
  • Debe ser miembro del grupo admins.
  • El grupo de host de destino que desea establecer como predeterminado existe en IdM.

Procedimiento

  1. Haga clic en Identity → Automember, y seleccione Host group rules.
  2. En el campo Default host group, seleccione el grupo que desea establecer como grupo de hosts por defecto.

    Setting a default host group

Capítulo 17. Gestión de reglas de autoservicio en IdM mediante la CLI

En este capítulo se presentan las reglas de autoservicio en Identity Management (IdM) y se describe cómo crear y editar reglas de acceso de autoservicio en la interfaz de línea de comandos (CLI).

17.1. Control de acceso de autoservicio en IdM

Las reglas de control de acceso de autoservicio definen qué operaciones puede realizar una entidad IdM en su entrada del servidor de directorio IdM: por ejemplo, los usuarios de IdM tienen la capacidad de actualizar sus propias contraseñas

Este método de control permite a una entidad IdM autentificada editar atributos específicos dentro de su entrada LDAP, pero no permite las operaciones add o delete en toda la entrada.

Aviso

Tenga cuidado cuando trabaje con las reglas de control de acceso de autoservicio: configurar las reglas de control de acceso de forma incorrecta puede elevar inadvertidamente los privilegios de una entidad.

17.2. Creación de reglas de autoservicio mediante la CLI

Este procedimiento describe la creación de reglas de acceso de autoservicio en IdM mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  • Para añadir una regla de autoservicio, utilice el comando ipa selfservice-add y especifique las dos opciones siguientes:

    --permissions
    establece los permisos read y write que concede la Instrucción de Control de Acceso (ACI).
    --attrs
    establece la lista completa de atributos a los que este ACI concede permiso.

Por ejemplo, para crear una regla de autoservicio que permita a los usuarios modificar los detalles de su propio nombre

$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
    Self-service name: Users can manage their own name details
    Permissions: write
    Attributes: givenname, displayname, title, initials

17.3. Edición de reglas de autoservicio mediante la CLI

Este procedimiento describe la edición de reglas de acceso de autoservicio en IdM mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  1. Optional: Muestra las reglas de autoservicio existentes con el comando ipa selfservice-find.
  2. Optional: Muestra los detalles de la regla de autoservicio que desea modificar con el comando ipa selfservice-show.
  3. Utilice el comando ipa selfservice-mod para editar una regla de autoservicio.

Por ejemplo

$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname
--------------------------------------------------------------
Modified selfservice "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials
Importante

El uso del comando ipa selfservice-mod sobrescribe los permisos y atributos previamente definidos, por lo que incluya siempre la lista completa de permisos y atributos existentes junto con los nuevos que desee definir.

Pasos de verificación

  • Utilice el comando ipa selfservice-show para mostrar la regla de autoservicio que ha editado.
$ ipa selfservice-show "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials

17.4. Eliminación de reglas de autoservicio mediante la CLI

Este procedimiento describe la eliminación de reglas de acceso de autoservicio en IdM mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  • Utilice el comando ipa selfservice-del para eliminar una regla de autoservicio.

Por ejemplo

$ ipa selfservice-del "Users can manage their own name details"
-----------------------------------------------------------
Deleted selfservice "Users can manage their own name details"
-----------------------------------------------------------

Pasos de verificación

  • Utilice el comando ipa selfservice-find para mostrar todas las reglas de autoservicio. La regla que acaba de eliminar debería desaparecer.

Capítulo 18. Gestión de las reglas de autoservicio mediante la interfaz web de IdM

Este capítulo presenta las reglas de autoservicio en la Gestión de identidades (IdM) y describe cómo crear y editar reglas de acceso de autoservicio en la interfaz web (IdM Web UI).

18.1. Control de acceso de autoservicio en IdM

Las reglas de control de acceso de autoservicio definen qué operaciones puede realizar una entidad IdM en su entrada del servidor de directorio IdM: por ejemplo, los usuarios de IdM tienen la capacidad de actualizar sus propias contraseñas

Este método de control permite a una entidad IdM autentificada editar atributos específicos dentro de su entrada LDAP, pero no permite las operaciones add o delete en toda la entrada.

Aviso

Tenga cuidado cuando trabaje con las reglas de control de acceso de autoservicio: configurar las reglas de control de acceso de forma incorrecta puede elevar inadvertidamente los privilegios de una entidad.

18.2. Creación de reglas de autoservicio mediante la interfaz web de IdM

Este procedimiento describe cómo crear reglas de acceso de autoservicio en IdM mediante la interfaz web (IdM Web UI).

Requisitos previos

Procedimiento

  1. Abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Self Service Permissions.
  2. Haga clic en Add en la parte superior derecha de la lista de las reglas de acceso de autoservicio:

    Añadir una regla de autoservicio

  3. Se abre la ventana Add Self Service Permission. Introduzca el nombre de la nueva regla de autoservicio en el campo Self-service name. Se permiten espacios:

    Formulario para añadir una regla de autoservicio

  4. Seleccione las casillas de verificación junto a los atributos que desea que los usuarios puedan editar.
  5. Optional: Si un atributo al que quiere dar acceso no está en la lista, puede añadir un listado para él:

    1. Haga clic en el botón Add.
    2. Introduzca el nombre del atributo en el campo de texto Attribute de la siguiente ventana Add Custom Attribute.
    3. Pulse el botón OK para añadir el atributo
    4. Compruebe que el nuevo atributo está seleccionado
  6. Haga clic en el botón Add en la parte inferior del formulario para guardar la nueva regla de autoservicio.
    También puede guardar y continuar editando la regla de autoservicio haciendo clic en el botón Add and Edit, o guardar y añadir más reglas haciendo clic en el botón Add and Add another.

18.3. Edición de reglas de autoservicio mediante la interfaz web de IdM

Este procedimiento describe cómo editar las reglas de acceso de autoservicio en IdM mediante la interfaz web (IdM Web UI).

Requisitos previos

Procedimiento

  1. Abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Self Service Permissions.
  2. Haga clic en el nombre de la regla de autoservicio que desea modificar.

    Editar una regla de autoservicio existente

  3. La página de edición sólo le permite editar la lista de atributos que desea añadir o eliminar de la regla de autoservicio. Active o desactive las casillas de verificación correspondientes.
  4. Haga clic en el botón Save para guardar los cambios en la regla de autoservicio.

18.4. Eliminación de reglas de autoservicio mediante la interfaz web de IdM

Este procedimiento describe cómo eliminar las reglas de acceso de autoservicio en IdM mediante la interfaz web (IdM Web UI).

Requisitos previos

Procedimiento

  1. Abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Self Service Permissions.
  2. Seleccione la casilla junto a la regla que desea eliminar y, a continuación, haga clic en el botón Delete situado a la derecha de la lista.

    Borrar una regla de autoservicio

  3. Se abre un cuadro de diálogo, haga clic en Delete para confirmar.

Capítulo 19. Delegación de permisos sobre los usuarios mediante IdM CLI

La delegación es uno de los métodos de control de acceso en IdM, junto con las reglas de autoservicio y el control de acceso basado en roles.

La delegación es similar a los roles en el sentido de que a un grupo de usuarios se le asigna permiso para gestionar las entradas de otro grupo de usuarios. Sin embargo, la autoridad delegada se limita a la edición de los valores de atributos específicos; no concede la capacidad de añadir o eliminar entradas completas ni el control sobre atributos no especificados. Además, los grupos con autoridad delegada son grupos de usuarios de IdM existentes en lugar de roles creados específicamente para los controles de acceso.

Este capítulo abarca los siguientes temas:

19.1. Normas de delegación

Puedes delegar permisos sobre los usuarios creando reglas de delegación.

Las reglas de delegación permiten a un grupo de usuarios específico realizar operaciones de escritura (edición) en atributos específicos para usuarios de otro grupo de usuarios. Esta forma de regla de control de acceso se limita a la edición de los valores de atributos específicos; no concede la capacidad de añadir o eliminar entradas completas ni el control sobre atributos no especificados.

Las reglas de delegación utilizan los grupos de usuarios existentes en IdM. Puede utilizar la delegación para, por ejemplo, permitir que el grupo de usuarios managers gestione los atributos seleccionados de los usuarios del grupo de usuarios employees.

19.2. Creación de una regla de delegación mediante la CLI de IdM

Esta sección describe cómo crear una regla de delegación utilizando la CLI de IdM.

Requisitos previos

  • Está conectado como miembro del grupo admins.

Procedimiento

  • Introduzca el comando ipa delegation-add. Especifique las siguientes opciones:

    • --group: el grupo que is being granted permissions a las entradas de los usuarios en el grupo de usuarios.
    • --membergroup: el grupo whose entries can be edited por los miembros del grupo de delegación.
    • --permissions: si los usuarios tendrán derecho a ver los atributos dados (read) y a añadir o cambiar los atributos dados (write). Si no se especifican los permisos, sólo se añadirá el permiso write.
    • --attrs: los atributos que los usuarios del grupo de miembros pueden ver o editar.

    Por ejemplo:

$ ipa delegation-add "basic manager attributes" --permissions=read --permissions=write --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --group=managers --membergroup=employees
-------------------------------------------
Added delegation "basic manager attributes"
-------------------------------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeetype, employeenumber
  Member user group: employees
  User group: managers

19.3. Visualización de las reglas de delegación existentes mediante la CLI de IdM

Esta sección describe cómo ver las reglas de delegación existentes utilizando la CLI de IdM.

Requisitos previos

  • Está conectado como miembro del grupo admins.

Procedimiento

  • Introduzca el comando ipa delegation-find:
$ ipa delegation-find
--------------------
1 delegation matched
--------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeenumber, employeetype
  Member user group: employees
  User group: managers
----------------------------
Number of entries returned 1
----------------------------

19.4. Modificación de una regla de delegación mediante la CLI de IdM

Esta sección describe cómo modificar una regla de delegación existente mediante la CLI de IdM.

Importante

La opción --attrs sobrescribe la lista anterior de atributos admitidos, por lo que siempre debe incluirse la lista completa de atributos junto con los nuevos. Esto también se aplica a la opción --permissions.

Requisitos previos

  • Está conectado como miembro del grupo admins.

Procedimiento

  • Introduzca el comando ipa delegation-mod con los cambios deseados. Por ejemplo, para añadir el atributo displayname a la regla de ejemplo basic manager attributes:

    $ ipa delegation-mod "basic manager attributes" --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --attrs=displayname
    ----------------------------------------------
    Modified delegation "basic manager attributes"
    ----------------------------------------------
      Delegation name: basic manager attributes
      Permissions: read, write
      Attributes: businesscategory, departmentnumber, employeetype, employeenumber, displayname
      Member user group: employees
      User group: managers

19.5. Eliminación de una regla de delegación mediante la CLI de IdM

Esta sección describe cómo eliminar una regla de delegación existente mediante la CLI de IdM.

Requisitos previos

  • Está conectado como miembro del grupo admins.

Procedimiento

  • Introduzca el comando ipa delegation-del.
  • Cuando se le solicite, introduzca el nombre de la regla de delegación que desea eliminar:

    $ ipa delegation-del
    Delegation name: basic manager attributes
    ---------------------------------------------
    Deleted delegation "basic manager attributes"
    ---------------------------------------------

Capítulo 20. Delegación de permisos sobre los usuarios mediante IdM WebUI

La delegación es uno de los métodos de control de acceso en IdM, junto con las reglas de autoservicio y el control de acceso basado en roles.

La delegación es similar a los roles en el sentido de que a un grupo de usuarios se le asigna permiso para gestionar las entradas de otro grupo de usuarios. Sin embargo, la autoridad delegada se limita a la edición de los valores de atributos específicos; no concede la capacidad de añadir o eliminar entradas completas ni el control sobre atributos no especificados. Además, los grupos con autoridad delegada son grupos de usuarios de IdM existentes en lugar de roles creados específicamente para los controles de acceso.

Este capítulo abarca los siguientes temas:

20.1. Normas de delegación

Puedes delegar permisos sobre los usuarios creando reglas de delegación.

Las reglas de delegación permiten a un grupo de usuarios específico realizar operaciones de escritura (edición) en atributos específicos para usuarios de otro grupo de usuarios. Esta forma de regla de control de acceso se limita a la edición de los valores de atributos específicos; no concede la capacidad de añadir o eliminar entradas completas ni el control sobre atributos no especificados.

Las reglas de delegación utilizan los grupos de usuarios existentes en IdM. Puede utilizar la delegación para, por ejemplo, permitir que el grupo de usuarios managers gestione los atributos seleccionados de los usuarios del grupo de usuarios employees.

20.2. Creación de una regla de delegación mediante IdM WebUI

Esta sección describe cómo crear una regla de delegación utilizando la IdM WebUI.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM como miembro del grupo admins.

Procedimiento

  1. En el menú IPA Server, haga clic en Role-Based Access ControlDelegations.
  2. Haga clic en Add.

    delegation list add
  3. En la ventana Add delegation, haga lo siguiente:

    1. Nombra la nueva regla de delegación.
    2. Establezca los permisos seleccionando las casillas de verificación que indican si los usuarios tendrán derecho a ver los atributos dados (read) y a añadir o cambiar los atributos dados (write).
    3. En el menú desplegable Grupo de usuarios, seleccione el grupo who is being granted permissions para ver o editar las entradas de los usuarios del grupo de miembros.
    4. En el menú desplegable Member user group, seleccione el grupo whose entries can be edited por miembros del grupo de delegación.
    5. En el cuadro de atributos, seleccione las casillas de verificación de los atributos a los que desea conceder permisos.

      delegation add UPDATED
    6. Haga clic en el botón Add para guardar la nueva regla de delegación.

20.3. Visualización de las reglas de delegación existentes mediante IdM WebUI

Esta sección describe cómo ver las reglas de delegación existentes utilizando la IdM WebUI.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM como miembro del grupo admins.

Procedimiento

  1. En el menú IPA Server, haga clic en Role-Based Access ControlDelegations.

    delegation list

20.4. Modificación de una regla de delegación mediante IdM WebUI

Esta sección describe cómo modificar una regla de delegación existente utilizando la IdM WebUI.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM como miembro del grupo admins.

Procedimiento

  1. En el menú IPA Server, haga clic en Role-Based Access ControlDelegations.

    delegation list
  2. Haga clic en la regla que desea modificar.
  3. Realice los cambios deseados:

    • Cambiar el nombre de la regla.
    • Cambie los permisos concedidos seleccionando las casillas que indican si los usuarios tendrán derecho a ver los atributos dados (read) y a añadir o cambiar los atributos dados (write).
    • En el menú desplegable Grupo de usuarios, seleccione el grupo who is being granted permissions para ver o editar las entradas de los usuarios del grupo de miembros.
    • En el menú desplegable Member user group, seleccione el grupo whose entries can be edited por miembros del grupo de delegación.
    • En el cuadro de atributos, seleccione las casillas de verificación de los atributos a los que desea conceder permisos. Para eliminar los permisos de un atributo, desmarque la casilla correspondiente.

      delegation modify
    • Pulse el botón Save para guardar los cambios.

20.5. Eliminación de una regla de delegación mediante IdM WebUI

Esta sección describe cómo eliminar una regla de delegación existente utilizando la IdM WebUI.

Requisitos previos

  • Ha iniciado la sesión en la interfaz web de IdM como miembro del grupo admins.

Procedimiento

  1. En el menú IPA Server, haga clic en Role-Based Access ControlDelegations.
  2. Seleccione la casilla junto a la regla que desea eliminar.
  3. Haga clic en Delete.

    delegation delete
  4. Haga clic en Delete para confirmar.

Capítulo 21. Gestión de los controles de acceso basados en roles en IdM mediante la CLI

En este capítulo se presenta el control de acceso basado en funciones en la gestión de identidades (IdM) y se describen las siguientes operaciones en la interfaz de línea de comandos (CLI):

21.1. Control de acceso basado en roles en IdM

El control de acceso basado en roles (RBAC) en IdM otorga un tipo de autoridad muy diferente a los usuarios en comparación con los controles de acceso de autoservicio y de delegación.

El control de acceso basado en roles se compone de tres partes:

  • Permissions concede el derecho a realizar una tarea específica, como añadir o eliminar usuarios, modificar un grupo, habilitar el acceso de lectura, etc.
  • Privileges combina los permisos, por ejemplo, todos los permisos necesarios para añadir un nuevo usuario.
  • Roles concede un conjunto de privilegios a usuarios, grupos de usuarios, hosts o grupos de hosts.

21.1.1. Permisos en IdM

Los permisos son la unidad de nivel más bajo del control de acceso basado en roles, definen las operaciones junto con las entradas LDAP a las que se aplican dichas operaciones. Comparable a los bloques de construcción, los permisos pueden asignarse a tantos privilegios como sea necesario.
Uno o más rights definen qué operaciones están permitidas:

  • write
  • read
  • search
  • compare
  • add
  • delete
  • all

Estas operaciones se aplican a tres direcciones básicas targets:

  • subtree: un nombre de dominio (DN); el subárbol bajo este DN
  • target filter: un filtro LDAP
  • target: DN con posibles comodines para especificar las entradas

Además, las siguientes opciones de conveniencia establecen los atributos correspondientes:

  • type: un tipo de objeto (usuario, grupo, etc.); establece subtree y target filter
  • memberof: miembros de un grupo; establece un target filter
  • targetgroup: concede el acceso para modificar un grupo específico (como la concesión de los derechos para gestionar la pertenencia a un grupo); establece un target

Con los permisos de IdM, puede controlar qué usuarios tienen acceso a qué objetos e incluso a qué atributos de estos objetos. IdM le permite permitir o bloquear atributos individuales o cambiar toda la visibilidad de una función específica de IdM, como usuarios, grupos o sudo, a todos los usuarios anónimos, a todos los usuarios autenticados o sólo a un determinado grupo de usuarios privilegiados.
Por ejemplo, la flexibilidad de este enfoque de los permisos es útil para un administrador que quiere limitar el acceso de los usuarios o grupos sólo a las secciones específicas a las que estos usuarios o grupos necesitan acceder y hacer que las otras secciones estén completamente ocultas para ellos.

Nota

Un permiso no puede contener otros permisos.

21.1.2. Permisos gestionados por defecto

Los permisos gestionados son permisos que vienen por defecto con IdM. Se comportan como otros permisos creados por el usuario, con las siguientes diferencias:

  • No se pueden eliminar ni modificar sus atributos de nombre, ubicación y destino.
  • Tienen tres conjuntos de atributos:

    • Default atributos, el usuario no puede modificarlos, ya que son gestionados por IdM
    • Included atributos, que son atributos adicionales añadidos por el usuario
    • Excluded atributos, que son atributos eliminados por el usuario

Un permiso gestionado se aplica a todos los atributos que aparecen en los conjuntos de atributos predeterminados e incluidos, pero no en el conjunto excluido.

Nota

Aunque no se puede eliminar un permiso gestionado, si se establece su tipo de enlace como permiso y se elimina el permiso gestionado de todos los privilegios, se desactiva de forma efectiva.

Los nombres de todos los permisos gestionados comienzan con System:, por ejemplo System: Add Sudo rule o System: Modify Services. Las versiones anteriores de IdM utilizaban un esquema diferente para los permisos por defecto. Por ejemplo, el usuario no podía eliminarlos y sólo podía asignarlos a los privilegios. La mayoría de estos permisos por defecto se han convertido en permisos gestionados, sin embargo, los siguientes permisos siguen utilizando el esquema anterior:

  • Añadir la tarea de reconstrucción de miembros automáticos
  • Añadir subentradas de configuración
  • Añadir acuerdos de replicación
  • Certificado Retirar Retención
  • Obtener el estado de los certificados de la CA
  • Rango de lectura del ADN
  • Modificar la gama de ADN
  • Leer la configuración de los gestores de PassSync
  • Modificar la configuración de los gestores de PassSync
  • Leer los acuerdos de replicación
  • Modificar los acuerdos de replicación
  • Eliminar los acuerdos de replicación
  • Leer la configuración de la base de datos LDBM
  • Solicitar certificado
  • Solicitar certificado ignorando las ACL de la CA
  • Solicitar certificados de un host diferente
  • Recuperar certificados de la CA
  • Revocar el certificado
  • Escribir la configuración IPA
Nota

Si intentas modificar un permiso gestionado desde la línea de comandos, el sistema no te permite cambiar los atributos que no puedes modificar, el comando falla. Si intentas modificar un permiso gestionado desde la interfaz web, los atributos que no puedes modificar están desactivados.

21.1.3. Privilegios en IdM

Un privilegio es un grupo de permisos aplicables a un rol.
Mientras que un permiso proporciona los derechos para hacer una sola operación, hay ciertas tareas de IdM que requieren múltiples permisos para tener éxito. Por lo tanto, un privilegio combina los diferentes permisos necesarios para realizar una tarea específica.
Por ejemplo, añadir un usuario requiere los siguientes permisos:

  • Crear una nueva entrada de usuario
  • Restablecer la contraseña de un usuario
  • Añadir el nuevo usuario al grupo de usuarios IPA por defecto

La combinación de estas tres tareas de bajo nivel en una tarea de nivel superior en forma de privilegio denominada Add User facilita la gestión de los roles. Además de usuarios y grupos de usuarios, también se asignan privilegios a hosts y grupos de hosts, así como a servicios de red. Esta práctica permite un control detallado de las operaciones de un conjunto de usuarios en un conjunto de hosts que utilizan servicios de red específicos.

Nota

Un privilegio no puede contener otros privilegios.

21.1.4. Roles en IdM

Un rol es una lista de privilegios que los usuarios especificados para el rol poseen.
En efecto, los permisos conceden la capacidad de realizar determinadas tareas de bajo nivel (crear una entrada de usuario, añadir una entrada a un grupo, etc.), los privilegios combinan uno o más de estos permisos necesarios para una tarea de nivel superior (como crear un nuevo usuario en un grupo determinado). Las funciones reúnen los privilegios necesarios: por ejemplo, una función de administrador de usuarios podría añadir, modificar y eliminar usuarios.

Importante

Los roles se utilizan para clasificar las acciones permitidas. No se utilizan como una herramienta para implementar la separación de privilegios o para proteger de la escalada de privilegios.

Nota

Los roles no pueden contener otros roles.

21.1.5. Funciones predefinidas en la gestión de identidades

Red Hat Identity Management proporciona la siguiente gama de funciones predefinidas:

Tabla 21.1. Roles predefinidos en la gestión de identidades

PapelPrivilegioDescripción

Servicio de asistencia técnica

Modificación de usuarios y restablecimiento de contraseñas, modificación de la pertenencia a grupos

Responsable de realizar tareas sencillas de administración de usuarios

Especialista en seguridad informática

Administradores de Netgroups, Administrador de HBAC, Administrador de Sudo

Responsable de la gestión de la política de seguridad, como los controles de acceso basados en el host, las reglas sudo

Especialista en TI

Administradores de hosts, administradores de grupos de hosts, administradores de servicios, administradores de autómatas

Responsable de la gestión de los anfitriones

Arquitecto de seguridad

Administrador de Delegación, Administradores de Replicación, Configuración IPA de Escritura, Administrador de Políticas de Contraseña

Responsable de la gestión del entorno de gestión de identidades, la creación de fideicomisos, la creación de acuerdos de replicación

Administrador de usuarios

Administradores de usuarios, administradores de grupos, administradores de usuarios de escenario

Responsable de la creación de usuarios y grupos

21.2. Gestión de los permisos de IdM en la CLI

Esta sección describe cómo gestionar los permisos de Gestión de Identidades (IdM) mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  1. Cree nuevas entradas de permisos con el comando ipa permission-add.
    Por ejemplo, para añadir un permiso llamado dns admin:

    $ ipa permission-add \ "dns admin"
  2. Especifique las propiedades del permiso con las siguientes opciones

    • --bindtype especifica el tipo de regla de enlace. Esta opción acepta los argumentos all, anonymous y permission. El permission bindtype significa que sólo los usuarios a los que se les ha concedido este permiso a través de un rol pueden ejercerlo.
      Por ejemplo:

      $ ipa permission-add \ "dns admin" --bindtype=all

      Si no se especifica --bindtype, el valor por defecto es permission.

      Nota

      No es posible añadir permisos con un tipo de regla de vinculación no predeterminado a los privilegios. Tampoco se puede establecer un permiso que ya esté presente en un privilegio con un tipo de regla de vinculación no predeterminado.

    • --right enumera los derechos concedidos por el permiso, sustituye a la opción obsoleta --permissions. Los valores disponibles son add, delete, read, search, compare, write, all.

      Puede establecer varios atributos utilizando varias opciones de --right o con una lista separada por comas dentro de llaves. Por ejemplo:

      $ ipa permission-add \ "dns admin" --right=read --right=write
      $ ipa permission-add \ "dns admin" --right={read,write}
      Nota

      add y delete son operaciones de nivel de entrada (por ejemplo, eliminar un usuario, añadir un grupo, etc.) mientras que read, search, compare y write son más de nivel de atributo: se puede escribir en userCertificate pero no leer userPassword.

    • --attrs proporciona la lista de atributos sobre los que se concede el permiso.
      Puede establecer varios atributos utilizando varias opciones de --attrs o enumerando las opciones en una lista separada por comas dentro de llaves. Por ejemplo:

      $ ipa permission-add \ "dns admin" --attrs=description --attrs=automountKey
      $ ipa permission-add \ "dns admin" --attrs={descripción,automountKey}

      Los atributos proporcionados con --attrs deben existir y ser atributos permitidos para el tipo de objeto dado, de lo contrario el comando falla con errores de sintaxis del esquema.

    • --type define el tipo de objeto de entrada al que se aplica el permiso, como usuario, host o servicio. Cada tipo tiene su propio conjunto de atributos permitidos.
      Por ejemplo:

      $ ipa permission-add \ "manage service" --right=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
    • --subtree proporciona una entrada de subárbol; el filtro se dirige entonces a todas las entradas situadas por debajo de esta entrada de subárbol. Proporcione una entrada de subárbol existente; --subtree no acepta comodines ni nombres de dominio (DN) inexistentes. Incluir un DN dentro del directorio.
      Dado que IdM utiliza una estructura de árbol de directorios plana y simplificada, --subtree puede utilizarse para seleccionar algunos tipos de entradas, como las ubicaciones de montaje automático, que son contenedores o entradas principales para otra configuración. Por ejemplo:

      $ ipa permission-add \ "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --right=write --attrs=nombredelmontajeautomático --attrs=clavedelmontajeautomático --attrs=informacióndelmontajeautomático
      Nota

      Las opciones --type y --subtree se excluyen mutuamente: se puede ver la inclusión de filtros para --type como una simplificación de --subtree, con la intención de facilitar la vida a un administrador.

    • --filter utiliza un filtro LDAP para identificar a qué entradas se aplica el permiso.
      IdM comprueba automáticamente la validez del filtro dado. El filtro puede ser cualquier filtro LDAP válido, por ejemplo:

      $ ipa permission-add \ "administrar grupos de Windows" --filtro="(!(objectclass=posixgroup))\N-" --right=write --attrs=description
    • --memberof establece el filtro de destino para los miembros del grupo dado después de comprobar que el grupo existe. Por ejemplo, para que los usuarios con este permiso puedan modificar el shell de inicio de sesión de los miembros del grupo de ingenieros:

      $ ipa permission-add ManageShell --right="write" --type=user --attr=loginshell --memberof=engineers
    • --targetgroup establece el objetivo en el grupo de usuarios especificado después de comprobar que el grupo existe. Por ejemplo, para permitir que aquellos con el permiso escriban el atributo de miembro en el grupo de ingenieros (para que puedan añadir o eliminar miembros):

      $ ipa permission-add ManageMembers --right="write" --subtree=cn=groups,cn=accounts,dc=example,dc=test --attr=member --targetgroup=engineers
    • Opcionalmente, puede especificar un nombre de dominio (DN) de destino

      • --target especifica el DN al que se aplicará el permiso. Se aceptan comodines.
      • --targetto especifica el subárbol de DN al que se puede mover una entrada.
      • --targetfrom especifica el subárbol de DN desde el que se puede mover una entrada.

21.3. Opciones de comando para los permisos existentes

Utilice las siguientes variantes para modificar los permisos existentes según sea necesario:

  • Para editar los permisos existentes, utilice el comando ipa permission-mod. Puede utilizar las mismas opciones de comando que para añadir permisos.
  • Para encontrar los permisos existentes, utilice el comando ipa permission-find. Puede utilizar las mismas opciones de comando que para añadir permisos.
  • Para ver un permiso específico, utilice el comando ipa permission-show.
    El argumento --raw muestra el ACI 389-ds en bruto que se genera. Por ejemplo:

     $ ipa permission-show <permission> --raw
  • El comando ipa permission-del borra un permiso por completo.

Recursos adicionales

Para más detalles sobre los comandos de ipa permission, consulte la página man de ipa y el comando ipa help.

21.4. Gestión de los privilegios de IdM en la CLI

Esta sección describe cómo gestionar los privilegios de Identity Management (IdM) mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  1. Añada entradas de privilegios utilizando el comando ipa privilege-add.
    Por ejemplo, para añadir un privilegio llamado managing filesystems con una descripción:

    $ ipa privilege-add \ "managing filesystems" --desc="for filesystems"
  2. Asigne los permisos necesarios al grupo de privilegios con el comando privilege-add-permission.
    Por ejemplo, para añadir los permisos denominados managing automount y managing ftp services al privilegio managing filesystems:

    $ ipa privilege-add-permission \ "managing filesystems" --permissions="managing automount" --permissions="managing ftp services"

21.5. Opciones de comando para los privilegios existentes

Utilice las siguientes variantes para modificar los privilegios existentes según sea necesario:

  • Para modificar los privilegios existentes, utilice el comando ipa privilege-mod.
  • Para encontrar los privilegios existentes, utilice el comando ipa privilege-find.
  • Para ver un privilegio específico, utilice el comando ipa privilege-show.
  • El comando ipa privilege-remove-permission elimina uno o más permisos de un privilegio.
  • El comando ipa privilege-del borra un privilegio por completo.

Recursos adicionales

Para más detalles sobre los comandos de ipa privilege, consulte la página man de ipa y el comando ipa help.

21.6. Gestión de los roles de IdM en la CLI

En esta sección se describe cómo gestionar los roles de Identity Management (IdM) mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  1. Añade nuevas entradas de rol utilizando el comando ipa role-add:

    $ ipa role-add --desc="User Administrator" useradmin
    ------------------------
    Added role "useradmin"
    ------------------------
    Role name: useradmin
    Description: User Administrator
  2. Añada los privilegios necesarios al rol utilizando el comando ipa role-add-privilege:

    $ ipa role-add-privilege --privileges="user administrators" useradmin
    Role name: useradmin
    Description: User Administrator
    Privileges: user administrators
    ----------------------------
    Number of privileges added 1
    ----------------------------
  3. Añada los miembros necesarios al rol utilizando el comando ipa role-add-member. Los tipos de miembros permitidos son: usuarios, grupos, hosts y hostgroups.
    Por ejemplo, para añadir el grupo llamado useradmins al rol previamente creado useradmin:

    $ ipa role-add-member --groups=useradmins useradmin
    Role name: useradmin
    Description: User Administrator
    Member groups: useradmins
    Privileges: user administrators
    -------------------------
    Number of members added 1
    -------------------------

21.7. Opciones de mando para los roles existentes

Utilice las siguientes variantes para modificar los roles existentes según sea necesario:

  • Para modificar los roles existentes, utilice el comando ipa role-mod.
  • Para encontrar los roles existentes, utilice el comando ipa role-find.
  • Para ver un rol específico, utilice el comando ipa role-show.
  • Para eliminar un miembro del rol, utilice el comando ipa role-remove-member.
  • El comando ipa role-remove-privilege elimina uno o más privilegios de un rol.
  • El comando ipa role-del borra un rol completamente.

Recursos adicionales

Para más detalles sobre los comandos de ipa role, consulte la página man de ipa y el comando ipa help.

Capítulo 22. Gestión de los controles de acceso basados en funciones mediante la interfaz web de IdM

Este capítulo presenta el control de acceso basado en roles en la Gestión de Identidades (IdM) y describe las siguientes operaciones en la interfaz web (Web UI):

22.1. Control de acceso basado en roles en IdM

El control de acceso basado en roles (RBAC) en IdM otorga un tipo de autoridad muy diferente a los usuarios en comparación con los controles de acceso de autoservicio y de delegación.

El control de acceso basado en roles se compone de tres partes:

  • Permissions concede el derecho a realizar una tarea específica, como añadir o eliminar usuarios, modificar un grupo, habilitar el acceso de lectura, etc.
  • Privileges combina los permisos, por ejemplo, todos los permisos necesarios para añadir un nuevo usuario.
  • Roles concede un conjunto de privilegios a usuarios, grupos de usuarios, hosts o grupos de hosts.

22.1.1. Permisos en IdM

Los permisos son la unidad de nivel más bajo del control de acceso basado en roles, definen las operaciones junto con las entradas LDAP a las que se aplican dichas operaciones. Comparable a los bloques de construcción, los permisos pueden asignarse a tantos privilegios como sea necesario.
Uno o más rights definen qué operaciones están permitidas:

  • write
  • read
  • search
  • compare
  • add
  • delete
  • all

Estas operaciones se aplican a tres direcciones básicas targets:

  • subtree: un nombre de dominio (DN); el subárbol bajo este DN
  • target filter: un filtro LDAP
  • target: DN con posibles comodines para especificar las entradas

Además, las siguientes opciones de conveniencia establecen los atributos correspondientes:

  • type: un tipo de objeto (usuario, grupo, etc.); establece subtree y target filter
  • memberof: miembros de un grupo; establece un target filter
  • targetgroup: concede el acceso para modificar un grupo específico (como la concesión de los derechos para gestionar la pertenencia a un grupo); establece un target

Con los permisos de IdM, puede controlar qué usuarios tienen acceso a qué objetos e incluso a qué atributos de estos objetos. IdM le permite permitir o bloquear atributos individuales o cambiar toda la visibilidad de una función específica de IdM, como usuarios, grupos o sudo, a todos los usuarios anónimos, a todos los usuarios autenticados o sólo a un determinado grupo de usuarios privilegiados.
Por ejemplo, la flexibilidad de este enfoque de los permisos es útil para un administrador que quiere limitar el acceso de los usuarios o grupos sólo a las secciones específicas a las que estos usuarios o grupos necesitan acceder y hacer que las otras secciones estén completamente ocultas para ellos.

Nota

Un permiso no puede contener otros permisos.

22.1.2. Permisos gestionados por defecto

Los permisos gestionados son permisos que vienen por defecto con IdM. Se comportan como otros permisos creados por el usuario, con las siguientes diferencias:

  • No se pueden eliminar ni modificar sus atributos de nombre, ubicación y destino.
  • Tienen tres conjuntos de atributos:

    • Default atributos, el usuario no puede modificarlos, ya que son gestionados por IdM
    • Included atributos, que son atributos adicionales añadidos por el usuario
    • Excluded atributos, que son atributos eliminados por el usuario

Un permiso gestionado se aplica a todos los atributos que aparecen en los conjuntos de atributos predeterminados e incluidos, pero no en el conjunto excluido.

Nota

Aunque no se puede eliminar un permiso gestionado, si se establece su tipo de enlace como permiso y se elimina el permiso gestionado de todos los privilegios, se desactiva de forma efectiva.

Los nombres de todos los permisos gestionados comienzan con System:, por ejemplo System: Add Sudo rule o System: Modify Services. Las versiones anteriores de IdM utilizaban un esquema diferente para los permisos por defecto. Por ejemplo, el usuario no podía eliminarlos y sólo podía asignarlos a los privilegios. La mayoría de estos permisos por defecto se han convertido en permisos gestionados, sin embargo, los siguientes permisos siguen utilizando el esquema anterior:

  • Añadir la tarea de reconstrucción de miembros automáticos
  • Añadir subentradas de configuración
  • Añadir acuerdos de replicación
  • Certificado Retirar Retención
  • Obtener el estado de los certificados de la CA
  • Rango de lectura del ADN
  • Modificar la gama de ADN
  • Leer la configuración de los gestores de PassSync
  • Modificar la configuración de los gestores de PassSync
  • Leer los acuerdos de replicación
  • Modificar los acuerdos de replicación
  • Eliminar los acuerdos de replicación
  • Leer la configuración de la base de datos LDBM
  • Solicitar certificado
  • Solicitar certificado ignorando las ACL de la CA
  • Solicitar certificados de un host diferente
  • Recuperar certificados de la CA
  • Revocar el certificado
  • Escribir la configuración IPA
Nota

Si intentas modificar un permiso gestionado desde la línea de comandos, el sistema no te permite cambiar los atributos que no puedes modificar, el comando falla. Si intentas modificar un permiso gestionado desde la interfaz web, los atributos que no puedes modificar están desactivados.

22.1.3. Privilegios en IdM

Un privilegio es un grupo de permisos aplicables a un rol.
Mientras que un permiso proporciona los derechos para hacer una sola operación, hay ciertas tareas de IdM que requieren múltiples permisos para tener éxito. Por lo tanto, un privilegio combina los diferentes permisos necesarios para realizar una tarea específica.
Por ejemplo, añadir un usuario requiere los siguientes permisos:

  • Crear una nueva entrada de usuario
  • Restablecer la contraseña de un usuario
  • Añadir el nuevo usuario al grupo de usuarios IPA por defecto

La combinación de estas tres tareas de bajo nivel en una tarea de nivel superior en forma de privilegio denominada Add User facilita la gestión de los roles. Además de usuarios y grupos de usuarios, también se asignan privilegios a hosts y grupos de hosts, así como a servicios de red. Esta práctica permite un control detallado de las operaciones de un conjunto de usuarios en un conjunto de hosts que utilizan servicios de red específicos.

Nota

Un privilegio no puede contener otros privilegios.

22.1.4. Roles en IdM

Un rol es una lista de privilegios que los usuarios especificados para el rol poseen.
En efecto, los permisos conceden la capacidad de realizar determinadas tareas de bajo nivel (crear una entrada de usuario, añadir una entrada a un grupo, etc.), los privilegios combinan uno o más de estos permisos necesarios para una tarea de nivel superior (como crear un nuevo usuario en un grupo determinado). Las funciones reúnen los privilegios necesarios: por ejemplo, una función de administrador de usuarios podría añadir, modificar y eliminar usuarios.

Importante

Los roles se utilizan para clasificar las acciones permitidas. No se utilizan como una herramienta para implementar la separación de privilegios o para proteger de la escalada de privilegios.

Nota

Los roles no pueden contener otros roles.

22.1.5. Funciones predefinidas en la gestión de identidades

Red Hat Identity Management proporciona la siguiente gama de funciones predefinidas:

Tabla 22.1. Roles predefinidos en la gestión de identidades

PapelPrivilegioDescripción

Servicio de asistencia técnica

Modificación de usuarios y restablecimiento de contraseñas, modificación de la pertenencia a grupos

Responsable de realizar tareas sencillas de administración de usuarios

Especialista en seguridad informática

Administradores de Netgroups, Administrador de HBAC, Administrador de Sudo

Responsable de la gestión de la política de seguridad, como los controles de acceso basados en el host, las reglas sudo

Especialista en TI

Administradores de hosts, administradores de grupos de hosts, administradores de servicios, administradores de autómatas

Responsable de la gestión de los anfitriones

Arquitecto de seguridad

Administrador de Delegación, Administradores de Replicación, Configuración IPA de Escritura, Administrador de Políticas de Contraseña

Responsable de la gestión del entorno de gestión de identidades, la creación de fideicomisos, la creación de acuerdos de replicación

Administrador de usuarios

Administradores de usuarios, administradores de grupos, administradores de usuarios de escenario

Responsable de la creación de usuarios y grupos

22.2. Gestión de permisos en la interfaz web de IdM

Esta sección describe cómo gestionar los permisos en la Gestión de identidades (IdM) mediante la interfaz web (IdM Web UI).

Requisitos previos

Procedimiento

  1. Para añadir un nuevo permiso, abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Permissions:

    Tarea de permisos

  2. Se abre la lista de permisos: Haga clic en el botón Add en la parte superior de la lista de los permisos:

    Añadir un nuevo permiso

  3. Se abre el formulario Add Permission. Especifique el nombre del nuevo permiso y defina sus propiedades en consecuencia:

    Formulario para añadir un permiso

  4. Seleccione el tipo de regla de enlace apropiado:

    • permission es el tipo de permiso por defecto, que otorga acceso a través de privilegios y roles
    • all especifica que el permiso se aplica a todos los usuarios autentificados
    • anonymous especifica que el permiso se aplica a todos los usuarios, incluidos los no autentificados

      Nota

      No es posible añadir permisos con un tipo de regla de vinculación no predeterminado a los privilegios. Tampoco se puede establecer un permiso que ya esté presente en un privilegio con un tipo de regla de vinculación no predeterminado.

  5. Elija los derechos a conceder con este permiso en Granted rights.
  6. Definir el método para identificar las entradas de destino para el permiso:

    • Type especifica un tipo de entrada, como usuario, host o servicio. Si se elige un valor para el ajuste Type, en Effective Attributes aparece una lista de todos los posibles atributos a los que se podrá acceder a través de este ACI para ese tipo de entrada. Si se define Type, se establece Subtree y Target DN a uno de los valores predefinidos.
    • Subtree (obligatorio) especifica una entrada de subárbol; todas las entradas por debajo de esta entrada de subárbol son el objetivo. Proporcione una entrada de subárbol existente, ya que Subtree no acepta comodines ni nombres de dominio (DN) inexistentes. Por ejemplo cn=automount,dc=example,dc=com
    • Extra target filter utiliza un filtro LDAP para identificar a qué entradas se aplica el permiso. El filtro puede ser cualquier filtro LDAP válido, por ejemplo: (!(objectclass=posixgroup))
      IdM comprueba automáticamente la validez del filtro dado. Si introduces un filtro no válido, IdM te advierte de ello cuando intentas guardar el permiso.
    • Target DN especifica el nombre de dominio (DN) y acepta comodines. Por ejemplo uid=*,cn=users,cn=accounts,dc=com
    • Member of group establece el filtro de destino a los miembros del grupo dado. Después de especificar la configuración del filtro y hacer clic en Add, IdM valida el filtro. Si todos los ajustes de permisos son correctos, IdM realizará la búsqueda. Si alguna de las configuraciones de permisos es incorrecta, IdM mostrará un mensaje informando sobre qué configuración es incorrecta.
  7. Añadir atributos al permiso:

    • Si establece Type, elija el Effective attributes de la lista de atributos ACI disponibles.
    • Si no ha utilizado Type, añada los atributos manualmente escribiéndolos en el campo Effective attributes. Añada un solo atributo a la vez; para añadir varios atributos, haga clic en Add para añadir otro campo de entrada.

      Importante

      Si no establece ningún atributo para el permiso, éste incluye todos los atributos por defecto.

  8. Termine de añadir los permisos con los botones de Add en la parte inferior del formulario:

    • Haga clic en el botón Add para guardar el permiso y volver a la lista de permisos.
    • También puede guardar el permiso y continuar añadiendo permisos adicionales en el mismo formulario haciendo clic en el botón Add and Add another
    • El botón Add and Edit le permite guardar y continuar editando el permiso recién creado.
  9. Optional. También puede editar las propiedades de un permiso existente haciendo clic en su nombre de la lista de permisos para mostrar la página Permission settings.
  10. Optional. Si necesita eliminar un permiso existente, haga clic en el botón Delete una vez que haya marcado la casilla junto a su nombre en la lista, para mostrar el cuadro de diálogo Remove permissions.

    Nota

    Las operaciones en los permisos gestionados por defecto están restringidas: los atributos que no puede modificar están desactivados en la interfaz web de IdM y no puede eliminar los permisos gestionados por completo.
    Sin embargo, puede desactivar efectivamente un permiso gestionado que tenga un tipo de enlace establecido como permiso, eliminando el permiso gestionado de todos los privilegios.

Por ejemplo, para permitir a los que tienen el permiso escribir el atributo de miembro en el grupo de ingenieros (para que puedan añadir o eliminar miembros):
Ejemplo para añadir un permiso

22.3. Gestión de privilegios en la IdM WebUI

Esta sección describe cómo gestionar los privilegios en IdM mediante la interfaz web (IdM Web UI).

Requisitos previos

Procedimiento

  1. Para añadir un nuevo privilegio, abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Privileges:

    Tarea de privilegios

  2. Se abre la lista de privilegios. Haga clic en el botón Add en la parte superior de la lista de privilegios:

    Añadir un nuevo privilegio

  3. Se abre el formulario Add Privilege. Introduzca el nombre y una descripción del privilegio:

    Formulario para añadir un privilegio

  4. Haga clic en el botón Add and Edit para guardar el nuevo privilegio y continuar con la página de configuración de privilegios para añadir permisos.
  5. Edite las propiedades de los privilegios haciendo clic en el nombre del privilegio en la lista de privilegios. Se abre la página de configuración de privilegios.
  6. La pestaña Permissions muestra una lista de permisos incluidos en el privilegio seleccionado. Haga clic en el botón Add situado en la parte superior de la lista para añadir permisos al privilegio:

    Añadir permisos

  7. Marque la casilla junto al nombre de cada permiso que desee añadir y utilice el botón > para mover los permisos a la columna Prospective:

    Selección de permisos

  8. Confirme haciendo clic en el botón Add.
  9. Optional. Si necesita eliminar permisos, haga clic en el botón Delete después de marcar la casilla de verificación junto al permiso correspondiente: se abre el cuadro de diálogo Remove privileges from permissions.
  10. Optional. Si necesita eliminar un privilegio existente, haga clic en el botón Delete después de marcar la casilla de verificación junto a su nombre en la lista: se abre el diálogo Remove privileges.

22.4. Gestión de funciones en la interfaz web de IdM

Esta sección describe cómo gestionar los roles en la Gestión de Identidades (IdM) mediante la interfaz web (IdM Web UI).

Requisitos previos

Procedimiento

  1. Para añadir un nuevo rol, abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Roles:

    Tarea de roles

  2. Se abre la lista de roles. Haga clic en el botón Add en la parte superior de la lista de las instrucciones de control de acceso basado en roles.

    Añadir un nuevo rol

  3. Se abre el formulario Add Role. Introduzca el nombre de la función y una descripción:

    Formulario para añadir un rol

  4. Haga clic en el botón Add and Edit para guardar el nuevo rol y vaya a la página de configuración de roles para añadir privilegios y usuarios.
  5. Edite las propiedades de los roles haciendo clic en el nombre del rol en la lista de roles. Se abre la página de configuración de roles.
  6. Añada miembros utilizando las pestañas Users, Users Groups, Hosts, Host Groups o Services, haciendo clic en el botón Add en la parte superior de la(s) lista(s) correspondiente(s).

    Añadir usuarios

  7. En la ventana que se abre, seleccione los miembros de la izquierda y utilice el botón > para moverlos a la columna Prospective.

    Selección de usuarios

  8. En la parte superior de la pestaña Privileges, haga clic en Add.

    Añadir privilegios

  9. Seleccione los privilegios de la izquierda y utilice el botón > para moverlos a la columna Prospective.

    Selección de privilegios

  10. Haga clic en el botón Add para guardar.
  11. Optional. Si necesita eliminar privilegios o miembros de un rol, haga clic en el botón Delete después de marcar la casilla de verificación junto al nombre de la entidad que desea eliminar. Se abrirá un cuadro de diálogo.
  12. Optional. Si necesita eliminar un rol existente, haga clic en el botón Delete después de marcar la casilla de verificación junto a su nombre en la lista, para mostrar el diálogo Remove roles.

Capítulo 23. Uso de una vista de identificación para anular el valor de un atributo de usuario en un cliente IdM

Si un usuario de Gestión de identidades (IdM) desea anular algunos de sus atributos de usuario o grupo almacenados en el servidor LDAP de IdM, por ejemplo, el nombre de inicio de sesión, el directorio principal, el certificado utilizado para la autenticación o las claves de SSH, usted, como administrador de IdM, puede redefinir estos valores para un cliente de IdM específico, utilizando las vistas de IdM ID. Por ejemplo, puede especificar un directorio de inicio diferente para un usuario en el cliente IdM que el usuario utiliza más comúnmente para iniciar sesión en IdM.

Este capítulo describe cómo redefinir un valor de atributo POSIX asociado a un usuario de IdM en un host inscrito en IdM como cliente. En concreto, el capítulo describe cómo redefinir el nombre de inicio de sesión del usuario y el directorio raíz.

Este capítulo incluye las siguientes secciones:

23.1. Vistas de identificación

Una vista de ID en la gestión de identidades (IdM) es una vista del lado del cliente de IdM que especifica la siguiente información:

  • Nuevos valores para los atributos de usuario o grupo POSIX definidos de forma centralizada
  • El host o los hosts cliente en los que se aplican los nuevos valores.

Una vista de ID contiene una o más anulaciones. Un override es un reemplazo específico de un valor de atributo POSIX definido centralmente.

Sólo se puede definir una vista de ID para un cliente IdM de forma centralizada en los servidores IdM. No se pueden configurar anulaciones del lado del cliente para un cliente IdM de forma local.

Por ejemplo, puede utilizar las vistas de ID para lograr los siguientes objetivos:

  • Defina diferentes valores de atributos para diferentes entornos. Por ejemplo, puede permitir que el administrador de IdM u otro usuario de IdM tenga diferentes directorios personales en diferentes clientes de IdM: puede configurar /home/encrypted/username para que sea el directorio personal de este usuario en un cliente de IdM y /dropbox/username en otro cliente. El uso de las vistas de ID en esta situación es conveniente, ya que de lo contrario, por ejemplo, el cambio de fallback_homedir, override_homedir u otras variables de directorio personal en el archivo /etc/sssd/sssd.conf del cliente afectaría a todos los usuarios. Véase Añadir una vista de ID para anular el directorio principal de un usuario IdM en un cliente IdM para ver un procedimiento de ejemplo.
  • Reemplazar un valor de atributo generado previamente con un valor diferente, como anular el UID de un usuario. Esta capacidad puede ser útil cuando se quiere lograr un cambio en todo el sistema que de otro modo sería difícil de hacer en el lado de LDAP, por ejemplo, hacer 1009 el UID de un usuario IdM. Los rangos de ID de IdM, que se utilizan para generar un UID de usuario de IdM, nunca comienzan tan bajos como 1000 o incluso 10000. Si existe una razón para que un usuario de IdM suplante a un usuario local con UID 1009 en todos los clientes de IdM, puede utilizar las vistas de ID para anular el UID de este usuario de IdM que se generó cuando se creó el usuario en IdM.
Importante

Sólo se pueden aplicar vistas de ID a los clientes de IdM, no a los servidores de IdM.

Recursos adicionales

  • También puede utilizar las vistas de ID en entornos que incluyan Active Directory (AD). Para obtener más detalles, consulte el capítulo Vistas de ID y migración de entornos existentes a la confianza en el Windows integration guide.
  • También puede configurar vistas de ID para hosts que no forman parte de un dominio de gestión de identidades centralizado. Para más detalles, consulte el capítulo Vistas del lado del cliente de SSSD en la guía System-level authentication guide.

23.2. Posible impacto negativo de las opiniones de ID en el rendimiento del SSSD

Cuando se define una vista de ID, IdM coloca el valor de anulación deseado en la caché del demonio de servicios de seguridad del sistema (SSSD) del servidor de IdM. El SSSD que se ejecuta en un cliente de IdM recupera entonces el valor de anulación de la caché del servidor.

La aplicación de una vista de ID puede tener un impacto negativo en el rendimiento del demonio de servicios de seguridad del sistema (SSSD), porque ciertas optimizaciones y vistas de ID no pueden ejecutarse al mismo tiempo. Por ejemplo, las vistas de ID impiden que SSSD optimice el proceso de búsqueda de grupos en el servidor:

  • Con las vistas de ID, SSSD debe comprobar cada miembro en la lista devuelta de nombres de miembros del grupo si el nombre del grupo está anulado.
  • Sin las vistas de ID, SSSD sólo puede recoger los nombres de usuario del atributo de miembro del objeto de grupo.

Este efecto negativo se hace más evidente cuando la caché de SSSD está vacía o después de borrar la caché, lo que hace que todas las entradas sean inválidas.

23.3. Atributos que una vista de identificación puede anular

Las vistas de ID consisten en anulaciones de ID de usuario y de grupo. Las anulaciones definen los nuevos valores de atributos POSIX.

Las anulaciones de ID de usuario y grupo pueden definir nuevos valores para los siguientes atributos POSIX:

Atributos del usuario
  • Nombre de usuario (uid)
  • Entrada de GECOS (gecos)
  • Número de UID (uidNumber)
  • Número GID (gidNumber)
  • Shell de inicio de sesión (loginShell)
  • Directorio de inicio (homeDirectory)
  • Claves públicas SSH (ipaSshPubkey)
  • Certificado (userCertificate)
Atributos del grupo
  • Nombre del grupo (cn)
  • Número de GID del grupo (gidNumber)

23.4. Obtención de ayuda para los comandos de la vista de identificación

Puede obtener ayuda para los comandos relacionados con las vistas de ID de Identity Management (IdM) en la interfaz de línea de comandos (CLI) de IdM.

Requisitos previos

  • Ha obtenido un ticket Kerberos para un usuario IdM.

Procedimiento

  • Para mostrar todos los comandos utilizados para gestionar las vistas y anulaciones de ID:

    $ ipa help idviews
    ID Views
    
    Manage ID Views
    
    IPA allows to override certain properties of users and groups[...]
    [...]
    Topic commands:
      idoverridegroup-add          Add a new Group ID override
      idoverridegroup-del          Delete a Group ID override
    [...]
  • Para mostrar la ayuda detallada de un comando concreto, añada la opción --help al comando:

    $ ipa idview-add --help
    Usage: ipa [global-options] idview-add NAME [options]
    
    Add a new ID View.
    Options:
      -h, --help      show this help message and exit
      --desc=STR      Description
    [...]

23.5. Uso de una vista de ID para anular el nombre de inicio de sesión de un usuario de IdM en un host específico

Esta sección describe cómo crear una vista de ID para un cliente de gestión de identidades (IdM) específico que anule un valor de atributo POSIX asociado a un usuario IdM específico. El procedimiento utiliza el ejemplo de una vista de ID que permite a un usuario de IdM llamado idm_user iniciar sesión en un cliente de IdM llamado host1 utilizando el nombre de inicio de sesión user_1234.

Requisitos previos

  • Está conectado como un usuario con los privilegios necesarios, por ejemplo admin.

Procedimiento

  1. Cree una nueva vista de identificación. Por ejemplo, para crear una vista de ID llamada example_for_host1:

    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  2. Añada una anulación de usuario a la vista de ID de example_for_host1. Para anular el inicio de sesión del usuario:

    • Introduzca el comando ipa idoverrideuser-add
    • Añadir el nombre de la vista de identificación
    • Añade el nombre del usuario, también llamado ancla
    • Añade la opción --login:

      $ ipa idoverrideuser-add example_for_host1 idm_user --login=user_1234
      -----------------------------
      Added User ID override "idm_user"
      -----------------------------
        Anchor to override: idm_user
        User login: user_1234

      Para obtener una lista de las opciones disponibles, ejecute ipa idoverrideuser-add --help.

      Nota

      El comando ipa idoverrideuser-add --certificate reemplaza todos los certificados existentes para la cuenta en la vista de ID especificada. Para añadir un certificado adicional, utilice el comando ipa idoverrideuser-add-cert:

      $ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
  3. Opcional: Utilizando el comando ipa idoverrideuser-mod, puede especificar nuevos valores de atributos para una anulación de usuario existente.
  4. Aplicar example_for_host1 al host host1.idm.example.com:

    $ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    Nota

    El comando ipa idview-apply también acepta la opción --hostgroups. La opción aplica la vista de ID a los hosts que pertenecen al grupo de hosts especificado, pero no asocia la vista de ID con el grupo de hosts en sí. En cambio, la opción --hostgroups expande los miembros del grupo de hosts especificado y aplica la opción --hosts individualmente a cada uno de ellos.

    Esto significa que si se añade un host al grupo de hosts en el futuro, la vista de ID no se aplica al nuevo host.

  5. Para aplicar la nueva configuración al sistema host1.idm.example.com inmediatamente:

    1. SSH al sistema como root:

      $ ssh root@host1
      Password:
    2. Borrar la caché de SSSD:

      root@host1 ~]# sss_cache -E
    3. Reinicie el demonio SSSD:
    root@host1 ~]# systemctl restart sssd

Pasos de verificación

  • Si tienes las credenciales de user_1234, puedes usarlas para iniciar sesión en IdM en host1:

    1. SSH a host1 usando user_1234 como nombre de inicio de sesión:

      [root@r8server ~]# ssh user_1234@host1.idm.example.com
      Password:
      
      Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
      [user_1234@host1 ~]$
    2. Muestra el directorio de trabajo:

      [user_1234@host1 ~]$ pwd
      /home/idm_user/
  • Alternativamente, si tiene credenciales de root en host1, puede utilizarlas para comprobar la salida del comando id para idm_user y user_1234:

    [root@host1 ~]# id idm_user
    uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)
    [root@host1 ~]# user_1234
    uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)

23.6. Modificación de una vista IdM ID

Una vista de ID en Gestión de Identidades (IdM) anula un valor de atributo POSIX asociado a un usuario específico de IdM. Esta sección describe cómo modificar una vista de ID existente. En concreto, se describe cómo modificar una vista de ID para permitir que el usuario llamado idm_user utilice el directorio /home/user_1234/ como directorio principal del usuario en lugar de /home/idm_user/ en el cliente IdM host1.idm.example.com.

Requisitos previos

  • Tienes acceso de root a host1.idm.example.com.
  • Está conectado como un usuario con los privilegios necesarios, por ejemplo admin.
  • Tiene una vista de ID configurada para idm_user que se aplica al cliente host1 IdM.

Procedimiento

  1. Como root, cree el directorio que desea que idm_user utilice en host1.idm.example.com como directorio principal del usuario:

    [root@host1 /]# mkdir /home/user_1234/
  2. Cambia la propiedad del directorio:

    [root@host1 /]# chown idm_user:idm_user /home/user_1234/
  3. Muestra la vista de ID, incluyendo los hosts a los que se aplica actualmente la vista de ID. Para mostrar la vista de ID denominada example_for_host1:

    $ ipa idview-show example_for_host1 --all
      dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
      ID View Name: example_for_host1
      User object override: idm_user
      Hosts the view applies to: host1.idm.example.com
      objectclass: ipaIDView, top, nsContainer

    La salida muestra que la vista de ID se aplica actualmente a host1.idm.example.com.

  4. Modificar la anulación del usuario de la vista example_for_host1 ID. Para anular el directorio de inicio del usuario:

    • Introduzca el comando ipa idoverrideuser-add
    • Añadir el nombre de la vista de identificación
    • Añade el nombre del usuario, también llamado ancla
    • Añade la opción --homedir:

      $ ipa idoverrideuser-mod example_for_host1 idm_user --homedir=/home/user_1234
      -----------------------------
      Modified an User ID override "idm_user"
      -----------------------------
        Anchor to override: idm_user
        User login: user_1234
        Home directory: /home/user_1234/

    Para ver una lista de las opciones disponibles, ejecute ipa idoverrideuser-mod --help.

  5. Para aplicar la nueva configuración al sistema host1.idm.example.com inmediatamente:

    1. SSH al sistema como root:

      $ ssh root@host1
      Password:
    2. Borrar la caché de SSSD:

      root@host1 ~]# sss_cache -E
    3. Reinicie el demonio SSSD:
    root@host1 ~]# systemctl restart sssd

Pasos de verificación

  1. SSH a host1 como idm_user:

    [root@r8server ~]# ssh idm_user@host1.idm.example.com
    Password:
    
    Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
    [user_1234@host1 ~]$
  2. Imprime el directorio de trabajo:

    [user_1234@host1 ~]$ pwd
    /home/user_1234/

23.7. Añadir una vista de ID para anular el directorio principal de un usuario de IdM en un cliente de IdM

Una vista de ID en la gestión de identidades (IdM) anula un valor de atributo POSIX asociado a un usuario IdM específico. En esta sección se describe cómo crear una vista de ID que se aplique a idm_user en un cliente IdM llamado host1 para que el usuario pueda utilizar el directorio /home/user_1234/ como directorio principal del usuario en lugar de /home/idm_user/.

Requisitos previos

  • Tienes acceso de root a host1.idm.example.com.
  • Está conectado como un usuario con los privilegios necesarios, por ejemplo admin.

Procedimiento

  1. Como root, cree el directorio que desea que idm_user utilice en host1.idm.example.com como directorio principal del usuario:

    [root@host1 /]# mkdir /home/user_1234/
  2. Cambia la propiedad del directorio:

    [root@host1 /]# chown idm_user:idm_user /home/user_1234/
  3. Cree una vista de identificación. Por ejemplo, para crear una vista de ID llamada example_for_host1:

    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  4. Añada una anulación de usuario a la vista de ID de example_for_host1. Para anular el directorio de inicio del usuario:

    • Introduzca el comando ipa idoverrideuser-add
    • Añadir el nombre de la vista de identificación
    • Añade el nombre del usuario, también llamado ancla
    • Añade la opción --homedir:
    $ ipa idoverrideuser-add example_for_host1 idm_user --homedir=/home/user_1234
    -----------------------------
    Added User ID override "idm_user"
    -----------------------------
      Anchor to override: idm_user
      Home directory: /home/user_1234/
  5. Aplicar example_for_host1 al host host1.idm.example.com:

    $ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    Nota

    El comando ipa idview-apply también acepta la opción --hostgroups. La opción aplica la vista de ID a los hosts que pertenecen al grupo de hosts especificado, pero no asocia la vista de ID con el grupo de hosts en sí. En cambio, la opción --hostgroups expande los miembros del grupo de hosts especificado y aplica la opción --hosts individualmente a cada uno de ellos.

    Esto significa que si se añade un host al grupo de hosts en el futuro, la vista de ID no se aplica al nuevo host.

  6. Para aplicar la nueva configuración al sistema host1.idm.example.com inmediatamente:

    1. SSH al sistema como root:

      $ ssh root@host1
      Password:
    2. Borrar la caché de SSSD:

      root@host1 ~]# sss_cache -E
    3. Reinicie el demonio SSSD:
    root@host1 ~]# systemctl restart sssd

Pasos de verificación

  1. SSH a host1 como idm_user:

    [root@r8server ~]# ssh idm_user@host1.idm.example.com
    Password:
    Activate the web console with: systemctl enable --now cockpit.socket
    
    Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
    [idm_user@host1 /]$
  2. Imprime el directorio de trabajo:

    [idm_user@host1 /]$ pwd
    /home/user_1234/

23.8. Aplicación de una vista de ID a un grupo de hosts de IdM

El comando ipa idview-apply acepta la opción --hostgroups. Sin embargo, la opción actúa como una operación única que aplica la vista de ID a los hosts que actualmente pertenecen al grupo de hosts especificado, pero no asocia dinámicamente la vista de ID con el propio grupo de hosts. La opción --hostgroups expande los miembros del grupo de hosts especificado y aplica la opción --hosts individualmente a cada uno de ellos.

Si más tarde añade un nuevo host al grupo de hosts, debe aplicar la vista de ID al nuevo host manualmente, utilizando el comando ipa idview-apply con la opción --hosts.

Del mismo modo, si se elimina un host de un grupo de hosts, la vista de ID se sigue asignando al host después de la eliminación. Para desasignar la vista de ID del host eliminado, debe ejecutar el comando ipa idview-unapply id_view_name --hosts=name_of_the_removed_host comando.

Esta sección describe cómo lograr los siguientes objetivos:

  1. Cómo crear un grupo de hosts y añadir hosts a él.
  2. Cómo aplicar una vista de identificación al grupo de hosts.
  3. Cómo añadir un nuevo host al grupo de hosts y aplicar la vista de ID al nuevo host.

Requisitos previos

Procedimiento

  1. Cree un grupo de hosts y añada hosts a él:

    1. Cree un grupo de hosts. Por ejemplo, para crear un grupo de hosts llamado baltimore:

      [root@master ~]# ipa hostgroup-add --desc="Baltimore hosts" baltimore
      ---------------------------
      Added hostgroup "baltimore"
      ---------------------------
      Host-group: baltimore
      Description: Baltimore hosts
    2. Añade hosts al grupo de hosts. Por ejemplo, para añadir el host102 y host103 al grupo de hosts baltimore:

      [root@master ~]# ipa hostgroup-add-member --hosts={host102,host103} baltimore
      Host-group: baltimore
      Description: Baltimore hosts
      Member hosts: host102.idm.example.com, host103.idm.example.com
      -------------------------
      Number of members added 2
      -------------------------
  2. Aplicar una vista de ID a los hosts del grupo de hosts. Por ejemplo, para aplicar la vista de ID example_for_host1 al grupo de hosts baltimore:

    [root@master ~]# ipa idview-apply --hostgroups=baltimore
    ID View Name: example_for_host1
    -----------------------------------------
    Applied ID View "example_for_host1"
    -----------------------------------------
      hosts: host102.idm.example.com, host103.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 2
    ---------------------------------------------
  3. Añade un nuevo host al grupo de hosts y aplica la vista de ID al nuevo host:

    1. Añade un nuevo host al grupo de hosts. Por ejemplo, para añadir el host somehost.idm.example.com al grupo de hosts baltimore:

      [root@master ~]# ipa hostgroup-add-member --hosts=somehost.idm.example.com baltimore
        Host-group: baltimore
        Description: Baltimore hosts
        Member hosts:  host102.idm.example.com, host103.idm.example.com,somehost.idm.example.com
      -------------------------
      Number of members added 1
      -------------------------
    2. Opcionalmente, muestre la información de la vista ID. Por ejemplo, para mostrar los detalles sobre la vista ID de example_for_host1:

      [root@master ~]# ipa idview-show example_for_host1 --all
        dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
        ID View Name: example_for_host1
      [...]
        Hosts the view applies to: host102.idm.example.com, host103.idm.example.com
        objectclass: ipaIDView, top, nsContainer

      La salida muestra que la vista de ID no se aplica a somehost.idm.example.com, el host recién agregado en el grupo de hosts baltimore.

    3. Aplique la vista de ID al nuevo host. Por ejemplo, para aplicar la vista de ID de example_for_host1 a somehost.idm.example.com:

      [root@master ~]# ipa idview-apply --host=somehost.idm.example.com
      ID View Name: example_for_host1
      -----------------------------------------
      Applied ID View "example_for_host1"
      -----------------------------------------
        hosts: somehost.idm.example.com
      ---------------------------------------------
      Number of hosts the ID View was applied to: 1
      ---------------------------------------------

Pasos de verificación

  • Vuelva a mostrar la información de la vista de identificación:

    [root@master ~]# ipa idview-show example_for_host1 --all
      dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
      ID View Name: example_for_host1
    [...]
      Hosts the view applies to: host102.idm.example.com, host103.idm.example.com, somehost.idm.example.com
      objectclass: ipaIDView, top, nsContainer

    La salida muestra que la vista de ID se aplica ahora a somehost.idm.example.com, el host recién añadido en el grupo de hosts baltimore.

Capítulo 24. Ajuste manual de los rangos de identificación

Un maestro de IdM genera números de identificación de usuario (UID) y de grupo (GID) únicos. Al crear y asignar diferentes rangos de ID a las réplicas, también se asegura de que nunca generen los mismos números de ID. Por defecto, este proceso es automático. Sin embargo, puede ajustar manualmente el rango de ID de IdM durante la instalación del maestro de IdM, o definir manualmente el rango de ID de ADN de una réplica.

24.1. Rangos de identificación

Los números de identificación se dividen en ID ranges. Mantener rangos numéricos separados para servidores individuales y réplicas elimina la posibilidad de que un número de identificación emitido para una entrada ya sea utilizado por otra entrada en otro servidor o réplica.

Tenga en cuenta que hay dos tipos distintos de rangos de ID:

  • El rango de ID de IdM, que se asigna durante la instalación del maestro de IdM. Este rango no puede ser modificado después de su creación. Sin embargo, si lo necesita, puede crear un nuevo rango de IdM ID además del original. Para obtener más información, consulte Asignación automática de ran gos de ID y Adición de un nuevo rango de ID de IdM.
  • Los rangos de ID de asignación numérica distribuida (DNA), que pueden ser modificados por el usuario. Estos tienen que encajar dentro de un rango de ID de IdM existente. Para obtener más información, consulte Ajuste manual de los rangos de ID de ADN.

    Las réplicas también pueden tener asignado un rango de ID de ADN next. Una réplica utiliza su siguiente rango cuando se le acaban los ID de su rango actual. Los siguientes rangos se asignan automáticamente cuando se elimina una réplica o se pueden establecer manualmente.

Los rangos son actualizados y compartidos entre el maestro y las réplicas por el plug-in DNA, como parte de la instancia del servidor de directorio del dominio.

La definición del rango de ADN se establece mediante dos atributos: el siguiente número disponible del servidor (el extremo inferior del rango de ADN) y su valor máximo (el extremo superior del rango de ADN). El rango inferior inicial se establece durante la configuración de la instancia del plug-in. Después, el plug-in actualiza el valor inferior. La división de los números disponibles en rangos permite a los servidores asignar continuamente números sin que se solapen unos con otros.

24.2. Asignación automática de rangos de ID

Por defecto, se asigna automáticamente un rango de ID de IdM durante la instalación del maestro de IdM. El comando ipa-server-install selecciona y asigna aleatoriamente un rango de 200.000 IDs de un total de 10.000 rangos posibles. La selección de un rango aleatorio de este modo reduce significativamente la probabilidad de que se produzcan conflictos de ID en caso de que decida fusionar dos dominios IdM separados en el futuro.

Nota

Este rango de ID de IdM no puede modificarse después de su creación. Sólo puede ajustar manualmente los rangos de ID de Asignación Numérica Distribuida (DNA), utilizando los comandos descritos en Ajuste manual de los rangos de ID de DNA. Durante la instalación se crea automáticamente un rango de ADN que coincide con el rango de ID de IdM.

Si tiene un único servidor IdM instalado, éste controla todo el rango de ID de ADN. Cuando se instala una nueva réplica y la réplica solicita su propio rango de ID de ADN, el rango de ID inicial del maestro se divide y se distribuye entre el maestro y la réplica: la réplica recibe la mitad del rango de ID de ADN restante que está disponible en el maestro inicial. El maestro y la réplica utilizan entonces sus respectivas porciones del rango de ID original para las nuevas entradas de usuarios o grupos. Además, si la réplica está a punto de agotar su rango de IDs asignado y quedan menos de 100 IDs, la réplica se pone en contacto con los otros servidores disponibles para solicitar un nuevo rango de IDs de ADN.

Importante

Cuando se instala una réplica, ésta does not recibe inmediatamente un rango de ID. Una réplica recibe un rango de ID la primera vez que se utiliza el plug-in de DNA, por ejemplo cuando se añade un usuario por primera vez. Hasta entonces, la réplica no tiene un rango de ID definido.

Si el maestro inicial deja de funcionar antes de que la réplica le solicite un rango de ID de ADN, la réplica no puede contactar con el maestro para solicitar el rango de ID. El intento de añadir un nuevo usuario en la réplica falla entonces. En tales situaciones, puede averiguar qué rango de ID está asignado al maestro inhabilitado, y asignar un rango de ID a la réplica manualmente.

24.3. Asignación manual del rango de ID de IdM durante la instalación del servidor

Puede anular el comportamiento predeterminado y establecer un rango de ID de IdM manualmente en lugar de que se asigne al azar.

Importante

No establezca rangos de ID que incluyan valores de UID de 1000 e inferiores; estos valores están reservados para el uso del sistema. Tampoco establezca un rango de ID que incluya el valor 0; el servicio SSSD no maneja el valor 0 de ID.

Procedimiento

  • Puede definir el rango de ID de IdM manualmente durante la instalación del servidor utilizando las dos opciones siguientes con ipa-server-install:

    • --idstart da el valor inicial de los números UID y GID.
    • --idmax da el número máximo de UID y GID; por defecto, el valor es el valor inicial de --idstart más 199.999.

Pasos de verificación

  • Para comprobar si el rango de ID se ha asignado correctamente, puede mostrar el rango de ID de IdM asignado utilizando el comando ipa idrange-find:

    # ipa idrange-find
    ---------------
    1 range matched
    ---------------
      Range name: IDM.EXAMPLE.COM_id_range
      First Posix ID of the range: 882200000
      Number of IDs in the range: 200000
      Range type: local domain range
    ----------------------------
    Number of entries returned 1
    ----------------------------

24.4. Añadir un nuevo rango de IDM

En algunos casos, es posible que desee crear un nuevo rango de IdM ID además del original; por ejemplo, cuando una réplica se ha quedado sin ID y el rango de IdM ID original se ha agotado.

Importante

La adición de un nuevo rango de ID de IdM no crea automáticamente nuevos rangos de ID de ADN. Es necesario asignar manualmente nuevos rangos de ID de ADN según sea necesario. Para obtener más información sobre cómo hacerlo, consulte Ajustar rangos de ID de ADN manualmente.

Procedimiento

  • Para crear un nuevo rango de IDM, utilice el comando ipa idrange-add. Debe especificar el nombre del nuevo rango, el primer número de ID del rango y el tamaño del rango:
# ipa idrange-add IDM.EXAMPLE.COM_new_range --base-id=1000000 --range-size=200000
------------------------------------------
Added ID range "IDM.EXAMPLE.COM_new_range"
------------------------------------------
  Range name: IDM.EXAMPLE.COM_new_range
  First Posix ID of the range: 1000000
  Number of IDs in the range: 200000
  Range type: local domain range

Pasos de verificación

  • Puede comprobar si el nuevo rango está configurado correctamente utilizando el comando ipa idrange-find:
# ipa idrange-find
----------------
2 ranges matched
----------------
  Range name: IDM.EXAMPLE.COM_id_range
  First Posix ID of the range: 882200000
  Number of IDs in the range: 200000
  Range type: local domain range

  Range name: IDM.EXAMPLE.COM_new_range
  First Posix ID of the range: 1000000
  Number of IDs in the range: 200000
  Range type: local domain range
----------------------------
Number of entries returned 2
----------------------------

24.5. Visualización de los rangos de ID de ADN actualmente asignados

Puede mostrar tanto el rango de ID de asignación numérica distribuida (DNA) actualmente activo en un servidor, como su siguiente rango de DNA si tiene uno asignado.

Procedimiento

  • Para mostrar qué rangos de ID de ADN están configurados para los servidores en la topología, utilice los siguientes comandos:

    • ipa-replica-manage dnarange-show muestra el rango de ID de ADN actual que está establecido en todos los servidores o, si se especifica un servidor, sólo en el servidor especificado, por ejemplo:

      # ipa-replica-manage dnarange-show
      masterA.example.com: 1001-1500
      masterB.example.com: 1501-2000
      masterC.example.com: No range set
      
      # ipa-replica-manage dnarange-show masterA.example.com
      masterA.example.com: 1001-1500
    • ipa-replica-manage dnanextrange-show muestra el siguiente rango de ID de ADN establecido actualmente en todos los servidores o, si se especifica un servidor, sólo en el servidor especificado, por ejemplo:

      # ipa-replica-manage dnanextrange-show
      masterA.example.com: 2001-2500
      masterB.example.com: No on-deck range set
      masterC.example.com: No on-deck range set
      
      # ipa-replica-manage dnanextrange-show masterA.example.com
      masterA.example.com: 2001-2500

24.6. Ampliación automática del rango de identificación del ADN

Cuando se elimina una réplica en funcionamiento, el comando ipa-replica-manage del recupera los rangos de ID de ADN que se asignaron a la réplica y los añade como rango siguiente a otra réplica de IdM disponible. Esto garantiza que los rangos de ID de ADN se utilicen de forma eficiente.

Después de eliminar una réplica, puede verificar qué rangos de ID de ADN están configurados para otros servidores utilizando los comandos descritos en Visualización de rangos de ID de ADN actualmente asignados.

24.7. Ajuste manual del rango de identificación del ADN

En ciertas situaciones, es necesario ajustar manualmente un rango de ID de asignación numérica distribuida (DNA), por ejemplo cuando:

  • Una réplica se ha quedado sin IDs y el rango de IDs de IdM se ha agotado

    Una réplica ha agotado el rango de ID de ADN que se le asignó, y la solicitud de ID adicionales ha fallado porque no hay más ID libres en el rango de IdM.

    Para resolver esta situación, amplíe el rango de ID de ADN asignado a la réplica. Puede hacerlo de dos maneras:

    • Acorte el rango de ID de ADN asignado a una réplica diferente, y luego asigne los nuevos valores disponibles a la réplica agotada.
    • Cree un nuevo rango de IdM, y luego establezca un nuevo rango de ID de ADN para la réplica dentro de este rango de IdM creado.

      Para obtener información sobre cómo crear un nuevo rango de IdM ID, consulte Añadir un nuevo rango de IdM ID.

  • Una réplica dejó de funcionar

    El rango de ID de ADN de una réplica no se recupera automáticamente cuando la réplica muere y necesita ser eliminada, lo que significa que el rango de ID de ADN previamente asignado a la réplica no está disponible. Desea recuperar el rango de ID de ADN y ponerlo a disposición de otras réplicas.

    Si desea recuperar un rango de ID de ADN perteneciente a una réplica que dejó de funcionar y asignarlo a otro servidor, primero debe averiguar cuáles son los valores del rango de ID, antes de asignar manualmente dicho rango a un servidor diferente. Además, para evitar la duplicación de UIDs o GIDs, asegúrese de que ningún valor de ID del rango recuperado haya sido asignado previamente a un usuario o grupo; puede hacerlo examinando los UIDs y GIDs de los usuarios y grupos existentes.

Puede ajustar manualmente un rango de ID de ADN para una réplica utilizando los comandos de Ajustar manualmente los rangos de ID de ADN.

Nota

Si se asigna un nuevo rango de ID de ADN, los UID de las entradas ya existentes en el servidor o la réplica no cambian. Esto no supone un problema porque, aunque se cambie el rango de ID de ADN actual, IdM mantiene un registro de los rangos que se asignaron en el pasado.

24.8. Ajuste manual de los rangos de identificación del ADN

En algunos casos, es posible que tenga que ajustar manualmente los rangos de ID de asignación numérica distribuida (DNA) para las réplicas existentes, por ejemplo para reasignar un rango de ID de DNA asignado a una réplica que no funciona. Para obtener más información, consulte Ajuste manual de rangos de ID de ADN.

Al ajustar manualmente un intervalo de ID de ADN, asegúrese de que el nuevo intervalo ajustado está incluido en el intervalo de ID de IdM; puede comprobarlo mediante el comando ipa idrange-find. De lo contrario, el comando fallará.

Importante

Tenga cuidado de no crear rangos de ID que se solapen. Si alguno de los rangos de ID que asigna a los servidores o a las réplicas se superpone, podría dar lugar a que dos servidores diferentes asignen el mismo valor de ID a entradas diferentes.

Requisitos previos

Procedimiento

  • Para definir el rango de ID de ADN actual para un servidor especificado, utilice la opción ipa-replica-manage dnarange-set:

    # ipa-replica-manage dnarange-set masterA.example.com 1250-1499
  • Para definir el siguiente rango de ID de ADN para un servidor especificado, utilice la opción ipa-replica-manage dnanextrange-set:

    # ipa-replica-manage dnanextrange-set masterB.example.com 1500-5000

Pasos de verificación

Capítulo 25. Configuración de IdM para el aprovisionamiento externo de usuarios

Como administrador del sistema, puede configurar la Gestión de Identidades (IdM) para que admita el aprovisionamiento de usuarios mediante una solución externa para la gestión de identidades.

En lugar de utilizar la utilidad ipa, el administrador del sistema de aprovisionamiento externo puede acceder al LDAP de IdM utilizando la utilidad ldapmodify. El administrador puede añadir usuarios de etapa individuales desde la CLI utilizando ldapmodify o utilizando un archivo LDIF.

Se supone que usted, como administrador de IdM, confía plenamente en su sistema de aprovisionamiento externo para que sólo añada usuarios validados. Sin embargo, al mismo tiempo no quiere asignar a los administradores del sistema de aprovisionamiento externo el rol de IdM de User Administrator para que puedan añadir nuevos usuarios activos directamente.

Puede configurar una secuencia de comandos para trasladar automáticamente los usuarios escalonados creados por el sistema de aprovisionamiento externo a usuarios activos.

Este capítulo contiene estas secciones:

  1. Preparar la gestión de identidades (IdM) para utilizar un sistema de aprovisionamiento externo para añadir usuarios de etapa a IdM.
  2. Creación de un script para mover los usuarios añadidos por el sistema de aprovisionamiento externo de la etapa a los usuarios activos.
  3. Utilizar un sistema de aprovisionamiento externo para añadir un usuario de etapa IdM. Puede hacerlo de dos maneras:

Materiales adicionales

Para ver ejemplos y plantillas para utilizar ldapmodify como administrador completo de IdM para realizar operaciones de gestión de usuarios y grupos que requieren privilegios superiores, consulte Uso de ldapmodify.

25.1. Preparación de las cuentas de IdM para la activación automática de las cuentas de usuario de la etapa

Este procedimiento muestra cómo configurar dos cuentas de usuario de IdM para que las utilice un sistema de aprovisionamiento externo. Al añadir las cuentas a un grupo con una política de contraseñas adecuada, se permite que el sistema de aprovisionamiento externo gestione el aprovisionamiento de usuarios en IdM. A continuación, la cuenta de usuario que utilizará el sistema externo para añadir usuarios de etapa se denomina provisionator. La cuenta de usuario que se utilizará para activar automáticamente los usuarios de escenario se denomina activator.

Requisitos previos

  • El host en el que se realiza el procedimiento está inscrito en IdM.

Procedimiento

  1. Inicie sesión como administrador de IdM:

    $ kinit admin
  2. Cree un usuario llamado provisionator con privilegios para añadir usuarios de escenario.

    1. Añade la cuenta de usuario del provisionador:
    $ ipa user-add provisionator --first=provisioning --last=account --password
    1. Conceder al usuario provisionador los privilegios necesarios.

      1. Cree un rol personalizado, System Provisioning, para gestionar la adición de usuarios del escenario:

        $ ipa role-add --desc \ "Responsable de los usuarios de la etapa de aprovisionamiento" \ "Aprovisionamiento del sistema"
      2. Añada el privilegio Stage User Provisioning al rol. Este privilegio proporciona la capacidad de añadir usuarios de escenario:

        $ ipa role-add-privilege \ "System Provisioning" --privileges="Stage User Provisioning"
      3. Añade el usuario provisionador al rol:

        $ ipa role-add-member --users=provisionator \ "System Provisioning"
      4. Verifique que el provisionador existe en IdM:
      $ ipa user-find provisionator --all --raw
      --------------
      1 user matched
      --------------
        dn: uid=provisionator,cn=users,cn=accounts,dc=idm,dc=example,dc=com
        uid: provisionator
        [...]
  3. Cree un usuario, activator, con los privilegios para gestionar las cuentas de usuario.

    1. Añade la cuenta de usuario del activador:

      $ ipa user-add activator --first=activation --last=account --password
    2. Conceda al usuario activador los privilegios necesarios añadiendo el usuario a la función predeterminada User Administrator:

      $ ipa role-add-member --users=activator \ "User Administrator"
  4. Cree un grupo de usuarios para las cuentas de la aplicación:

    $ ipa group-add application-accounts
  5. Actualice la política de contraseñas para el grupo. La siguiente política evita la caducidad de la contraseña y el bloqueo de la cuenta, pero compensa los posibles riesgos exigiendo contraseñas complejas:

    $ ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
  6. (Opcional) Compruebe que la política de contraseñas existe en IdM:

    $ ipa pwpolicy-show application-accounts
      Group: application-accounts
      Max lifetime (days): 10000
      Min lifetime (hours): 0
      History size: 0
    [...]
  7. Añade las cuentas de aprovisionamiento y activación al grupo de cuentas de aplicación:

    $ ipa group-add-member application-accounts --users={provisionator,activator}
  8. Cambie las contraseñas de las cuentas de usuario:

    $ kpasswd provisionator
    $ kpasswd activator

    El cambio de las contraseñas es necesario porque las contraseñas de los nuevos usuarios de IdM caducan inmediatamente.

Recursos adicionales:

25.2. Configuración de la activación automática de las cuentas de usuario de la etapa IdM

Este procedimiento muestra cómo crear un script para activar a los usuarios de la etapa. El sistema ejecuta el script automáticamente a intervalos de tiempo especificados. Esto garantiza que las nuevas cuentas de usuario se activen automáticamente y estén disponibles para su uso poco después de su creación.

Importante

El procedimiento asume que el propietario del sistema de aprovisionamiento externo ya ha validado a los usuarios y que éstos no requieren una validación adicional en el lado de IdM antes de que el script los añada a IdM.

Basta con activar el proceso de activación en uno solo de sus servidores de IdM.

Requisitos previos

Procedimiento

  1. Generar un archivo keytab para la cuenta de activación:

    # ipa-getkeytab -s server.idm.example.com -p \ "activator" -k /etc/krb5.ipa-activation.keytab

    Si desea activar el proceso de activación en más de un servidor IdM, genere el archivo keytab en un solo servidor. A continuación, copie el archivo keytab en los demás servidores.

  2. Cree un script, /usr/local/sbin/ipa-activate-all, con el siguiente contenido para activar a todos los usuarios:

    #!/bin/bash
    
    kinit -k -i activator
    
    ipa stageuser-find --all --raw | grep "  uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
  3. Edite los permisos y la propiedad del script ipa-activate-all para que sea ejecutable:

    # chmod 755 /usr/local/sbin/ipa-activate-all
    # chown root:root /usr/local/sbin/ipa-activate-all
  4. Cree un archivo de unidad systemd, /etc/systemd/system/ipa-activate-all.service, con el siguiente contenido:

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Service]
    Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab
    Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all
    ExecStart=/usr/local/sbin/ipa-activate-all
  5. Cree un temporizador systemd, /etc/systemd/system/ipa-activate-all.timer, con el siguiente contenido:

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Timer]
    OnBootSec=15min
    OnUnitActiveSec=1min
    
    [Install]
    WantedBy=multi-user.target
  6. Recarga la nueva configuración:

    # systemctl daemon-reload
  7. Activar ipa-activate-all.timer:

    # systemctl enable ipa-activate-all.timer
  8. Inicio ipa-activate-all.timer:

    # systemctl start ipa-activate-all.timer
  9. (Opcional) Compruebe que el demonio ipa-activate-all.timer se está ejecutando:

    # systemctl status ipa-activate-all.timer
    ● ipa-activate-all.timer - Scan IdM every minute for any stage users that must be activated
       Loaded: loaded (/etc/systemd/system/ipa-activate-all.timer; enabled; vendor preset: disabled)
       Active: active (waiting) since Wed 2020-06-10 16:34:55 CEST; 15s ago
      Trigger: Wed 2020-06-10 16:35:55 CEST; 44s left
    
    Jun 10 16:34:55 server.idm.example.com systemd[1]: Started Scan IdM every minute for any stage users that must be activated.

25.3. Añadir una etapa IdM definida por el usuario en un archivo LDIF

En esta sección se describe cómo un administrador de un sistema de aprovisionamiento externo puede acceder a IdM LDAP y utilizar un archivo LDIF para añadir usuarios del escenario. Aunque el ejemplo siguiente muestra la adición de un solo usuario, se pueden añadir varios usuarios en un archivo en modo masivo.

Requisitos previos

  • El administrador de IdM ha creado la cuenta provisionator y una contraseña para ella. Para obtener más información, consulte Preparación de las cuentas de IdM para la activación automática de las cuentas de usuario del escenario.
  • Usted, como administrador externo, conoce la contraseña de la cuenta provisionator.
  • Puedes acceder mediante SSH al servidor IdM desde tu servidor LDAP.
  • Puede suministrar el conjunto mínimo de atributos que debe tener un usuario de la etapa IdM para permitir el correcto procesamiento del ciclo de vida del usuario, a saber

    • El distinguished name (dn)
    • El common name (cn)
    • El last name (sn)
    • El uid

Procedimiento

  1. En el servidor externo, cree un archivo LDIF que contenga información sobre el nuevo usuario:

    dn: uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: stageidmuser
    sn: surname
    givenName: first_name
    cn: full_name
  2. Transfiera el archivo LDIF del servidor externo al servidor IdM:

    $ scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/
    Password:
    add-stageidmuser.ldif                                                                                          100%  364   217.6KB/s   00:00
  3. Utilice el protocolo SSH para conectarse al servidor IdM como provisionator:

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  4. En el servidor de IdM, obtenga el ticket de concesión de tickets (TGT) de Kerberos para la cuenta del provisionador:

    [provisionator@server ~]$ kinit provisionator
  5. Introduzca el comando ldapadd con la opción -f y el nombre del archivo LDIF. Especifique el nombre del servidor IdM y el número de puerto:

    ~]$ ldapadd -h server.idm.example.com -p 389 -f  add-stageidmuser.ldif
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
    adding the entry "uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"

25.4. Añadir un usuario del escenario IdM directamente desde la CLI usando ldapmodify

Esta sección describe cómo un administrador de un sistema de aprovisionamiento externo puede acceder al LDAP de Gestión de Identidades (IdM) y utilizar la utilidad ldapmodify para añadir un usuario de escenario.

Requisitos previos

  • El administrador de IdM ha creado la cuenta provisionator y una contraseña para ella. Para obtener más información, consulte Preparación de las cuentas de IdM para la activación automática de las cuentas de usuario de escenario.
  • Usted, como administrador externo, conoce la contraseña de la cuenta provisionator.
  • Puedes acceder mediante SSH al servidor IdM desde tu servidor LDAP.
  • Puede suministrar el conjunto mínimo de atributos que debe tener un usuario de la etapa IdM para permitir el correcto procesamiento del ciclo de vida del usuario, a saber

    • El distinguished name (dn)
    • El common name (cn)
    • El last name (sn)
    • El uid

Procedimiento

  1. Utilice el protocolo SSH para conectarse al servidor de IdM utilizando su identidad y credenciales de IdM:

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  2. Obtenga el TGT de la cuenta provisionator, un usuario de IdM con un rol para agregar nuevos usuarios de escenario:

    $ kinit provisionator
  3. Introduzca el comando ldapmodify y especifique Generic Security Services API (GSSAPI) como mecanismo de Simple Authentication and Security Layer (SASL) a utilizar para la autenticación. Especifique el nombre del servidor IdM y el puerto:

    # ldapmodify -h server.idm.example.com -p 389 -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 56
    SASL data security layer installed.
  4. Introduzca la dirección dn del usuario que va a añadir:

    dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
  5. Introduzca add como el tipo de cambio que está realizando:

    tipo de cambio: añadir
  6. Especifique las categorías de clase de objeto LDAP necesarias para permitir el correcto procesamiento del ciclo de vida del usuario:

    objectClass: top
    objectClass: inetorgperson

    Se pueden especificar clases de objetos adicionales.

  7. Introduzca la dirección uid del usuario:

    uid: stageuser
  8. Introduzca la dirección cn del usuario:

    cn: Babs Jensen
  9. Introduzca el apellido del usuario:

    sn: Jensen
  10. Vuelva a pulsar Enter para confirmar que es el final de la entrada:

    [Enter]
    
    adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
  11. Salga de la conexión mediante Ctrl C .

Pasos de verificación

Verifique el contenido de la entrada del escenario para asegurarse de que su sistema de aprovisionamiento ha añadido todos los atributos POSIX necesarios y la entrada del escenario está lista para ser activada.

  • Para mostrar los atributos LDAP del nuevo usuario del escenario, introduzca el comando ipa stageuser-show --all --raw:

    $ ipa stageuser-show stageuser --all --raw
      dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
      uid: stageuser
      sn: Jensen
      cn: Babs Jensen
      has_password: FALSE
      has_keytab: FALSE
      nsaccountlock: TRUE
      objectClass: top
      objectClass: inetorgperson
      objectClass: organizationalPerson
      objectClass: person
    1. Tenga en cuenta que el usuario está explícitamente desactivado por el atributo nsaccountlock.

Capítulo 26. Uso de ldapmodify para gestionar los usuarios de IdM de forma externa

Puede modificar el LDAP de Identity Management (IdM) directamente desde la interfaz de línea de comandos (CLI) utilizando las utilidades ldapmodify y ldapdelete. Las utilidades proporcionan una funcionalidad completa para añadir, editar y eliminar el contenido del directorio. Puede utilizar estas utilidades para gestionar tanto las entradas de configuración del servidor como los datos de las entradas de usuario. Las utilidades también se pueden utilizar para escribir scripts para realizar una gestión masiva de uno o más directorios.

26.1. Plantillas para gestionar externamente las cuentas de usuario de IdM

Esta sección describe las plantillas para varias operaciones de gestión de usuarios en IdM. Las plantillas muestran los atributos que debe modificar mediante ldapmodify para lograr los siguientes objetivos:

  • Añadir un nuevo usuario de escenario
  • Modificar el atributo de un usuario
  • Habilitación de un usuario
  • Desactivar un usuario
  • Conservación de un usuario

Las plantillas están formateadas en el formato de intercambio de datos LDAP (LDIF). LDIF es un formato estándar de intercambio de datos en texto plano para representar el contenido del directorio LDAP y las solicitudes de actualización.

Utilizando las plantillas, puede configurar el proveedor LDAP de su sistema de aprovisionamiento para gestionar las cuentas de usuario de IdM.

Para ver ejemplos de procedimientos detallados, consulte las siguientes secciones:

Plantillas para añadir un nuevo usuario de escenario

  • Una plantilla para añadir un usuario con UID and GID assigned automatically. El nombre distinguido (DN) de la entrada creada debe empezar por uid=user_login:

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: user_login
    sn: surname
    givenName: first_name
    cn: full_name
  • Una plantilla para añadir un usuario con UID and GID assigned statically:

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: person
    objectClass: inetorgperson
    objectClass: organizationalperson
    objectClass: posixaccount
    uid: user_login
    uidNumber: UID_number
    gidNumber: GID_number
    sn: surname
    givenName: first_name
    cn: full_name
    homeDirectory: /home/user_login

    No es necesario especificar ninguna clase de objeto IdM cuando se añaden usuarios de escenario. IdM añade estas clases automáticamente después de que se activen los usuarios.

Plantillas para modificar los usuarios existentes

  • Modifying a user’s attribute:

    dn: distinguished_name
    changetype: modify
    replace: attribute_to_modify
    attribute_to_modify: new_value
  • Disabling a user:

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: TRUE
  • Enabling a user:

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: FALSE

    La actualización del atributo nssAccountLock no tiene ningún efecto sobre los usuarios de la etapa y los preservados. Aunque la operación de actualización se complete con éxito, el valor del atributo sigue siendo nssAccountLock: TRUE.

  • Preserving a user:

    dn: distinguished_name
    changetype: modrdn
    newrdn: uid=user_login
    deleteoldrdn: 0
    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
Nota

Antes de modificar un usuario, obtenga el nombre distinguido (DN) del usuario mediante una búsqueda con el nombre de usuario. En el siguiente ejemplo, el usuario user_allowed_to_modify_user_entries es un usuario autorizado a modificar la información de usuarios y grupos, por ejemplo activator o administrador de IdM. La contraseña del ejemplo es la de este usuario:

[...]
# ldapsearch -LLL -x -D "uid=user_allowed_to_modify_user_entries,cn=users,cn=accounts,dc=idm,dc=example,dc=com" -w "Secret123" -H ldap://r8server.idm.example.com -b "cn=users,cn=accounts,dc=idm,dc=example,dc=com" uid=test_user
dn: uid=test_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=example,dc=com

26.2. Plantillas para gestionar externamente las cuentas de grupo de IdM

En esta sección se describen las plantillas para varias operaciones de gestión de grupos de usuarios en IdM. Las plantillas muestran los atributos que debe modificar mediante ldapmodify para lograr los siguientes objetivos:

  • Crear un nuevo grupo
  • Borrar un grupo existente
  • Añadir un miembro a un grupo
  • Eliminar un miembro de un grupo

Las plantillas están formateadas en el formato de intercambio de datos LDAP (LDIF). LDIF es un formato estándar de intercambio de datos en texto plano para representar el contenido del directorio LDAP y las solicitudes de actualización.

Utilizando las plantillas, puede configurar el proveedor LDAP de su sistema de aprovisionamiento para gestionar las cuentas de grupo de IdM.

Crear un nuevo grupo

dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaobject
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
objectClass: posixgroup
uid: group_name
cn: group_name
gidNumber: GID_number

Modificación de los grupos

  • Deleting an existing group:

    dn: group_distinguished_name
    changetype: delete
  • Adding a member to a group:

    dn: group_distinguished_name
    changetype: modify
    add: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com

    No añada usuarios de la etapa o conservados a los grupos. Aunque la operación de actualización se complete con éxito, los usuarios no se actualizarán como miembros del grupo. Sólo los usuarios activos pueden pertenecer a los grupos.

  • Removing a member from a group:

    dn: distinguished_name
    changetype: modify
    delete: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
Nota

Antes de modificar un grupo, obtenga el nombre distinguido (DN) del grupo buscando con el nombre del grupo.

# ldapsearch -YGSSAPI -H ldap://server.idm.example.com -b "cn=groups,cn=accounts,dc=idm,dc=example,dc=com" "cn=group_name"
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1650388524-2605035987-2578146103-11017
cn: testgroup
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaUniqueID: 569bf864-9d45-11ea-bea3-525400f6f085
gidNumber: 1997010017

26.3. Conservación de un usuario IdM con ldapmodify

Esta sección describe cómo utilizar ldapmodify para conservar un usuario de IdM; es decir, cómo desactivar una cuenta de usuario después de que el empleado haya dejado la empresa.

Requisitos previos

  • Puede autenticarse como usuario de IdM con un rol para preservar a los usuarios.

Procedimiento

  1. Inicie sesión como usuario de IdM con un rol para preservar usuarios:

    $ kinit admin
  2. Introduzca el comando ldapmodify y especifique la API de servicios de seguridad genéricos (GSSAPI) como el mecanismo de capa de seguridad y autenticación simple (SASL) que se utilizará para la autenticación:

    # ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
  3. Introduzca la dirección dn del usuario que desea conservar:

    dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
  4. Introduzca modrdn como el tipo de cambio que desea realizar:

    tipo de cambio: modrdn
  5. Especifique el newrdn para el usuario:

    newrdn: uid=user1
  6. Indique que desea conservar el usuario:

    deleteoldrdn: 0
  7. Especifique la dirección new superior DN:

    newsuperior: cn=usuarios eliminados,cn=cuentas,cn=aprovisionamiento,dc=idm,dc=ejemplo,dc=com

    La conservación de un usuario mueve la entrada a una nueva ubicación en el árbol de información del directorio (DIT). Por esta razón, debe especificar el DN de la nueva entrada padre como el nuevo DN superior.

  8. Vuelva a pulsar Enter para confirmar que es el final de la entrada:

    [Enter]
    
    modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com"
  9. Salga de la conexión mediante Ctrl C .

Pasos de verificación

  • Verifique que el usuario ha sido preservado, listando todos los usuarios preservados:

    $ ipa user-find --preserved=true
    --------------
    1 user matched
    --------------
      User login: user1
      First name: First 1
      Last name: Last 1
      Home directory: /home/user1
      Login shell: /bin/sh
      Principal name: user1@IDM.EXAMPLE.COM
      Principal alias: user1@IDM.EXAMPLE.COM
      Email address: user1@idm.example.com
      UID: 1997010003
      GID: 1997010003
      Account disabled: True
      Preserved user: True
    ----------------------------
    Number of entries returned 1
    ----------------------------

Capítulo 27. Gestión de hosts en IdM CLI

En este capítulo se presentan los hosts y las entradas de hosts en Identity Management (IdM), así como las siguientes operaciones que se realizan al gestionar los hosts y las entradas de hosts en la CLI de IdM:

El capítulo también contiene una tabla resumen de los requisitos previos, el contexto y las consecuencias de estas operaciones.

27.1. Hosts en IdM

La Gestión de Identidades (IdM) gestiona estas identidades:

  • Usuarios
  • Servicios
  • Anfitriones

Un host representa una máquina. Como identidad IdM, un host tiene una entrada en el LDAP de IdM, es decir, la instancia 389 del servidor IdM.

La entrada de host en IdM LDAP se utiliza para establecer relaciones entre otros hosts e incluso servicios dentro del dominio. Estas relaciones forman parte de delegating autorización y control a los hosts dentro del dominio. Cualquier host puede ser utilizado en las reglas de host-based access control (HBAC).

El dominio de IdM establece una comunidad entre las máquinas, con información de identidad común, políticas comunes y servicios compartidos. Cualquier máquina que pertenezca a un dominio funciona como cliente del mismo, lo que significa que utiliza los servicios que el dominio proporciona. El dominio IdM proporciona tres servicios principales específicos para las máquinas:

  • DNS
  • Kerberos
  • Gestión de certificados

Los hosts en IdM están estrechamente relacionados con los servicios que se ejecutan en ellos:

  • Las entradas de servicio están asociadas a un host.
  • Un host almacena tanto los principales de Kerberos del host como los del servicio.

27.2. Inscripción del anfitrión

Esta sección describe la inscripción de hosts como clientes de IdM y lo que ocurre durante y después de la inscripción. La sección compara la inscripción de hosts y usuarios de IdM. La sección también describe los tipos alternativos de autenticación disponibles para los hosts.

La inscripción de un anfitrión consiste en:

  • Creación de una entrada de host en IdM LDAP: posiblemente utilizando el comandoipa host-add en la CLI de IdM, o la operación equivalente de la interfaz web de IdM.
  • Configurar los servicios de IdM en el host, por ejemplo, el demonio de servicios de seguridad del sistema (SSSD), Kerberos y certmonger, y unir el host al dominio de IdM.

Las dos acciones pueden realizarse por separado o conjuntamente.

Si se realizan por separado, permiten dividir las dos tareas entre dos usuarios con diferentes niveles de privilegio. Esto es útil para los despliegues masivos.

El comando ipa-client-install puede realizar las dos acciones juntas. El comando crea una entrada de host en el LDAP de IdM si esa entrada aún no existe, y configura los servicios Kerberos y SSSD para el host. El comando introduce el host en el dominio IdM y le permite identificar el servidor IdM con el que se conectará. Si el host pertenece a una zona DNS gestionada por IdM, ipa-client-install también añade registros DNS para el host. El comando debe ejecutarse en el cliente.

27.2.1. Privilegios de usuario necesarios para la inscripción en el host

La operación de inscripción de hosts requiere autenticación para evitar que un usuario sin privilegios añada máquinas no deseadas al dominio de IdM. Los privilegios necesarios dependen de varios factores, por ejemplo:

  • Si se crea una entrada de host por separado de la ejecución de ipa-client-install
  • Si se utiliza una contraseña de un solo uso (OTP) para la inscripción
Privilegios de usuario para crear manualmente una entrada de host en IdM LDAP

El privilegio de usuario necesario para crear una entrada de host en IdM LDAP mediante el comando CLI ipa host-add o la interfaz web de IdM es Host Administrators. El privilegio Host Administrators se puede obtener a través del rol IT Specialist.

Privilegios de usuario para unir el cliente al dominio IdM

Los hosts se configuran como clientes IdM durante la ejecución del comando ipa-client-install. El nivel de credenciales necesario para ejecutar el comando ipa-client-install depende de cuál de los siguientes escenarios de inscripción se encuentre:

  • La entrada del host en IdM LDAP no existe. Para este escenario, necesita las credenciales de un administrador completo o el rol Host Administrators. Un administrador completo es un miembro del grupo admins. La función Host Administrators proporciona privilegios para añadir hosts y registrar hosts. Para más detalles sobre este escenario, consulte Instalación de un cliente con credenciales de usuario: instalación interactiva.
  • La entrada del host en IdM LDAP existe. Para este escenario, se necesitan las credenciales de un administrador limitado para ejecutar ipa-client-install con éxito. El administrador limitado en este caso tiene el rol Enrollment Administrator, que proporciona el privilegio Host Enrollment. Para obtener más detalles, consulte Instalación de un cliente con credenciales de usuario: instalación interactiva.
  • La entrada del host en el LDAP de IdM existe, y un administrador completo o limitado ha generado un OTP para el host. En este caso, puede instalar un cliente IdM como un usuario normal si ejecuta el comando ipa-client-install con la opción --password, proporcionando la OTP correcta. Para obtener más información, consulte Instalación de un cliente mediante una contraseña de un solo uso: Instalación interactiva.

Tras la inscripción, los hosts de IdM autentican cada nueva sesión para poder acceder a los recursos de IdM. La autenticación de la máquina es necesaria para que el servidor IdM confíe en ella y acepte las conexiones IdM del software cliente instalado en esa máquina. Después de autenticar al cliente, el servidor IdM puede responder a sus solicitudes.

27.2.2. Registro y autenticación de hosts y usuarios de IdM: comparación

Existen muchas similitudes entre los usuarios y los hosts en IdM. En esta sección se describen algunas de las similitudes que se pueden observar durante la etapa de inscripción, así como las que se refieren a la autenticación durante la etapa de despliegue.

  • La etapa de inscripción (Tabla 27.1, “Inscripción de usuarios y hosts”):

    • Un administrador puede crear una entrada LDAP tanto para un usuario como para un host antes de que el usuario o el host se unan realmente a IdM: para el usuario del escenario, el comando es ipa stageuser-add; para el host, el comando es ipa host-add.
    • Durante la ejecución del comando ipa-client-install en el host se crea un archivo que contiene una key table o, abreviado, keytab, una clave simétrica que se asemeja en cierta medida a una contraseña de usuario, lo que hace que el host se una al reino IdM. De forma análoga, se pide a un usuario que cree una contraseña cuando activa su cuenta, uniéndose así al reino IdM.
    • Mientras que la contraseña de usuario es el método de autenticación por defecto para un usuario, el keytab es el método de autenticación por defecto para un host. El keytab se almacena en un archivo en el host.

    Tabla 27.1. Inscripción de usuarios y hosts

    AcciónUsuarioAnfitrión

    Antes de la inscripción

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

    Activación de la cuenta

    $ ipa stageuser-activate user_name

    $ ipa-client install [--password] (debe ejecutarse en el propio host)

  • La etapa de despliegue (Tabla 27.2, “Autenticación de la sesión del usuario y del host”):

    • Cuando un usuario inicia una nueva sesión, se autentifica utilizando una contraseña; del mismo modo, cada vez que se enciende, el host se autentifica presentando su archivo keytab. El demonio de servicios de seguridad del sistema (SSSD) gestiona este proceso en segundo plano.
    • Si la autenticación tiene éxito, el usuario o el host obtiene un ticket de concesión de Kerberos (TGT).
    • El TGT se utiliza entonces para obtener billetes específicos para servicios concretos.

    Tabla 27.2. Autenticación de la sesión del usuario y del host

     UsuarioAnfitrión

    Medio de autentificación por defecto

    Password

    Keytabs

    Iniciar una sesión (usuario ordinario)

    $ kinit user_name

    [switch on the host]

    El resultado de una autenticación exitosa

    TGT para obtener acceso a servicios específicos

    TGT para obtener acceso a servicios específicos

Los TGT y otros tiques Kerberos se generan como parte de los servicios y políticas Kerberos definidos por el servidor. La concesión inicial de un ticket Kerberos, la renovación de las credenciales Kerberos e incluso la destrucción de la sesión Kerberos son gestionadas automáticamente por los servicios IdM.

27.2.3. Opciones alternativas de autenticación para los hosts de IdM

Además de los keytabs, IdM admite otros dos tipos de autenticación de máquinas:

  • Claves SSH. La clave pública SSH para el host se crea y se carga en la entrada del host. A partir de ahí, el demonio de servicios de seguridad del sistema (SSSD) utiliza IdM como proveedor de identidad y puede trabajar en conjunto con OpenSSH y otros servicios para hacer referencia a las claves públicas ubicadas centralmente en IdM.
  • Certificados de máquina. En este caso, la máquina utiliza un certificado SSL emitido por la autoridad de certificación del servidor de IdM y almacenado en el servidor de directorio de IdM. El certificado se envía entonces a la máquina para que lo presente cuando se autentique en el servidor. En el cliente, los certificados son gestionados por un servicio llamado certmonger.

27.3. Operaciones de acogida

Esta sección enumera las operaciones más comunes relacionadas con la inscripción y habilitación de hosts, y explica los requisitos previos, el contexto y las consecuencias de realizarlas.

Tabla 27.3. Operaciones de acogida parte 1

Acción¿Cuáles son los requisitos de la acción?¿Cuándo tiene sentido ejecutar el comando?¿Cómo realiza la acción un administrador del sistema? ¿Qué comando(s) ejecuta?

Enrolling a client

consulte Preparación del sistema para la instalación del cliente de gestión de identidades en Installing_Identity_Management

Cuando quiera que el host se una al reino de IdM.

La inscripción de máquinas como clientes en el dominio IdM es un proceso de dos partes. Se crea una entrada de host para el cliente (y se almacena en la instancia 389 del servidor de directorios) cuando se ejecuta el comando ipa host-add y, a continuación, se crea un keytab para aprovisionar al cliente. Ambas partes son realizadas automáticamente por el comando ipa-client-install. También es posible realizar estos pasos por separado; esto permite a los administradores preparar las máquinas y el IdM antes de configurar los clientes. Esto permite escenarios de configuración más flexibles, incluyendo despliegues masivos.

Disabling a client

El host debe tener una entrada en IdM. El host debe tener un keytab activo.

Cuando se desea eliminar el host del ámbito de IdM temporalmente, quizás por motivos de mantenimiento.

ipa host-disable host_name

Enabling a client

El host debe tener una entrada en IdM.

Cuando quieras que el host temporalmente desactivado vuelva a estar activo.

ipa-getkeytab

Re-enrolling a client

El host debe tener una entrada en IdM.

Cuando se ha perdido el host original pero se ha instalado un host con el mismo nombre de host.

ipa-client-install --keytab o ipa-client-install --force-join

Un-enrolling a client

El host debe tener una entrada en IdM.

Si desea eliminar el host del ámbito de IdM de forma permanente.

ipa-client-install --uninstall

Tabla 27.4. Operaciones de acogida parte 2

Acción¿En qué máquina puede el administrador ejecutar los comandos?¿Qué ocurre cuando se realiza la acción? ¿Cuáles son las consecuencias para el funcionamiento del host en IdM? ¿Qué limitaciones se introducen/suprimen?

Enrolling a client

En el caso de una inscripción en dos pasos: ipa host-add puede ejecutarse en cualquier cliente IdM; el segundo paso de ipa-client-install debe ejecutarse en el propio cliente

Por defecto, esto configura SSSD para conectarse a un servidor IdM para la autenticación y autorización. Opcionalmente se puede configurar el Pluggable Authentication Module (PAM) y el Name Switching Service (NSS) para trabajar con un servidor IdM sobre Kerberos y LDAP.

Disabling a client

Cualquier máquina en IdM, incluso el propio host

La clave Kerberos y el certificado SSL del host se invalidan, y todos los servicios que se ejecutan en el host se desactivan.

Enabling a client

Cualquier máquina en IdM. Si se ejecuta en el host deshabilitado, es necesario suministrar las credenciales LDAP.

La clave Kerberos del host y el certificado SSL vuelven a ser válidos, y todos los servicios IdM que se ejecutan en el host se vuelven a habilitar.

Re-enrolling a client

El host que se va a reinscribir. Es necesario suministrar las credenciales LDAP.

Se genera una nueva clave Kerberos para el host, sustituyendo la anterior.

Un-enrolling a client

El anfitrión que se va a dar de baja.

El comando desconfigura IdM e intenta devolver la máquina a su estado anterior. Parte de este proceso consiste en desinscribir la máquina del servidor IdM. La desinscripción consiste en desactivar la clave de la máquina en el servidor IdM. La entidad de seguridad de la máquina en /etc/krb5.keytab (host/<fqdn>@REALM) se utiliza para autenticarse en el servidor IdM para desinscribirse. Si esta entidad de seguridad no existe, la desinscripción fallará y el administrador tendrá que desactivar la entidad de seguridad del host (ipa host-disable <fqdn>).

27.4. Entrada de host en IdM LDAP

Esta sección describe el aspecto de una entrada de host en la Gestión de identidades (IdM) y los atributos que puede contener.

Una entrada de host LDAP contiene toda la información relevante sobre el cliente dentro de IdM:

  • Entradas de servicio asociadas al host
  • El anfitrión y el director del servicio
  • Normas de control de acceso
  • Información sobre la máquina, como su ubicación física y su sistema operativo
Nota

Tenga en cuenta que la pestaña IdM Web UI IdentityHosts no muestra toda la información sobre un host concreto almacenada en el LDAP de IdM.

27.4.1. Propiedades de configuración de la entrada del host

Una entrada de host puede contener información sobre el host que está fuera de su configuración del sistema, como su ubicación física, dirección MAC, claves y certificados.

Esta información puede establecerse cuando se crea la entrada del host si se crea manualmente. Alternativamente, la mayor parte de esta información se puede añadir a la entrada del host después de que el host esté inscrito en el dominio.

Tabla 27.5. Propiedades de configuración del host

Campo UIOpción de línea de comandosDescripción

Descripción

--desc=description

Una descripción del anfitrión.

Localidad

--locality=locality

La ubicación geográfica del anfitrión.

Ubicación

--location=location

La ubicación física del host, como el rack de su centro de datos.

Plataforma

--platform=string

El hardware o la arquitectura del host.

Sistema operativo

--os=string

El sistema operativo y la versión del host.

Dirección MAC

--macaddress=address

La dirección MAC del host. Se trata de un atributo con varios valores. El complemento NIS utiliza la dirección MAC para crear un mapa NIS ethers para el host.

Claves públicas SSH

--sshpubkey=string

La clave pública SSH completa para el host. Este es un atributo multivaluado, por lo que se pueden establecer múltiples claves.

Nombre del director (no editable)

--principalname=principal

El nombre de la entidad de seguridad Kerberos para el host. Por defecto es el nombre del host durante la instalación del cliente, a menos que se establezca explícitamente una entidad de seguridad diferente en -p. Esto puede ser cambiado usando las herramientas de línea de comandos, pero no puede ser cambiado en la UI.

Establecer una contraseña única

--password=string

Esta opción establece una contraseña para el host que se puede utilizar en la inscripción masiva.

-

--random

Esta opción genera una contraseña aleatoria que se utilizará en la inscripción masiva.

-

--certificate=string

Un blob de certificado para el host.

-

--updatedns

Establece si el host puede actualizar dinámicamente sus entradas DNS si su dirección IP cambia.

27.5. Añadir entradas de host IdM desde la CLI de IdM

Esta sección describe cómo añadir entradas de host en Identity Management (IdM) mediante la interfaz de línea de comandos (CLI).

Las entradas de host se crean con el comando host-add. Este comando añade la entrada de host al servidor de directorio IdM. Consulte la página de manual ipa host escribiendo ipa help host en su CLI para obtener la lista completa de opciones disponibles con host-add.

Hay varios escenarios diferentes cuando se añade un host a IdM:

  • En su forma más básica, especifica sólo el nombre del host del cliente para añadirlo al ámbito de Kerberos y crear una entrada en el servidor LDAP de IdM:

    $ ipa host-add client1.example.com
  • Si el servidor IdM está configurado para gestionar DNS, añada el host a los registros de recursos DNS utilizando la opción --ip-address.

    Ejemplo 27.1. Creación de entradas de host con direcciones IP estáticas

    $ ipa host-add --ip-address=192.168.166.31 client1.example.com
  • Si el host que se va a añadir no tiene una dirección IP estática o si no se conoce la dirección IP en el momento de configurar el cliente, utilice la opción --force con el comando ipa host-add.

    Ejemplo 27.2. Creación de entradas de host con DHCP

    $ ipa host-add --force client1.example.com

    Por ejemplo, los ordenadores portátiles pueden estar preconfigurados como clientes de IdM, pero no tienen direcciones IP en el momento de su configuración. El uso de --force crea esencialmente una entrada de marcador de posición en el servicio DNS de IdM. Cuando el servicio DNS actualiza dinámicamente sus registros, se detecta la dirección IP actual del host y se actualiza su registro DNS.

27.6. Eliminación de entradas de host desde la CLI de IdM

  • Utilice el comando host-del para eliminar los registros de host. Si su dominio IdM tiene DNS integrado, utilice la opción --updatedns para eliminar los registros asociados de cualquier tipo para el host del DNS:

    $ ipa host-del --updatedns client1.example.com

27.7. Volver a inscribir a un cliente de Gestión de Identidades

27.7.1. Reinscripción de clientes en IdM

Esta sección describe cómo volver a inscribir a un cliente de gestión de identidades (IdM).

Si una máquina cliente ha sido destruida y ha perdido la conexión con los servidores de IdM, por ejemplo debido a un fallo de hardware del cliente, y todavía tienes su keytab, puedes volver a inscribir al cliente. En este caso, lo que quieres es que el cliente vuelva al entorno IdM con el mismo nombre de host.

Durante la reinscripción, el cliente genera una nueva clave Kerberos y claves SSH, pero la identidad del cliente en la base de datos LDAP no cambia. Después de la reinscripción, el host tiene sus claves y otra información en el mismo objeto LDAP con la misma FQDN que anteriormente, antes de la pérdida de conexión de la máquina con los servidores IdM.

Importante

Sólo puede volver a inscribir a los clientes cuya entrada de dominio aún está activa. Si ha desinstalado un cliente (mediante ipa-client-install --uninstall) o ha desactivado su entrada de host (mediante ipa host-disable), no podrá volver a inscribirlo.

No se puede volver a inscribir a un cliente después de haberle cambiado el nombre. Esto se debe a que en la Gestión de Identidades, el atributo clave de la entrada del cliente en LDAP es el nombre de host del cliente, su FQDN. A diferencia de la reinscripción de un cliente, durante la cual el objeto LDAP del cliente no cambia, el resultado de cambiar el nombre de un cliente es que éste tiene sus claves y otra información en un objeto LDAP diferente con un nuevo FQDN. Por lo tanto, la única forma de cambiar el nombre de un cliente es desinstalar el host de IdM, cambiar el nombre del host e instalarlo como cliente de IdM con un nuevo nombre. Para más detalles sobre cómo cambiar el nombre de un cliente, consulte Sección 27.8, “Renombrar los sistemas cliente de Gestión de Identidades”.

27.7.1.1. Qué ocurre durante la reinscripción de los clientes

Durante la reinscripción, la gestión de la identidad:

  • Revoca el certificado original del host
  • Crea nuevas claves SSH
  • Genera un nuevo keytab

27.7.2. Reinscripción de un cliente mediante credenciales de usuario: Reinscripción interactiva

Este procedimiento describe la reinscripción de un cliente de gestión de identidades de forma interactiva utilizando las credenciales de un usuario autorizado.

  1. Vuelva a crear la máquina cliente con el mismo nombre de host.
  2. Ejecute el comando ipa-client-install --force-join en la máquina cliente:

    # ipa-client-install --force-join
  3. El script solicita un usuario cuya identidad se utilizará para reinscribir al cliente. Podría ser, por ejemplo, un usuario de hostadmin con el rol de administrador de inscripciones:

    User authorized to enroll computers: hostadmin
    Password for hostadmin@EXAMPLE.COM:

Recursos adicionales

27.7.3. Reinscripción de un cliente mediante el uso de la ficha de clave del cliente: Reinscripción no interactiva

Requisitos previos

  • Haga una copia de seguridad del archivo keytab original del cliente, por ejemplo en el directorio /tmp o /root.

Procedimiento

Este procedimiento describe la reinscripción de un cliente de gestión de identidades (IdM) de forma no interactiva mediante el uso del llavero del sistema cliente. Por ejemplo, la reinscripción mediante el llavero del cliente es adecuada para una instalación automatizada.

  1. Vuelva a crear la máquina cliente con el mismo nombre de host.
  2. Copie el archivo keytab desde la ubicación de la copia de seguridad al directorio /etc/ en la máquina cliente recreada.
  3. Utilice la utilidad ipa-client-install para volver a inscribir el cliente, y especifique la ubicación del keytab con la opción --keytab:

    # ipa-client-install --keytab /etc/krb5.keytab
    Nota

    El keytab especificado en la opción --keytab sólo se utiliza cuando se autentifica para iniciar la inscripción. Durante la reinscripción, IdM genera un nuevo keytab para el cliente.

27.7.4. Probar un cliente de gestión de identidades después de la instalación

La interfaz de línea de comandos le informa de que el ipa-client-install se ha realizado con éxito, pero también puede hacer su propia prueba.

Para comprobar que el cliente de gestión de identidades puede obtener información sobre los usuarios definidos en el servidor, compruebe que puede resolver un usuario definido en el servidor. Por ejemplo, para comprobar el usuario predeterminado admin:

[user@client1 ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

Para comprobar que la autenticación funciona correctamente, su - como otro usuario de IdM:

[user@client1 ~]$ su - idm_user
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[idm_user@client1 ~]$

27.8. Renombrar los sistemas cliente de Gestión de Identidades

Las siguientes secciones describen cómo cambiar el nombre del host de un sistema cliente de Gestión de Identidades.

Aviso

Cambiar el nombre de un cliente es un procedimiento manual. No lo realice a menos que sea absolutamente necesario cambiar el nombre del host.

El cambio de nombre de un cliente de Gestión de Identidades implica:

  1. Preparar el anfitrión. Para más detalles, consulte Sección 27.8.1, “Requisitos previos”
  2. Desinstalar el cliente IdM del host. Para más detalles, consulte Sección 27.8.2, “Desinstalación de un cliente de gestión de identidades”
  3. Cambiar el nombre del host. Para más detalles, consulte Sección 27.8.3, “Cambiar el nombre del sistema anfitrión”
  4. Instalar el cliente IdM en el host con el nuevo nombre. Para más detalles, consulte Sección 27.8.4, “Reinstalación de un cliente de gestión de identidades”
  5. Configurar el host después de la instalación del cliente IdM. Para más detalles, consulte Sección 27.8.5, “Volver a añadir servicios, volver a generar certificados y volver a añadir grupos de hosts”

27.8.1. Requisitos previos

Antes de desinstalar el cliente actual, tome nota de ciertas configuraciones para el cliente. Aplicará esta configuración después de volver a inscribir la máquina con un nuevo nombre de host.

  • Identificar qué servicios se están ejecutando en la máquina:

    • Utilice el comando ipa service-find, e identifique los servicios con certificados en la salida:

      $ ipa service-find old-client-name.example.com
    • Además, cada host tiene un host service por defecto que no aparece en la salida de ipa service-find. El principal del servicio del host, también llamado host principal, es host/old-client-name.example.com.
  • Para todos los directores de servicio mostrados por ipa service-find old-client-name.example.comdetermine la ubicación de las fichas de claves correspondientes en el old-client-name.example.com sistema:

    # find / -name "*.keytab"

    Cada servicio en el sistema cliente tiene una entidad de seguridad Kerberos de la forma service_name/host_name@REALM, como ldap/old-client-name.example.com@EXAMPLE.COM.

  • Identifica todos los grupos de hosts a los que pertenece la máquina.

    # ipa hostgroup-find old-client-name.example.com

27.8.2. Desinstalación de un cliente de gestión de identidades

La desinstalación de un cliente elimina el cliente del dominio de Gestión de Identidades, junto con toda la configuración específica de Gestión de Identidades de los servicios del sistema, como System Security Services Daemon (SSSD). Esto restablece la configuración anterior del sistema cliente.

Procedimiento

  1. Ejecute el comando ipa-client-install --uninstall:

    [root@client]# ipa-client-install --uninstall
  2. Elimine manualmente del servidor las entradas DNS del host cliente:

    [root@server]# ipa dnsrecord-del
    Record name: old-client-client
    Zone name: idm.example.com
    No option to delete specific record provided.
    Delete all? Yes/No (default No): yes
    ------------------------
    Deleted record "old-client-name"
  3. Para cada keytab identificado que no sea /etc/krb5.keytab, elimine los antiguos principales:

    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
  4. En un servidor IdM, elimine la entrada del host. Esto elimina todos los servicios y revoca todos los certificados emitidos para ese host:

    [root@server ~]# ipa host-del client.example.com

27.8.3. Cambiar el nombre del sistema anfitrión

Cambie el nombre de la máquina según sea necesario. Por ejemplo:

[root@client]# hostnamectl set-hostname new-client-name.example.com

Ahora puede volver a instalar el cliente de gestión de identidades en el dominio de gestión de identidades con el nuevo nombre de host.

27.8.4. Reinstalación de un cliente de gestión de identidades

Instale un cliente en su host renombrado siguiendo el procedimiento descrito en Instalación de un cliente de gestión de identidades: Escenario básico en Installing Identity Management.

27.8.5. Volver a añadir servicios, volver a generar certificados y volver a añadir grupos de hosts

  1. En el servidor de gestión de identidades (IdM), añada un nuevo keytab para cada servicio identificado en Sección 27.8.1, “Requisitos previos”.

    [root@server ~]# ipa service-add service_name/new-client-name
  2. Generar certificados para servicios que tenían un certificado asignado en Sección 27.8.1, “Requisitos previos”. Puede hacer esto:

    • Uso de las herramientas de administración de IdM
    • Utilizando la utilidad certmonger
  3. Vuelva a añadir el cliente a los grupos de hosts identificados en Sección 27.8.1, “Requisitos previos”.

27.9. Desactivación y reactivación de las entradas de host

Esta sección describe cómo desactivar y volver a activar los hosts en la Gestión de Identidades (IdM).

27.9.1. Desactivación de hosts

Realice este procedimiento para desactivar una entrada de host en IdM.

Los servicios de dominio, los hosts y los usuarios pueden acceder a un host activo. Puede haber situaciones en las que sea necesario eliminar un host activo temporalmente, por razones de mantenimiento, por ejemplo. Eliminar el host en tales situaciones no es deseable, ya que elimina la entrada del host y toda la configuración asociada de forma permanente. En su lugar, elija la opción de desactivar el host.

Desactivar un host impide que los usuarios del dominio accedan a él sin eliminarlo permanentemente del dominio. Esto puede hacerse utilizando el comando host-disable. Al deshabilitar un host se eliminan los keytabs actuales y activos del mismo.

Por ejemplo:

$ kinit admin
$ ipa host-disable client.example.com

Al desactivar un host, éste deja de estar disponible para todos los usuarios, hosts y servicios de IdM.

Importante

Desactivar una entrada de host no sólo desactiva ese host. También desactiva todos los servicios configurados en ese host.

27.9.2. Reactivación de hosts

Esta sección describe cómo volver a habilitar un host IdM desactivado.

Al deshabilitar un host se eliminan sus keytabs activos, lo que hace que el host desaparezca del dominio IdM sin tocar su entrada de configuración.

Para volver a habilitar un host, utilice el comando ipa-getkeytab, añadiendo:

  • la opción -s para especificar a qué servidor de IdM solicitar el keytab
  • la opción -p para especificar el nombre del director
  • la opción -k para especificar el archivo en el que guardar el keytab.

Por ejemplo, para solicitar un nuevo keytab de host a server.example.com para client.example.com, y almacenar el keytab en el archivo /etc/krb5.keytab:

$  ipa-getkeytab -s server.example.com -p host/client.example.com -k /etc/krb5.keytab -D "cn=directory manager" -w password
Nota

También puede utilizar las credenciales del administrador, especificando -D "uid=admin,cn=users,cn=accounts,dc=example,dc=com". Es importante que las credenciales correspondan a un usuario autorizado a crear el keytab para el host.

Si el comando ipa-getkeytab se ejecuta en un cliente o servidor IdM activo, puede ejecutarse sin ninguna credencial LDAP (-D y -w) si el usuario tiene un TGT obtenido mediante, por ejemplo, kinit admin. Para ejecutar el comando directamente en el host deshabilitado, proporcione las credenciales LDAP para autenticarse en el servidor IdM.

Capítulo 28. Añadir entradas de host desde la interfaz web de IdM

En este capítulo se presentan los hosts en la Gestión de identidades (IdM) y el funcionamiento de la adición de una entrada de host en la interfaz web de IdM.

28.1. Hosts en IdM

La Gestión de Identidades (IdM) gestiona estas identidades:

  • Usuarios
  • Servicios
  • Anfitriones

Un host representa una máquina. Como identidad IdM, un host tiene una entrada en el LDAP de IdM, es decir, la instancia 389 del servidor IdM.

La entrada de host en IdM LDAP se utiliza para establecer relaciones entre otros hosts e incluso servicios dentro del dominio. Estas relaciones forman parte de delegating autorización y control a los hosts dentro del dominio. Cualquier host puede ser utilizado en las reglas de host-based access control (HBAC).

El dominio de IdM establece una comunidad entre las máquinas, con información de identidad común, políticas comunes y servicios compartidos. Cualquier máquina que pertenezca a un dominio funciona como cliente del mismo, lo que significa que utiliza los servicios que el dominio proporciona. El dominio IdM proporciona tres servicios principales específicos para las máquinas:

  • DNS
  • Kerberos
  • Gestión de certificados

Los hosts en IdM están estrechamente relacionados con los servicios que se ejecutan en ellos:

  • Las entradas de servicio están asociadas a un host.
  • Un host almacena tanto los principales de Kerberos del host como los del servicio.

28.2. Inscripción del anfitrión

Esta sección describe la inscripción de hosts como clientes de IdM y lo que ocurre durante y después de la inscripción. La sección compara la inscripción de hosts y usuarios de IdM. La sección también describe los tipos alternativos de autenticación disponibles para los hosts.

La inscripción de un anfitrión consiste en:

  • Creación de una entrada de host en IdM LDAP: posiblemente utilizando el comandoipa host-add en la CLI de IdM, o la operación equivalente de la interfaz web de IdM.
  • Configurar los servicios de IdM en el host, por ejemplo, el demonio de servicios de seguridad del sistema (SSSD), Kerberos y certmonger, y unir el host al dominio de IdM.

Las dos acciones pueden realizarse por separado o conjuntamente.

Si se realizan por separado, permiten dividir las dos tareas entre dos usuarios con diferentes niveles de privilegio. Esto es útil para los despliegues masivos.

El comando ipa-client-install puede realizar las dos acciones juntas. El comando crea una entrada de host en el LDAP de IdM si esa entrada aún no existe, y configura los servicios Kerberos y SSSD para el host. El comando introduce el host en el dominio IdM y le permite identificar el servidor IdM con el que se conectará. Si el host pertenece a una zona DNS gestionada por IdM, ipa-client-install también añade registros DNS para el host. El comando debe ejecutarse en el cliente.

28.2.1. Privilegios de usuario necesarios para la inscripción en el host

La operación de inscripción de hosts requiere autenticación para evitar que un usuario sin privilegios añada máquinas no deseadas al dominio de IdM. Los privilegios necesarios dependen de varios factores, por ejemplo:

  • Si se crea una entrada de host por separado de la ejecución de ipa-client-install
  • Si se utiliza una contraseña de un solo uso (OTP) para la inscripción
Privilegios de usuario para crear manualmente una entrada de host en IdM LDAP

El privilegio de usuario necesario para crear una entrada de host en IdM LDAP mediante el comando CLI ipa host-add o la interfaz web de IdM es Host Administrators. El privilegio Host Administrators se puede obtener a través del rol IT Specialist.

Privilegios de usuario para unir el cliente al dominio IdM

Los hosts se configuran como clientes IdM durante la ejecución del comando ipa-client-install. El nivel de credenciales necesario para ejecutar el comando ipa-client-install depende de cuál de los siguientes escenarios de inscripción se encuentre:

  • La entrada del host en IdM LDAP no existe. Para este escenario, necesita las credenciales de un administrador completo o el rol Host Administrators. Un administrador completo es un miembro del grupo admins. La función Host Administrators proporciona privilegios para añadir hosts y registrar hosts. Para más detalles sobre este escenario, consulte Instalación de un cliente con credenciales de usuario: instalación interactiva.
  • La entrada del host en IdM LDAP existe. Para este escenario, se necesitan las credenciales de un administrador limitado para ejecutar ipa-client-install con éxito. El administrador limitado en este caso tiene el rol Enrollment Administrator, que proporciona el privilegio Host Enrollment. Para obtener más detalles, consulte Instalación de un cliente con credenciales de usuario: instalación interactiva.
  • La entrada del host en el LDAP de IdM existe, y un administrador completo o limitado ha generado un OTP para el host. En este caso, puede instalar un cliente IdM como un usuario normal si ejecuta el comando ipa-client-install con la opción --password, proporcionando la OTP correcta. Para obtener más información, consulte Instalación de un cliente mediante una contraseña de un solo uso: Instalación interactiva.

Tras la inscripción, los hosts de IdM autentican cada nueva sesión para poder acceder a los recursos de IdM. La autenticación de la máquina es necesaria para que el servidor IdM confíe en ella y acepte las conexiones IdM del software cliente instalado en esa máquina. Después de autenticar al cliente, el servidor IdM puede responder a sus solicitudes.

28.2.2. Registro y autenticación de hosts y usuarios de IdM: comparación

Existen muchas similitudes entre los usuarios y los hosts en IdM. En esta sección se describen algunas de las similitudes que se pueden observar durante la etapa de inscripción, así como las que se refieren a la autenticación durante la etapa de despliegue.

  • La etapa de inscripción (Tabla 28.1, “Inscripción de usuarios y hosts”):

    • Un administrador puede crear una entrada LDAP tanto para un usuario como para un host antes de que el usuario o el host se unan realmente a IdM: para el usuario del escenario, el comando es ipa stageuser-add; para el host, el comando es ipa host-add.
    • Durante la ejecución del comando ipa-client-install en el host se crea un archivo que contiene una key table o, abreviado, keytab, una clave simétrica que se asemeja en cierta medida a una contraseña de usuario, lo que hace que el host se una al reino IdM. De forma análoga, se pide a un usuario que cree una contraseña cuando activa su cuenta, uniéndose así al reino IdM.
    • Mientras que la contraseña de usuario es el método de autenticación por defecto para un usuario, el keytab es el método de autenticación por defecto para un host. El keytab se almacena en un archivo en el host.

    Tabla 28.1. Inscripción de usuarios y hosts

    AcciónUsuarioAnfitrión

    Antes de la inscripción

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

    Activación de la cuenta

    $ ipa stageuser-activate user_name

    $ ipa-client install [--password] (debe ejecutarse en el propio host)

  • La etapa de despliegue (Tabla 28.2, “Autenticación de la sesión del usuario y del host”):

    • Cuando un usuario inicia una nueva sesión, se autentifica utilizando una contraseña; del mismo modo, cada vez que se enciende, el host se autentifica presentando su archivo keytab. El demonio de servicios de seguridad del sistema (SSSD) gestiona este proceso en segundo plano.
    • Si la autenticación tiene éxito, el usuario o el host obtiene un ticket de concesión de Kerberos (TGT).
    • El TGT se utiliza entonces para obtener billetes específicos para servicios concretos.

    Tabla 28.2. Autenticación de la sesión del usuario y del host

     UsuarioAnfitrión

    Medio de autentificación por defecto

    Password

    Keytabs

    Iniciar una sesión (usuario ordinario)

    $ kinit user_name

    [switch on the host]

    El resultado de una autenticación exitosa

    TGT para obtener acceso a servicios específicos

    TGT para obtener acceso a servicios específicos

Los TGT y otros tiques Kerberos se generan como parte de los servicios y políticas Kerberos definidos por el servidor. La concesión inicial de un ticket Kerberos, la renovación de las credenciales Kerberos e incluso la destrucción de la sesión Kerberos son gestionadas automáticamente por los servicios IdM.

28.2.3. Opciones alternativas de autenticación para los hosts de IdM

Además de los keytabs, IdM admite otros dos tipos de autenticación de máquinas:

  • Claves SSH. La clave pública SSH para el host se crea y se carga en la entrada del host. A partir de ahí, el demonio de servicios de seguridad del sistema (SSSD) utiliza IdM como proveedor de identidad y puede trabajar en conjunto con OpenSSH y otros servicios para hacer referencia a las claves públicas ubicadas centralmente en IdM.
  • Certificados de máquina. En este caso, la máquina utiliza un certificado SSL emitido por la autoridad de certificación del servidor de IdM y almacenado en el servidor de directorio de IdM. El certificado se envía entonces a la máquina para que lo presente cuando se autentique en el servidor. En el cliente, los certificados son gestionados por un servicio llamado certmonger.

28.3. Entrada de host en IdM LDAP

Esta sección describe el aspecto de una entrada de host en la Gestión de identidades (IdM) y los atributos que puede contener.

Una entrada de host LDAP contiene toda la información relevante sobre el cliente dentro de IdM:

  • Entradas de servicio asociadas al host
  • El anfitrión y el director del servicio
  • Normas de control de acceso
  • Información sobre la máquina, como su ubicación física y su sistema operativo
Nota

Tenga en cuenta que la pestaña IdM Web UI IdentityHosts no muestra toda la información sobre un host concreto almacenada en el LDAP de IdM.

28.3.1. Propiedades de configuración de la entrada del host

Una entrada de host puede contener información sobre el host que está fuera de su configuración del sistema, como su ubicación física, dirección MAC, claves y certificados.

Esta información puede establecerse cuando se crea la entrada del host si se crea manualmente. Alternativamente, la mayor parte de esta información se puede añadir a la entrada del host después de que el host esté inscrito en el dominio.

Tabla 28.3. Propiedades de configuración del host

Campo UIOpción de línea de comandosDescripción

Descripción

--desc=description

Una descripción del anfitrión.

Localidad

--locality=locality

La ubicación geográfica del anfitrión.

Ubicación

--location=location

La ubicación física del host, como el rack de su centro de datos.

Plataforma

--platform=string

El hardware o la arquitectura del host.

Sistema operativo

--os=string

El sistema operativo y la versión del host.

Dirección MAC

--macaddress=address

La dirección MAC del host. Se trata de un atributo con varios valores. El complemento NIS utiliza la dirección MAC para crear un mapa NIS ethers para el host.

Claves públicas SSH

--sshpubkey=string

La clave pública SSH completa para el host. Este es un atributo multivaluado, por lo que se pueden establecer múltiples claves.

Nombre del director (no editable)

--principalname=principal

El nombre de la entidad de seguridad Kerberos para el host. Por defecto es el nombre del host durante la instalación del cliente, a menos que se establezca explícitamente una entidad de seguridad diferente en -p. Esto puede ser cambiado usando las herramientas de línea de comandos, pero no puede ser cambiado en la UI.

Establecer una contraseña única

--password=string

Esta opción establece una contraseña para el host que se puede utilizar en la inscripción masiva.

-

--random

Esta opción genera una contraseña aleatoria que se utilizará en la inscripción masiva.

-

--certificate=string

Un blob de certificado para el host.

-

--updatedns

Establece si el host puede actualizar dinámicamente sus entradas DNS si su dirección IP cambia.

28.4. Añadir entradas de host desde la interfaz web

  1. Abra la pestaña Identity y seleccione la subpestaña Hosts.
  2. Haga clic en Añadir en la parte superior de la lista de hosts.

    Figura 28.1. Añadir entradas de host

    hosts list
  3. Introduzca el nombre de la máquina y seleccione el dominio de las zonas configuradas en la lista desplegable. Si el host ya tiene asignada una dirección IP estática, inclúyala con la entrada del host para que la entrada DNS se cree completamente.

    El campo Class no tiene ningún propósito específico por el momento.

    Figura 28.2. Asistente para añadir host

    host add

    Las zonas DNS se pueden crear en IdM. Si el servidor IdM no gestiona el servidor DNS, la zona puede introducirse manualmente en el área del menú, como un campo de texto normal.

    Nota

    Seleccione la casilla Force si desea omitir la comprobación de si el host se puede resolver mediante DNS.

  4. Haga clic en el botón Add and Edit para ir directamente a la página de entrada ampliada e introducir más información de atributos. Se puede incluir información sobre el hardware del host y la ubicación física con la entrada del host.

    Figura 28.3. Página de entrada ampliada

    host attr

Capítulo 29. Gestión de los hosts mediante libros de juego de Ansible

Ansible es una herramienta de automatización que se utiliza para configurar sistemas, desplegar software y realizar actualizaciones continuas. Ansible incluye soporte para la gestión de identidades (IdM), y puede utilizar módulos de Ansible para automatizar la gestión de hosts.

En este capítulo se describen las siguientes operaciones que se realizan cuando se gestionan los hosts y las entradas de hosts mediante los libros de reproducción de Ansible:

29.1. Garantizar la presencia de una entrada de host de IdM con FQDN utilizando los libros de juego de Ansible

En esta sección se describe cómo garantizar la presencia de entradas de host en Identity Management (IdM) mediante los libros de juego de Ansible. Las entradas de host sólo se definen por su fully-qualified domain names (FQDNs).

Especificar el nombre FQDN del host es suficiente si se cumple al menos una de las siguientes condiciones:

  • El servidor IdM no está configurado para gestionar el DNS.
  • El host no tiene una dirección IP estática o la dirección IP no se conoce en el momento de configurar el host. Al añadir un host definido únicamente por un FQDN se crea esencialmente una entrada de marcador de posición en el servicio DNS de IdM. Por ejemplo, los ordenadores portátiles pueden estar preconfigurados como clientes IdM, pero no tienen direcciones IP en el momento en que se configuran. Cuando el servicio DNS actualiza dinámicamente sus registros, se detecta la dirección IP actual del host y se actualiza su registro DNS.
Nota

Sin Ansible, las entradas de host se crean en IdM mediante el comando ipa host-add. El resultado de añadir un host a IdM es el estado del host presente en IdM. Debido a la dependencia de Ansible en la idempotencia, para añadir un host a IdM utilizando Ansible, debe crear un libro de jugadas en el que se define el estado del host como presente: state: present.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • El paquete ansible-freeipa está instalado en el controlador Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Crea un archivo de playbook de Ansible con el FQDN del host cuya presencia en IdM quieres asegurar. Para simplificar este paso, puedes copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/host/add-host.yml:

    ---
    - name: Host present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Host host01.idm.example.com present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          state: present
          force: yes
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
Nota

El procedimiento da lugar a la creación de una entrada de host en el servidor LDAP de IdM, pero no a la inscripción del host en el ámbito de Kerberos de IdM. Para ello, debe implementar el host como cliente de IdM. Para obtener más detalles, consulte Instalación de un cliente de gestión de identidades mediante un libro de jugadas de Ansible.

Pasos de verificación

  1. Inicie sesión en su servidor IdM como administrador:

    $ ssh admin@server.idm.example.com
    Password:
  2. Introduzca el comando ipa host-show y especifique el nombre del host:

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

La salida confirma que host01.idm.example.com existe en IdM.

29.2. Garantizar la presencia de una entrada de host de IdM con información de DNS utilizando los libros de juego de Ansible

En esta sección se describe cómo garantizar la presencia de entradas de host en Identity Management (IdM) mediante los libros de juego de Ansible. Las entradas de host se definen por su fully-qualified domain names (FQDNs) y sus direcciones IP.

Nota

Sin Ansible, las entradas de host se crean en IdM mediante el comando ipa host-add. El resultado de añadir un host a IdM es el estado del host presente en IdM. Debido a la dependencia de Ansible en la idempotencia, para añadir un host a IdM utilizando Ansible, debe crear un libro de jugadas en el que se define el estado del host como presente: state: present.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • El paquete ansible-freeipa está instalado en el controlador Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con el fully-qualified domain name (FQDN) del host cuya presencia en IdM desea asegurar. Además, si el servidor IdM está configurado para gestionar DNS y conoce la dirección IP del host, especifique un valor para el parámetro ip_address. La dirección IP es necesaria para que el host exista en los registros de recursos DNS. Para simplificar este paso, puede copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/host/host-present.yml. También puede incluir otra información adicional:

    ---
    - name: Host present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure host01.idm.example.com is present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          description: Example host
          ip_address: 192.168.0.123
          locality: Lab
          ns_host_location: Lab
          ns_os_version: CentOS 7
          ns_hardware_platform: Lenovo T61
          mac_address:
          - "08:00:27:E3:B1:2D"
          - "52:54:00:BD:97:1E"
          state: present
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
Nota

El procedimiento da lugar a la creación de una entrada de host en el servidor LDAP de IdM, pero no a la inscripción del host en el ámbito de Kerberos de IdM. Para ello, debe implementar el host como cliente de IdM. Para obtener más detalles, consulte Instalación de un cliente de gestión de identidades mediante un libro de jugadas de Ansible.

Pasos de verificación

  1. Inicie sesión en su servidor IdM como administrador:

    $ ssh admin@server.idm.example.com
    Password:
  2. Introduzca el comando ipa host-show y especifique el nombre del host:

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Description: Example host
      Locality: Lab
      Location: Lab
      Platform: Lenovo T61
      Operating system: CentOS 7
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      MAC address: 08:00:27:E3:B1:2D, 52:54:00:BD:97:1E
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

La salida confirma que host01.idm.example.com existe en IdM.

29.3. Garantizar la presencia de múltiples entradas de host IdM con contraseñas aleatorias utilizando los playbooks de Ansible

El módulo ipahost permite al administrador del sistema asegurar la presencia o ausencia de múltiples entradas de host en IdM utilizando una sola tarea Ansible. Esta sección describe cómo asegurar la presencia de múltiples entradas de host que sólo están definidas por su fully-qualified domain names (FQDNs). La ejecución del playbook de Ansible genera contraseñas aleatorias para los hosts.

Nota

Sin Ansible, las entradas de host se crean en IdM mediante el comando ipa host-add. El resultado de añadir un host a IdM es el estado del host presente en IdM. Debido a la dependencia de Ansible en la idempotencia, para añadir un host a IdM utilizando Ansible, debe crear un libro de jugadas en el que se define el estado del host como presente: state: present.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • El paquete ansible-freeipa está instalado en el controlador Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Crea un archivo de playbook de Ansible con el fully-qualified domain name (FQDN) de los hosts cuya presencia en IdM quieres asegurar. Para que el playbook de Ansible genere una contraseña aleatoria para cada host incluso cuando el host ya existe en IdM y update_password se limita a on_create, añade las opciones random: yes y force: yes. Para simplificar este paso, puedes copiar y modificar el ejemplo del archivo Markdown de /usr/share/doc/ansible-freeipa/README-host.md:

    ---
    - name: Ensure hosts with random password
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Hosts host01.idm.example.com and host02.idm.example.com present with random passwords
        ipahost:
          ipaadmin_password: MySecret123
          hosts:
          - name: host01.idm.example.com
            random: yes
            force: yes
          - name: host02.idm.example.com
            random: yes
            force: yes
        register: ipahost
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-are-present.yml
    [...]
    TASK [Hosts host01.idm.example.com and host02.idm.example.com present with random passwords]
    changed: [r8server.idm.example.com] => {"changed": true, "host": {"host01.idm.example.com": {"randompassword": "0HoIRvjUdH0Ycbf6uYdWTxH"}, "host02.idm.example.com": {"randompassword": "5VdLgrf3wvojmACdHC3uA3s"}}}

Pasos de verificación

  1. Inicie sesión en su servidor IdM como administrador:

    $ ssh admin@server.idm.example.com
    Password:
  2. Introduzca el comando ipa host-show y especifique el nombre de uno de los hosts:

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Password: True
      Keytab: False
      Managed by: host01.idm.example.com

La salida confirma que host01.idm.example.com existe en IdM con una contraseña aleatoria.

29.4. Garantizar la presencia de una entrada de host de IdM con múltiples direcciones IP utilizando los playbooks de Ansible

En esta sección se describe cómo garantizar la presencia de una entrada de host en Identity Management (IdM) mediante los libros de juego de Ansible. La entrada de host se define por su fully-qualified domain name (FQDN) y sus múltiples direcciones IP.

Nota

A diferencia de la utilidad ipa host, el módulo de Ansible ipahost puede asegurar la presencia o ausencia de varias direcciones IPv4 e IPv6 para un host. El comando ipa host-mod no puede manejar direcciones IP.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • El paquete ansible-freeipa está instalado en el controlador Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo Ansible playbook. Especifique, como name de la variable ipahost, el fully-qualified domain name (FQDN) del host cuya presencia en IdM desea asegurar. Especifique cada uno de los múltiples valores de IPv4 e IPv6 ip_address en una línea separada utilizando la sintaxis - ip_address sintaxis. Para simplificar este paso, puede copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/host/host-member-ipaddresses-present.yml. También puede incluir información adicional:

    ---
    - name: Host member IP addresses present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure host101.example.com IP addresses present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          ip_address:
          - 192.168.0.123
          - fe80::20c:29ff:fe02:a1b3
          - 192.168.0.124
          - fe80::20c:29ff:fe02:a1b4
          force: yes
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-with-multiple-IP-addreses-is-present.yml
Nota

El procedimiento crea una entrada de host en el servidor LDAP de IdM, pero no inscribe el host en el ámbito de IdM Kerberos. Para ello, debe implementar el host como cliente de IdM. Para obtener más detalles, consulte Instalación de un cliente de gestión de identidades mediante un libro de jugadas de Ansible.

Pasos de verificación

  1. Inicie sesión en su servidor IdM como administrador:

    $ ssh admin@server.idm.example.com
    Password:
  2. Introduzca el comando ipa host-show y especifique el nombre del host:

    $ ipa host-show host01.idm.example.com
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

    La salida confirma que host01.idm.example.com existe en IdM.

  3. Para verificar que las múltiples direcciones IP del host existen en los registros DNS de IdM, introduzca el comando ipa dnsrecord-show y especifique la siguiente información:

    • El nombre del dominio IdM
    • El nombre del anfitrión

      $ ipa dnsrecord-show idm.example.com host01
      [...]
        Record name: host01
        A record: 192.168.0.123, 192.168.0.124
        AAAA record: fe80::20c:29ff:fe02:a1b3, fe80::20c:29ff:fe02:a1b4

    La salida confirma que todas las direcciones IPv4 e IPv6 especificadas en el libro de jugadas están correctamente asociadas a la entrada de host host01.idm.example.com.

29.5. Garantizar la ausencia de una entrada en el host de IdM utilizando los playbooks de Ansible

En esta sección se describe cómo garantizar la ausencia de entradas de host en Identity Management (IdM) mediante los libros de juego de Ansible.

Requisitos previos

  • Credenciales de administrador de IdM

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con el fully-qualified domain name (FQDN) del host cuya ausencia de IdM desea asegurar. Si tu dominio IdM tiene DNS integrado, utiliza la opción updatedns: yes para eliminar los registros asociados de cualquier tipo para el host desde el DNS.

    Para simplificar este paso, puede copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/host/delete-host.yml:

    ---
    - name: Host absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Host host01.idm.example.com absent
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          updatedns: yes
          state: absent
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-absent.yml
Nota

El procedimiento da como resultado:

  • El host no está presente en el reino de IdM Kerberos.
  • La entrada del host no está presente en el servidor LDAP de IdM.

Para eliminar la configuración específica de IdM de los servicios del sistema, como el demonio de servicios de seguridad del sistema (SSSD), del propio host cliente, debe ejecutar el comando ipa-client-install --uninstall en el cliente. Para obtener más detalles, consulte Desinstalación de un cliente IdM.

Pasos de verificación

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar información sobre host01.idm.example.com:

    $ ipa host-show host01.idm.example.com
    ipa: ERROR: host01.idm.example.com: host not found

La salida confirma que el host no existe en IdM.

Recursos adicionales

  • Puede ver las definiciones de las variables de ipahost, así como ejemplos de libros de juego de Ansible para garantizar la presencia, la ausencia y la desactivación de hosts en el archivo /usr/share/doc/ansible-freeipa/README-host.md Markdown.
  • En el directorio /usr/share/doc/ansible-freeipa/playbooks/host hay más libros de juego.

Capítulo 30. Gestión de grupos de hosts mediante la CLI de IdM

En este capítulo se presentan los grupos de hosts en Identity Management (IdM) y se describen las siguientes operaciones para gestionar los grupos de hosts y sus miembros en la interfaz de línea de comandos (CLI):

  • Ver los grupos de acogida y sus miembros
  • Creación de grupos de acogida
  • Borrado de grupos de hosts
  • Añadir miembros del grupo de anfitriones
  • Eliminación de miembros del grupo anfitrión
  • Añadir administradores de miembros de grupos anfitriones
  • Eliminación de los administradores de los miembros del grupo anfitrión

30.1. Grupos de acogida en IdM

Los grupos de hosts de IdM pueden utilizarse para centralizar el control de importantes tareas de gestión, en particular el control de acceso.

Definición de grupos de acogida

Un grupo de hosts es una entidad que contiene un conjunto de hosts IdM con reglas de control de acceso comunes y otras características. Por ejemplo, se pueden definir grupos de hosts en función de los departamentos de la empresa, las ubicaciones físicas o los requisitos de control de acceso.

Un grupo de hosts en IdM puede incluir:

  • Servidores y clientes de IdM
  • Otros grupos de acogida de IdM

Grupos de hosts creados por defecto

Por defecto, el servidor IdM crea el grupo de hosts ipaservers para todos los hosts del servidor IdM.

Miembros directos e indirectos del grupo

Los atributos de grupo en IdM se aplican tanto a los miembros directos como a los indirectos: cuando el grupo de host B es miembro del grupo de host A, todos los miembros del grupo de host B se consideran miembros indirectos del grupo de host A.

30.2. Visualización de los grupos de hosts de IdM mediante la CLI

Esta sección describe cómo ver los grupos de hosts de IdM mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  1. Encuentre todos los grupos de hosts utilizando el comando ipa hostgroup-find.

    $ ipa hostgroup-find
    -------------------
    1 hostgroup matched
    -------------------
      Host-group: ipaservers
      Description: IPA server hosts
    ----------------------------
    Number of entries returned 1
    ----------------------------

    Para mostrar todos los atributos de un grupo de hosts, añada la opción --all. Por ejemplo:

    $ ipa hostgroup-find --all
    -------------------
    1 hostgroup matched
    -------------------
      dn: cn=ipaservers,cn=hostgroups,cn=accounts,dc=idm,dc=local
      Host-group: ipaservers
      Description: IPA server hosts
      Member hosts: xxx.xxx.xxx.xxx
      ipauniqueid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      objectclass: top, groupOfNames, nestedGroup, ipaobject, ipahostgroup
    ----------------------------
    Number of entries returned 1
    ----------------------------

30.3. Creación de grupos de hosts IdM mediante la CLI

Esta sección describe cómo crear grupos de hosts IdM mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  1. Añade un grupo de hosts con el comando ipa hostgroup-add.
    Por ejemplo, para crear un grupo de hosts IdM llamado group_name y darle una descripción:

    $ ipa hostgroup-add --desc 'My new host group' group_name
    ---------------------
    Added hostgroup "group_name"
    ---------------------
      Host-group: group_name
      Description: My new host group
    ---------------------

30.4. Eliminación de grupos de hosts IdM mediante la CLI

En esta sección se describe cómo eliminar grupos de hosts IdM mediante la interfaz de línea de comandos (CLI).

Requisitos previos

Procedimiento

  1. Elimine un grupo de hosts con el comando ipa hostgroup-del.
    Por ejemplo, para eliminar el grupo de hosts IdM denominado group_name:

    $ ipa hostgroup-del group_name
    --------------------------
    Deleted hostgroup "group_name"
    --------------------------
Nota

La eliminación de un grupo no elimina los miembros del grupo del IdM.

30.5. Adición de miembros del grupo de hosts IdM mediante la CLI

Puede añadir hosts y grupos de hosts como miembros de un grupo de hosts IdM mediante un único comando.

Requisitos previos

  • Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
  • Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
  • Optional. Utilice el comando ipa hostgroup-find para encontrar hosts y grupos de hosts.

Procedimiento

  1. Para añadir un miembro a un grupo de hosts, utilice la dirección ipa hostgroup-add-member y proporcione la información pertinente. Puedes especificar el tipo de miembro a añadir utilizando estas opciones

    • Utilice la opción --hosts para añadir uno o varios hosts a un grupo de hosts IdM.
      Por ejemplo, para añadir el host denominado example_member al grupo denominado group_name:

      $ ipa hostgroup-add-member group_name --hosts example_member
      Host-group: group_name
      Description: My host group
      Member hosts: example_member
      -------------------------
      Number of members added 1
      -------------------------
    • Utilice la opción --hostgroups para añadir uno o varios grupos de hosts a un grupo de hosts IdM.
      Por ejemplo, para añadir el grupo de hosts denominado nested_group al grupo denominado group_name:

      $ ipa hostgroup-add-member group_name --hostgroups nested_group
      Host-group: group_name
      Description: My host group
      Member host-groups: nested_group
      -------------------------
      Number of members added 1
      -------------------------
    • Puede añadir varios hosts y varios grupos de hosts a un grupo de hosts IdM con un solo comando utilizando la siguiente sintaxis:

      $ ipa hostgroup-add-member group_name --hosts={host1,host2} --hostgroups={group1,group2}
Importante

Cuando añada un grupo de hosts como miembro de otro grupo de hosts, no cree grupos recursivos. Por ejemplo, si el grupo A es miembro del grupo B, no añada el grupo B como miembro del grupo A. Los grupos recursivos pueden provocar un comportamiento imprevisible.

30.6. Eliminación de los miembros del grupo de hosts de IdM mediante la CLI

Puede eliminar tanto los hosts como los grupos de hosts de un grupo de hosts IdM mediante un único comando.

Requisitos previos

  • Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
  • Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
  • Optional. Utilice el comando ipa hostgroup-find para confirmar que el grupo incluye al miembro que desea eliminar.

Procedimiento

  1. Para eliminar un miembro del grupo de hosts, utilice el comando ipa hostgroup-remove-member y proporcione la información pertinente. Puedes especificar el tipo de miembro a eliminar utilizando estas opciones

    • Utilice la opción --hosts para eliminar uno o varios hosts de un grupo de hosts IdM.
      Por ejemplo, para eliminar el host denominado example_member del grupo denominado group_name:

      $ ipa hostgroup-remove-member group_name --hosts example_member
      Host-group: group_name
      Description: My host group
      -------------------------
      Number of members removed 1
      -------------------------
    • Utilice la opción --hostgroups para eliminar uno o varios grupos de hosts de un grupo de hosts IdM.
      Por ejemplo, para eliminar el grupo de hosts denominado nested_group del grupo denominado group_name:

      $ ipa hostgroup-remove-member group_name --hostgroups example_member
      Host-group: group_name
      Description: My host group
      -------------------------
      Number of members removed 1
      -------------------------
Nota

La eliminación de un grupo no elimina los miembros del grupo del IdM.

  • Puede eliminar varios hosts y varios grupos de hosts de un grupo de hosts IdM en un solo comando utilizando la siguiente sintaxis:

    $ ipa hostgroup-remove-member group_name --hosts={host1,host2} --hostgroups={group1,group2}

30.7. Adición de administradores de grupos de hosts IdM mediante la CLI

Puede añadir hosts y grupos de hosts como administradores miembros a un grupo de hosts IdM mediante un único comando. Los administradores miembros pueden añadir hosts o grupos de hosts a los grupos de hosts IdM, pero no pueden cambiar los atributos de un grupo de hosts.

Requisitos previos

  • Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
  • Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
  • Debes tener el nombre del host o grupo de host que estás añadiendo como miembros gestores y el nombre del grupo de host que quieres que gestionen.

Procedimiento

  1. Optional. Utilice el comando ipa hostgroup-find para encontrar hosts y grupos de hosts.
  2. Para añadir un gestor de miembros a un grupo de hosts, utilice la dirección ipa hostgroup-add-member-manager.

    Por ejemplo, para añadir el usuario llamado example_member como miembro administrador del grupo llamado group_name:

    $ ipa hostgroup-add-member-manager group_name --user example_member
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Member of netgroups: group_name
    Membership managed by users: example_member
    -------------------------
    Number of members added 1
    -------------------------
  3. Utilice la opción --groups para añadir uno o varios grupos de hosts como gestores miembros de un grupo de hosts IdM.

    Por ejemplo, para añadir el grupo de hosts llamado admin_group como miembro administrador del grupo llamado group_name:

    $ ipa hostgroup-add-member-manager group_name --groups admin_group
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Member of netgroups: group_name
    Membership managed by groups: admin_group
    Membership managed by users: example_member
    -------------------------
    Number of members added 1
    -------------------------
Nota

Después de añadir un gestor de miembros a un grupo de hosts, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de gestión de identidades.

Pasos de verificación

  • Utilizar el comando ipa group-show para verificar que el usuario y el grupo del host se han añadido como administradores miembros.

    $ ipa hostgroup-show group_name
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Membership managed by groups: admin_group
    Membership managed by users: example_member

Recursos adicionales

  • Consulte ipa hostgroup-add-member-manager --help para más detalles.
  • Consulte ipa hostgroup-show --help para más detalles.

30.8. Eliminación de gestores de grupos de hosts IdM mediante la CLI

Puede eliminar hosts y grupos de hosts como administradores miembros de un grupo de hosts IdM mediante un único comando. Los administradores miembros pueden eliminar administradores miembros de grupos de hosts de IdM, pero no pueden cambiar los atributos de un grupo de hosts.

Requisitos previos

  • Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
  • Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
  • Debe tener el nombre del grupo de host del gestor de miembros existente que está eliminando y el nombre del grupo de host que está gestionando.

Procedimiento

  1. Optional. Utilice el comando ipa hostgroup-find para encontrar hosts y grupos de hosts.
  2. Para eliminar un gestor de miembros de un grupo de hosts, utilice el comando ipa hostgroup-remove-member-manager.

    Por ejemplo, para eliminar al usuario llamado example_member como miembro administrador del grupo llamado group_name:

    $ ipa hostgroup-remove-member-manager group_name --user example_member
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Member of netgroups: group_name
    Membership managed by groups: nested_group
    ---------------------------
    Number of members removed 1
    ---------------------------
  3. Utilice la opción --groups para eliminar uno o varios grupos de hosts como administrador de miembros de un grupo de hosts IdM.

    Por ejemplo, para eliminar el grupo de hosts llamado nested_group como administrador de miembros del grupo llamado group_name:

    $ ipa hostgroup-remove-member-manager group_name --groups nested_group
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Member of netgroups: group_name
    ---------------------------
    Number of members removed 1
    ---------------------------
Nota

Después de eliminar un gestor de miembros de un grupo de hosts, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de Gestión de identidades.

Pasos de verificación

  • Utilice el comando ipa group-show para verificar que el usuario y el grupo del host se han eliminado como administradores miembros.

    $ ipa hostgroup-show group_name
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins

Recursos adicionales

  • Consulte ipa hostgroup-remove-member-manager --help para más detalles.
  • Consulte ipa hostgroup-show --help para más detalles.

Capítulo 31. Gestión de grupos de hosts mediante la interfaz web de IdM

En este capítulo se presentan los grupos de hosts en la Gestión de identidades (IdM) y se describen las siguientes operaciones para gestionar los grupos de hosts y sus miembros en la interfaz web (Web UI):

  • Ver los grupos de acogida y sus miembros
  • Creación de grupos de acogida
  • Borrado de grupos de hosts
  • Añadir miembros del grupo de anfitriones
  • Eliminación de miembros del grupo anfitrión
  • Añadir administradores de miembros de grupos anfitriones
  • Eliminación de los administradores de los miembros del grupo anfitrión

31.1. Grupos de acogida en IdM

Los grupos de hosts de IdM pueden utilizarse para centralizar el control de importantes tareas de gestión, en particular el control de acceso.

Definición de grupos de acogida

Un grupo de hosts es una entidad que contiene un conjunto de hosts IdM con reglas de control de acceso comunes y otras características. Por ejemplo, se pueden definir grupos de hosts en función de los departamentos de la empresa, las ubicaciones físicas o los requisitos de control de acceso.

Un grupo de hosts en IdM puede incluir:

  • Servidores y clientes de IdM
  • Otros grupos de acogida de IdM

Grupos de hosts creados por defecto

Por defecto, el servidor IdM crea el grupo de hosts ipaservers para todos los hosts del servidor IdM.

Miembros directos e indirectos del grupo

Los atributos de grupo en IdM se aplican tanto a los miembros directos como a los indirectos: cuando el grupo de host B es miembro del grupo de host A, todos los miembros del grupo de host B se consideran miembros indirectos del grupo de host A.

31.2. Visualización de los grupos de hosts en la interfaz web de IdM

Esta sección describe cómo ver los grupos de hosts de IdM mediante la interfaz web (Web UI).

Requisitos previos

Procedimiento

  1. Haga clic en Identity → Groups, y seleccione la pestaña Host Groups.

    • La página enumera los grupos de hosts existentes y sus descripciones.
    • Puede buscar un grupo de hosts específico.

    idm viendo grupos de hosts

  2. Haga clic en un grupo de la lista para mostrar los hosts que pertenecen a este grupo. Puede limitar los resultados a los miembros directos o indirectos.

    idm viendo los miembros del grupo anfitrión

  3. Seleccione la pestaña Host Groups para mostrar los grupos de hosts que pertenecen a este grupo (grupos de hosts anidados). Puede limitar los resultados a los miembros directos o indirectos.

    idm viendo los miembros del grupo anfitrión grupo anidado

31.3. Creación de grupos de hosts en la interfaz web de IdM

Esta sección describe cómo crear grupos de hosts de IdM mediante la interfaz web (Web UI).

Requisitos previos

Procedimiento

  1. Haga clic en Identity → Groups, y seleccione la pestaña Host Groups.
  2. Haga clic en Add. Aparece el cuadro de diálogo Add host group.
  3. Proporcione la información sobre el grupo: nombre (obligatorio) y descripción (opcional).
  4. Haga clic en Add para confirmar.

    idm creando grupos de hosts

31.4. Eliminación de grupos de hosts en la interfaz web de IdM

Esta sección describe cómo eliminar los grupos de hosts IdM mediante la interfaz web (Web UI).

Requisitos previos

Procedimiento

  1. Haga clic en Identity → Groups y seleccione la pestaña Host Groups.
  2. Seleccione el grupo de hosts IdM que desea eliminar y haga clic en Delete. Aparece un diálogo de confirmación.
  3. Haga clic en Delete para confirmar

    idm borrando grupos de hosts

Nota

La eliminación de un grupo de hosts no elimina los miembros del grupo del IdM.

31.5. Añadir miembros del grupo de hosts en la interfaz web de IdM

Esta sección describe cómo añadir miembros de grupos de hosts en IdM mediante la interfaz web (Web UI).

Requisitos previos

Procedimiento

  1. Haga clic en Identity → Groups y seleccione la pestaña Host Groups.
  2. Haga clic en el nombre del grupo al que desea añadir miembros.
  3. Haga clic en la pestaña Hosts o Host groups según el tipo de miembros que desee añadir. Aparece el diálogo correspondiente.
  4. Seleccione los hosts o grupos de hosts que desee añadir y haga clic en el botón de flecha > para moverlos a la columna Prospective.
  5. Haga clic en Add para confirmar.

    idm añadiendo miembros del grupo de hosts

31.6. Eliminación de miembros del grupo de hosts en la interfaz web de IdM

Esta sección describe cómo eliminar miembros de grupos de hosts en IdM mediante la interfaz web (Web UI).

Requisitos previos

Procedimiento

  1. Haga clic en Identity → Groups y seleccione la pestaña Host Groups.
  2. Haga clic en el nombre del grupo del que desea eliminar miembros.
  3. Haga clic en la pestaña Hosts o Host groups según el tipo de miembros que desee eliminar.
  4. Seleccione la casilla junto al miembro que desea eliminar.
  5. Haga clic en Eliminar. Aparece un diálogo de confirmación.

    idm eliminando miembros del grupo de hosts

  6. Haga clic en Eliminar para confirmar. Los miembros seleccionados se eliminan.

31.7. Adición de administradores de grupos de hosts IdM mediante la interfaz web

Esta sección describe cómo añadir usuarios o grupos de usuarios como administradores de miembros de grupos de hosts en IdM mediante la interfaz web (Web UI). Los administradores miembros pueden añadir administradores miembros de grupos de hosts a los grupos de hosts de IdM, pero no pueden cambiar los atributos de un grupo de hosts.

Requisitos previos

  • Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
  • Ha iniciado una sesión en la interfaz web de IdM. Para obtener más información, consulte Acceso a la interfaz web de IdM en un navegador web.
  • Debes tener el nombre del grupo de hosts que estás añadiendo como miembros administradores y el nombre del grupo de hosts que quieres que administren.

Procedimiento

  1. Haga clic en Identity → Groups y seleccione la pestaña Host Groups.

    hostgroups
  2. Haga clic en el nombre del grupo al que desea añadir administradores miembros.
  3. Haga clic en la pestaña de gestores de miembros User Groups o Users según el tipo de gestores de miembros que desee añadir. Aparecerá el diálogo correspondiente.
  4. Haga clic en Add.

    group membermanagers
  5. Seleccione los usuarios o grupos de usuarios que desee añadir y haga clic en el botón de flecha > para moverlos a la columna Prospective.
  6. Haga clic en Add para confirmar.
Nota

Después de añadir un gestor de miembros a un grupo de hosts, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de gestión de identidades.

Pasos de verificación

  • En el cuadro de diálogo del grupo anfitrión, compruebe que el grupo de usuarios o el usuario se ha añadido a la lista de grupos o usuarios de los administradores de miembros.

    membermanager added

31.8. Eliminación de los administradores de grupos de hosts de IdM mediante la interfaz web

Esta sección describe cómo eliminar usuarios o grupos de usuarios como administradores de miembros de grupos de hosts en IdM mediante la interfaz web (Web UI). Los administradores de miembros pueden eliminar a los administradores de miembros de grupos de hosts de IdM, pero no pueden cambiar los atributos de un grupo de hosts.

Requisitos previos

  • Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
  • Ha iniciado una sesión en la interfaz web de IdM. Para obtener más información, consulte Acceso a la interfaz web de IdM en un navegador web.
  • Debe tener el nombre del grupo de host del gestor de miembros existente que está eliminando y el nombre del grupo de host que está gestionando.

Procedimiento

  1. Haga clic en Identity → Groups y seleccione la pestaña Host Groups.

    hostgroup tab
  2. Haga clic en el nombre del grupo del que desea eliminar a los administradores miembros.
  3. Haga clic en la pestaña de gestores de miembros User Groups o Users según el tipo de gestores de miembros que desee eliminar. Aparecerá el diálogo correspondiente.
  4. Seleccione el usuario o los grupos de usuarios que desea eliminar y haga clic en Delete.
  5. Haga clic en Delete para confirmar.

    idm removing host group member managers
    Nota

    Después de eliminar un gestor de miembros de un grupo de hosts, la actualización puede tardar algún tiempo en extenderse a todos los clientes de su entorno de Gestión de identidades.

Pasos de verificación

  • En el cuadro de diálogo del grupo anfitrión, compruebe que el grupo de usuarios o el usuario se ha eliminado de la lista de grupos o usuarios de los administradores de miembros.

    remove membermanager verification

Capítulo 32. Gestión de grupos de hosts mediante los playbooks de Ansible

En este capítulo se describe el uso de Ansible para realizar las siguientes operaciones relacionadas con los grupos de hosts en la gestión de identidades (IdM):

32.1. Garantizar la presencia de los grupos de hosts de IdM mediante los playbooks de Ansible

En esta sección se describe cómo garantizar la presencia de grupos de hosts en Identity Management (IdM) mediante los libros de juego de Ansible.

Nota

Sin Ansible, las entradas de grupos de hosts se crean en IdM mediante el comando ipa hostgroup-add. El resultado de añadir un grupo de hosts a IdM es el estado del grupo de hosts presente en IdM. Debido a la dependencia de Ansible en la idempotencia, para añadir un grupo de hosts a IdM utilizando Ansible, debe crear un libro de jugadas en el que se define el estado del grupo de hosts como presente: state: present.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver con la lista de servidores IdM a los que dirigirse:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria del grupo de hosts. Por ejemplo, para garantizar la presencia de un grupo de hosts llamado databases, especifique name: databases en la tarea - ipahostgroup. Para simplificar este paso, puede copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-present.yml.

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is present
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          state: present

    En el libro de jugadas, state: present significa una solicitud para añadir el grupo de hosts a IdM a menos que ya exista allí.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-present.yml

Pasos de verificación

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicitar un ticket Kerberos para el administrador:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Muestra información sobre el grupo de hosts cuya presencia en IdM desea asegurar:

    $ ipa hostgroup-show databases
      Host-group: databases

El grupo de hosts databases existe en IdM.

32.2. Garantizar la presencia de los hosts en los grupos de hosts de IdM mediante los libros de juego de Ansible

En esta sección se describe cómo garantizar la presencia de hosts en grupos de hosts en Identity Management (IdM) mediante los libros de juego de Ansible.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver con la lista de servidores IdM a los que dirigirse:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria del host. Especifique el nombre del grupo de hosts con el parámetro name de la variable ipahostgroup. Especifique el nombre del host con el parámetro host de la variable ipahostgroup. Para simplificar este paso, puede copiar y modificar los ejemplos en el archivo /usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml:

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is present
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          host:
          - db.idm.example.com
          action: member

    Este libro de jugadas añade el host db.idm.example.com al grupo de hosts databases. La línea action: member indica que cuando se ejecuta el libro de jugadas, no se intenta añadir el grupo databases. En su lugar, sólo se intenta añadir db.idm.example.com a databases.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml

Pasos de verificación

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicitar un ticket Kerberos para el administrador:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Muestra información sobre un grupo de hosts para ver qué hosts están presentes en él:

    $ ipa hostgroup-show databases
      Host-group: databases
      Member hosts: db.idm.example.com

El host db.idm.example.com está presente como miembro del grupo de hosts databases.

32.3. Anidación de grupos de hosts de IdM mediante libros de juego de Ansible

En esta sección se describe cómo garantizar la presencia de grupos de hosts anidados en los grupos de hosts de Identity Management (IdM) mediante los libros de juego de Ansible.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver con la lista de servidores IdM a los que dirigirse:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria del grupo de hosts. Para asegurarse de que un grupo de hosts anidado A existe en un grupo de hosts B: en el libro de jugadas de Ansible, especifique, entre las variables - ipahostgroup, el nombre del grupo de hosts B con la variable name. Especifique el nombre del grupo de hosts anidado A con la variable hostgroup. Para simplificar este paso, puede copiar y modificar los ejemplos en el archivo /usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml:

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure hosts and hostgroups are present in existing databases hostgroup
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          hostgroup:
          - mysql-server
          - oracle-server
          action: member

    Este libro de jugadas de Ansible garantiza la presencia de los grupos de hosts myqsl-server y oracle-server en el grupo de hosts databases. La línea action: member indica que cuando se ejecuta el libro de jugadas, no se intenta añadir el grupo databases a IdM.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml

Pasos de verificación

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicitar un ticket Kerberos para el administrador:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Muestra información sobre el grupo de hosts en el que hay grupos de hosts anidados:

    $ ipa hostgroup-show databases
      Host-group: databases
      Member hosts: db.idm.example.com
      Member host-groups: mysql-server, oracle-server

Los grupos de hosts mysql-server y oracle-server existen en el grupo de hosts databases.

32.4. Garantizar la presencia de los administradores miembros en los grupos de hosts de IDM utilizando Ansible Playbooks

El siguiente procedimiento describe cómo garantizar la presencia de los administradores de miembros en los hosts y grupos de hosts de IdM mediante un libro de jugadas de Ansible.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
  • Debes tener el nombre del host o grupo de host que estás añadiendo como miembros gestores y el nombre del grupo de host que quieres que gestionen.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria para la gestión del host y de los miembros del grupo del host:

    ---
    
    - name: Playbook to handle host group membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager user example_member is present for group_name
          ipahostgroup:
            ipaadmin_password: MySecret123
            name: group_name
            membermanager_user: example_member
    
      - name: Ensure member manager group project_admins is present for group_name
          ipahostgroup:
            ipaadmin_password: MySecret123
            name: group_name
            membermanager_group: project_admins
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-host-groups.yml

Pasos de verificación

Puede verificar si el grupo group_name contiene example_member y project_admins como administradores miembros utilizando el comando ipa group-show:

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar información sobre testhostgroup:

    ipaserver]$ ipa hostgroup-show group_name
      Host-group: group_name
      Member hosts: server.idm.example.com
      Member host-groups: testhostgroup2
      Membership managed by groups: project_admins
      Membership managed by users: example_member

Recursos adicionales

  • Véase ipa hostgroup-add-member-manager --help.
  • Consulte la página de manual ipa.

32.5. Garantizar la ausencia de hosts de los grupos de hosts de IdM mediante los libros de juego de Ansible

En esta sección se describe cómo garantizar la ausencia de hosts de los grupos de hosts en la gestión de identidades (IdM) mediante los libros de juego de Ansible.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver con la lista de servidores IdM a los que dirigirse:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria sobre el host y el grupo de hosts. Especifique el nombre del grupo de hosts utilizando el parámetro name de la variable ipahostgroup. Especifique el nombre del host cuya ausencia del grupo de hosts desea asegurar utilizando el parámetro host de la variable ipahostgroup. Para simplificar este paso, puede copiar y modificar los ejemplos del archivo /usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml:

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is absent
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          host:
          - db.idm.example.com
          action: member
          state: absent

    Este libro de jugadas asegura la ausencia del host db.idm.example.com del grupo de hosts databases. La línea action: member indica que cuando se ejecuta el libro de jugadas, no se intenta eliminar el propio grupo databases.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml

Pasos de verificación

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicitar un ticket Kerberos para el administrador:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Muestra información sobre el grupo de hosts y los hosts que contiene:

    $ ipa hostgroup-show databases
      Host-group: databases
      Member host-groups: mysql-server, oracle-server

El host db.idm.example.com no existe en el grupo de hosts databases.

32.6. Garantizar la ausencia de grupos de hosts anidados de los grupos de hosts de IdM utilizando los playbooks de Ansible

En esta sección se describe cómo garantizar la ausencia de grupos de hosts anidados de los grupos de hosts externos en la Gestión de identidades (IdM) mediante los libros de juego de Ansible.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver con la lista de servidores IdM a los que dirigirse:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria del grupo de hosts. Especifique, entre las variables de - ipahostgroup, el nombre del grupo de hosts externo mediante la variable name. Especifique el nombre del grupo de hosts anidado con la variable hostgroup. Para simplificar este paso, puedes copiar y modificar los ejemplos en el archivo /usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml:

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure hosts and hostgroups are absent in existing databases hostgroup
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          hostgroup:
          - mysql-server
          - oracle-server
          action: member
          state: absent

    Este libro de jugadas se asegura de que los grupos de hosts mysql-server y oracle-server estén ausentes del grupo de hosts databases. La línea action: member indica que cuando se ejecuta el libro de jugadas, no se intenta asegurar que el propio grupo databases se elimine de IdM.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml

Pasos de verificación

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicitar un ticket Kerberos para el administrador:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Muestra información sobre el grupo de hosts del que deben estar ausentes los grupos de hosts anidados:

    $ ipa hostgroup-show databases
      Host-group: databases

La salida confirma que los grupos de hosts anidados mysql-server y oracle-server están ausentes del grupo de hosts externo databases.

32.7. Garantizar la ausencia de grupos de hosts de IdM mediante los playbooks de Ansible

En esta sección se describe cómo garantizar la ausencia de grupos de hosts en Identity Management (IdM) mediante los libros de juego de Ansible.

Nota

Sin Ansible, las entradas de grupos de hosts se eliminan de IdM mediante el comando ipa hostgroup-del. El resultado de eliminar un grupo de hosts de IdM es el estado del grupo de hosts ausente de IdM. Debido a la dependencia de Ansible en la idempotencia, para eliminar un grupo de hosts de IdM utilizando Ansible, debe crear un libro de jugadas en el que se define el estado del grupo de hosts como ausente: state: absent.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver con la lista de servidores IdM a los que dirigirse:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria del grupo de hosts. Para simplificar este paso, puede copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-absent.yml.

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      - Ensure host-group databases is absent
        ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          state: absent

    Este libro de jugadas asegura la ausencia del grupo de hosts databases de IdM. El state: absent significa una solicitud para eliminar el grupo de host de IdM a menos que ya se haya eliminado.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-absent.yml

Pasos de verificación

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicitar un ticket Kerberos para el administrador:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Muestra información sobre el grupo de anfitriones cuya ausencia ha asegurado:

    $ ipa hostgroup-show databases
    ipa: ERROR: databases: host group not found

El grupo de hosts databases no existe en IdM.

32.8. Garantizar la ausencia de administradores miembros de los grupos de host de IdM mediante libros de juego de Ansible

El siguiente procedimiento describe cómo garantizar la ausencia de administradores miembros en los hosts y grupos de hosts de IdM mediante un libro de jugadas de Ansible.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
  • Debes tener el nombre del usuario o grupo de usuarios que estás eliminando como miembros administradores y el nombre del grupo de hosts que están administrando.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree un archivo de playbook de Ansible con la información necesaria para la gestión del host y de los miembros del grupo del host:

    ---
    
    - name: Playbook to handle host group membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager host and host group members are absent for group_name
        ipahostgroup:
          ipaadmin_password: MySecret123
          name: group_name
          membermanager_user: example_member
          membermanager_group: project_admins
          action: member
          state: absent
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-host-groups-are-absent.yml

Pasos de verificación

Puede verificar si el grupo group_name no contiene example_member o project_admins como administradores miembros utilizando el comando ipa group-show:

  1. Entre en ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar información sobre testhostgroup:

    ipaserver]$ ipa hostgroup-show group_name
      Host-group: group_name
      Member hosts: server.idm.example.com
      Member host-groups: testhostgroup2

Recursos adicionales

  • Véase ipa hostgroup-add-member-manager --help.
  • Consulte la página de manual ipa.

Capítulo 33. Gestión de las políticas de tickets de Kerberos

Las políticas de tickets de Kerberos en Identity Management (IdM) establecen restricciones en el acceso, la duración y la renovación de los tickets de Kerberos. Puede configurar las políticas de tiques Kerberos para el Centro de distribución de claves (KDC) que se ejecuta en el servidor IdM.

Este capítulo presenta los siguientes temas y tareas de gestión de tickets de Kerberos:

33.1. El papel del KDC de IdM

Los mecanismos de autenticación de la Gestión de Identidades utilizan la infraestructura Kerberos establecida por el Centro de Distribución de Claves (KDC). El KDC es la autoridad de confianza que almacena la información de las credenciales y garantiza la autenticidad de los datos procedentes de las entidades de la red de IdM.

Cada usuario, servicio y host de IdM actúa como cliente de Kerberos y se identifica con un único Kerberos principal:

  • Para los usuarios: identifier@REALM, como admin@EXAMPLE.COM
  • Para los servicios: service/fully-qualified-hostname@REALM, como http/master.example.com@EXAMPLE.COM
  • Para los anfitriones: host/fully-qualified-hostname@REALM, como host/client.example.com@EXAMPLE.COM

La siguiente imagen es una simplificación de la comunicación entre un cliente Kerberos, el KDC y una aplicación Kerberizada con la que el cliente quiere comunicarse.

Kerberos KDC flow of communication
  1. Un cliente de Kerberos se identifica ante el KDC autenticándose como entidad emisora de Kerberos. Por ejemplo, un usuario de IdM realiza kinit username y proporciona su contraseña.
  2. El KDC busca la entidad de crédito en su base de datos, autentifica al cliente y evalúa las políticas de los tiques Kerberos para determinar si concede la solicitud.
  3. El centro de distribución de claves (KDC) emite al cliente un ticket de concesión de tickets (TGT) con un ciclo de vida e indicadores de autenticación de acuerdo con la política de tickets correspondiente.
  4. Con el TGT, el cliente solicita un service ticket al KDC para comunicarse con un servicio Kerberizado en un host de destino.
  5. El KDC comprueba si el TGT del cliente sigue siendo válido y evalúa la solicitud de ticket de servicio en función de las políticas de tickets.
  6. El KDC emite al cliente un service ticket.
  7. Con el ticket de servicio, el cliente puede iniciar la comunicación cifrada con el servicio en el host de destino.

33.2. Tipos de política de tickets IdM Kerberos

Las políticas de tickets de IdM Kerberos implementan los siguientes tipos de políticas de tickets:

Política de conexión

Para proteger los servicios Kerberizados con diferentes niveles de seguridad, puede definir políticas de conexión para aplicar reglas basadas en el mecanismo de preautenticación que un cliente utilizó para recuperar un ticket de concesión (TGT).

Por ejemplo, puede exigir la autenticación con tarjeta inteligente para conectarse a client1.example.com, y exigir la autenticación de dos factores para acceder a la aplicación testservice en client2.example.com.

Para aplicar las políticas de conexión, asocie authentication indicators con los servicios. Sólo los clientes que tienen los indicadores de autenticación requeridos en sus solicitudes de ticket de servicio pueden acceder a esos servicios. Para obtener más información, consulte Indicadores de autenticación de Kerberos.

Política de ciclo de vida de los billetes

Cada ticket de Kerberos tiene un lifetime y un renewal age potencial: puede renovar un ticket antes de que alcance su vida máxima, pero no después de que supere su edad máxima de renovación.

El tiempo de vida global del ticket por defecto es de un día (86400 segundos) y la edad máxima de renovación global por defecto es de una semana (604800 segundos). Para ajustar estos valores globales, consulte Configuración de la política global del ciclo de vida del ticket.

También puede definir sus propias políticas de ciclo de vida de los tickets:

33.3. Indicadores de autenticación Kerberos

El Centro de Distribución de Claves Kerberos (KDC) adjunta authentication indicators a un ticket de concesión (TGT) en función del mecanismo de preautenticación que el cliente haya utilizado para demostrar su identidad:

otp
autenticación de dos factores (contraseña de un solo uso)
radius
Autenticación RADIUS (normalmente para la autenticación 802.1x)
pkinit
Autenticación por PKINIT, tarjeta inteligente o certificado
hardened
contraseñas reforzadas (SPAKE o FAST)[1]

A continuación, el KDC adjunta los indicadores de autenticación del TGT a cualquier solicitud de ticket de servicio que se derive de él. El centro de distribución de claves aplica políticas como el control de acceso a los servicios, la duración máxima de los tickets y la edad máxima renovable en función de los indicadores de autenticación.

33.3.1. Indicadores de autenticación y servicios IdM

Si se asocia un servicio o un host con un indicador de autenticación, sólo podrán acceder a él los clientes que hayan utilizado el mecanismo de autenticación correspondiente para obtener un vale de transporte. El KDC, y no la aplicación o el servicio, comprueba los indicadores de autenticación en las solicitudes de vales de servicio, y concede o deniega las solicitudes basándose en las políticas de conexión de Kerberos.

Por ejemplo, para requerir la autenticación de dos factores para conectarse al host secure.example.com, asocie el indicador de autenticación otp con la entidad de seguridad Kerberos host/secure.example.com@EXAMPLE.COM. Sólo los usuarios que hayan utilizado una contraseña de un solo uso para obtener su TGT inicial del centro de distribución de claves podrán conectarse.

Si un servicio o un host no tiene asignados indicadores de autenticación, aceptará tickets autenticados por cualquier mecanismo.

Recursos adicionales



[1] Una contraseña reforzada está protegida contra los ataques de diccionario por fuerza bruta utilizando la preautenticación Single-Party Public-Key Authenticated Key Exchange (SPAKE) y/o el blindaje Flexible Authentication via Secure Tunneling (FAST).

33.4. Aplicación de indicadores de autenticación para un servicio IdM

Este procedimiento describe la creación de un servicio IdM y su configuración para requerir determinados indicadores de autenticación Kerberos de las solicitudes de tickets de servicio entrantes.

Al asociar indicadores de autenticación a un servicio IdM, sólo los clientes que hayan utilizado esos mecanismos específicos de preautenticación para obtener su ticket inicial (TGT) podrán acceder al servicio.

33.4.1. Creación de una entrada de servicio IdM y su llavero Kerberos

Al añadir una entrada IdM service a IdM para un servicio que se ejecuta en un host IdM, se crea la entidad de seguridad Kerberos correspondiente y se permite que el servicio solicite un certificado SSL, un llavero Kerberos o ambos.

El siguiente procedimiento describe la creación de una entrada de servicio IdM y la generación de un llavero Kerberos asociado para cifrar la comunicación con ese servicio.

Requisitos previos

  • Su servicio puede almacenar una entidad de crédito Kerberos, un certificado SSL o ambos.

Procedimiento

  1. Añada un servicio IdM con el comando ipa service-add para crear una entidad de seguridad Kerberos asociada a él. Por ejemplo, para crear la entrada de servicio IdM para la aplicación testservice que se ejecuta en el host client.example.com:

    [root@client ~]# ipa service-add testservice/client.example.com
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Managed by: client.example.com
  2. Generar y almacenar un keytab Kerberos para el servicio en el cliente.

    [root@client ~]# ipa-getkeytab -k /etc/testservice.keytab -p testservice/client.example.com
    Keytab successfully retrieved and stored in: /etc/testservice.keytab

Pasos de verificación

  1. Muestra información sobre un servicio IdM con el comando ipa service-show.

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Keytab: True
      Managed by: client.example.com
  2. Muestra el contenido del keytab de Kerberos del servicio con el comando klist.

    [root@server etc]# klist -ekt /etc/testservice.keytab
    Keytab name: FILE:/etc/testservice.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia256-cts-cmac)

33.4.2. Asociar indicadores de autenticación a un servicio IdM

Este procedimiento describe la configuración de un servicio para requerir determinados indicadores de autenticación Kerberos de las solicitudes de tickets de servicio entrantes.

Requisitos previos

Aviso

Haga not asigne indicadores de autenticación a los servicios internos de IdM. Los siguientes servicios de IdM no pueden realizar los pasos de autenticación interactiva requeridos por PKINIT y los métodos de autenticación multifactor:

host/server.example.com@EXAMPLE.COM
HTTP/server.example.com@EXAMPLE.COM
ldap/server.example.com@EXAMPLE.COM
DNS/server.example.com@EXAMPLE.COM
cifs/server.example.com@EXAMPLE.COM

Procedimiento

  • Utilice el comando ipa service-mod para especificar uno o más indicadores de autenticación necesarios para un servicio, identificado con el argumento --auth-ind.

    Método de autenticación--auth-ind valor

    Autenticación de dos factores

    otp

    Autenticación RADIUS

    radius

    Autenticación por PKINIT, tarjeta inteligente o certificado

    pkinit

    Contraseñas reforzadas (SPAKE o FAST)

    hardened

    Por ejemplo, para requerir que un usuario se autentique con tarjeta inteligente o autenticación OTP para recuperar un ticket de servicio para la entidad de seguridad testservice en el host client.example.com:

    [root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind otp --auth-ind pkinit
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Managed by: client.example.com
Nota

Para eliminar todos los indicadores de autenticación de un servicio, proporcione una lista vacía de indicadores:

[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind ''
------------------------------------------------------
Modified service "testservice/client.example.com@EXAMPLE.COM"
------------------------------------------------------
  Principal name: testservice/client.example.com@EXAMPLE.COM
  Principal alias: testservice/client.example.com@EXAMPLE.COM
  Managed by: client.example.com

Pasos de verificación

  • Muestra información sobre un servicio IdM, incluidos los indicadores de autenticación que requiere, con el comando ipa service-show.

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Keytab: True
      Managed by: client.example.com

Recursos adicionales

33.4.3. Recuperación de un ticket de servicio Kerberos para un servicio IdM

El siguiente procedimiento describe la recuperación de un ticket de servicio Kerberos para un servicio IdM. Puede utilizar este procedimiento para probar las políticas de tickets de Kerberos.

Requisitos previos

Procedimiento

  • Utilice el comando kvno con la opción -S para recuperar un ticket de servicio y especifique el nombre del servicio IdM y el nombre de dominio completo del host que lo gestiona.

    [root@server ~]# kvno -S testservice client.example.com
    testservice/client.example.com@EXAMPLE.COM: kvno = 1
Nota

Si necesita acceder a un servicio IdM y su ticket actual (TGT) no posee los indicadores de autenticación necesarios asociados a él, borre su caché de credenciales Kerberos actual con el comando kdestroy y recupere un nuevo TGT:

[root@server ~]# kdestroy

Por ejemplo, si inicialmente recuperó un TGT autenticándose con una contraseña, y necesita acceder a un servicio IdM que tiene asociado el indicador de autenticación pkinit, destruya su caché de credenciales actual y vuelva a autenticarse con una tarjeta inteligente. Consulte los indicadores de autenticación de Kerberos.

Pasos de verificación

  • Utilice el comando klist para verificar que el ticket de servicio está en la caché de credenciales de Kerberos por defecto.

    [root@server etc]# klist_
    Ticket cache: KCM:1000
    Default principal: admin@EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    04/01/2020 12:52:42  04/02/2020 12:52:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    04/01/2020 12:54:07 04/02/2020 12:52:39 testservice/client.example.com@EXAMPLE.COM

33.4.4. Recursos adicionales

33.5. Configuración de la política global del ciclo de vida del ticket

La política global de tickets se aplica a todos los tickets de servicio y a los usuarios que no tienen definida ninguna política de tickets por usuario.

El siguiente procedimiento describe el ajuste de la duración máxima del ticket y la edad máxima de renovación del ticket para la política global de tickets de Kerberos mediante el comando ipa krbtpolicy-mod.

Al utilizar el comando ipa krbtpolicy-mod, especifique al menos uno de los siguientes argumentos:

  • --maxlife para la duración máxima del billete en segundos
  • --maxrenew para la edad máxima renovable en segundos

Procedimiento

  1. Para modificar la política global de tickets:

    [root@server ~]# ipa krbtpolicy-mod --maxlife=$((8*60*60)) --maxrenew=$((24*60*60))
      Max life: 28800
      Max renew: 86400

    In this example, the maximum lifetime is set to eight hours (8 * 60 minutes * 60 seconds) and the maximum renewal age is set to one day (24 * 60 minutes * 60 seconds).

  2. Opcional: Para restablecer la política global de tickets de Kerberos a los valores de instalación por defecto:

    [root@server ~]# ipa krbtpolicy-reset
      Max life: 86400
      Max renew: 604800

Pasos de verificación

  • Muestra la política global de tickets:

    [root@server ~]# ipa krbtpolicy-show
      Max life: 28800
      Max renew: 86640

Recursos adicionales

33.6. Configuración de políticas globales de tickets por indicador de autenticación

Este procedimiento describe el ajuste de la duración máxima global del ticket y la edad máxima renovable para cada indicador de autenticación. Estos ajustes se aplican a los usuarios que no tienen definidas políticas de tickets por usuario.

Utilice el comando ipa krbtpolicy-mod para especificar la duración máxima global o la edad máxima renovable de los tickets de Kerberos en función de los indicadores de autenticación adjuntos.

Procedimiento

  • Por ejemplo, para establecer los valores globales de duración del ticket de dos factores y de edad de renovación a una semana, y los valores globales de duración del ticket de tarjeta inteligente y de edad de renovación a dos semanas:

    [root@server ~]# ipa krbtpolicy-mod --otp-maxlife=604800 --otp-maxrenew=604800 --pkinit-maxlife=172800 --pkinit-maxrenew=172800

Pasos de verificación

  • Muestra la política global de tickets:

    [root@server ~]# ipa krbtpolicy-show
      Max life: 86400
      OTP max life: 604800
      PKINIT max life: 172800
      Max renew: 604800
      OTP max renew: 604800
      PKINIT max renew: 172800

    Observe que los valores OTP y PKINIT son diferentes de los valores globales por defecto Max life y Max renew.

Recursos adicionales

33.7. Configuración de la política de tickets por defecto para un usuario

Puede definir una política de tickets de Kerberos única que sólo se aplique a un único usuario. Estas configuraciones por usuario anulan la política de tickets global, para todos los indicadores de autenticación.

Utilice el comando ipa krbtpolicy-mod username y especifique al menos uno de los siguientes argumentos:

  • --maxlife para la duración máxima del billete en segundos
  • --maxrenew para la edad máxima renovable en segundos

Procedimiento

  1. Por ejemplo, para establecer la duración máxima del ticket del usuario de IdM admin en dos días y la edad máxima de renovación en dos semanas:

    [root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600
      Max life: 172800
      Max renew: 1209600
  2. Opcional: Para restablecer la política de tickets de un usuario:

    [root@server ~]# ipa krbtpolicy-reset admin

Pasos de verificación

  • Muestra la política de tickets de Kerberos efectiva que se aplica a un usuario:

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 172800
      Max renew: 1209600

Recursos adicionales

33.8. Configuración de políticas de tickets de indicadores de autenticación individuales para un usuario

Como administrador, puede definir políticas de tickets de Kerberos para un usuario que difieren según el indicador de autenticación. Por ejemplo, puede configurar una política que permita al usuario de IdM admin renovar un ticket durante dos días si se obtuvo con autenticación OTP, y una semana si se obtuvo con autenticación de tarjeta inteligente.

Estos ajustes por indicador de autenticación anulan la política de tickets por defecto de user’s, la política de tickets por defecto de global y cualquier política de tickets de indicador de autenticación de global.

Utilice el comando ipa krbtpolicy-mod username para establecer valores personalizados de vida útil máxima y edad máxima renovable para los tiques Kerberos de un usuario en función de los indicadores de autenticación adjuntos.

Procedimiento

  1. Por ejemplo, para permitir que el usuario de IdM admin renueve un ticket de Kerberos durante dos días si se obtuvo con la autenticación One-Time Password, configure la opción --otp-maxrenew:

    [root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60))
      OTP max renew: 172800
  2. Opcional: Para restablecer la política de tickets de un usuario:

    [root@server ~]# ipa krbtpolicy-reset username

Pasos de verificación

  • Muestra la política de tickets de Kerberos efectiva que se aplica a un usuario:

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 28800
      Max renew: 86640

Recursos adicionales

33.9. Opciones del indicador de autentificación para el comando krbtpolicy-mod

Especifique los valores de los indicadores de autenticación con los siguientes argumentos.

Tabla 33.1. Opciones del indicador de autentificación para el comando krbtpolicy-mod

Indicador de autentificaciónArgumento de la vida útil máximaArgumento para la edad máxima de renovación

otp

--otp-maxlife

--otp-maxrenew

radius

--radius-maxlife

--radius-maxrenew

pkinit

--pkinit-maxlife

--pkinit-maxrenew

hardened

--hardened-maxlife

--hardened-maxrenew

Capítulo 34. Definición de políticas de contraseñas de IdM

En este capítulo se describen las políticas de contraseñas de Identity Management (IdM) y cómo añadir una nueva política de contraseñas en IdM mediante un libro de jugadas de Ansible.

34.1. ¿Qué es una política de contraseñas?

Una política de contraseñas es un conjunto de reglas que deben cumplir las contraseñas. Por ejemplo, una política de contraseñas puede definir la longitud mínima de la contraseña y la duración máxima de la misma. Todos los usuarios afectados por esta política deben establecer una contraseña suficientemente larga y cambiarla con la frecuencia necesaria para cumplir las condiciones especificadas. De este modo, las políticas de contraseñas ayudan a reducir el riesgo de que alguien descubra y haga un uso indebido de la contraseña de un usuario.

34.2. Políticas de contraseñas en IdM

Las contraseñas son la forma más común de que los usuarios de Gestión de Identidades (IdM) se autentiquen en el dominio IdM Kerberos. Las políticas de contraseñas definen los requisitos que deben cumplir estas contraseñas de los usuarios de IdM.

Nota

La política de contraseñas de IdM se establece en el directorio LDAP subyacente, pero el Centro de Distribución de Claves de Kerberos (KDC) aplica la política de contraseñas.

Atributos de la política de contraseñas enumera los atributos que puede utilizar para definir una política de contraseñas en IdM.

Tabla 34.1. Atributos de la política de contraseñas

AtributoExplicaciónEjemplo

Vida útil máxima

La cantidad máxima de tiempo en días que una contraseña es válida antes de que un usuario deba restablecerla.

Vida útil máxima = 90

Las contraseñas de los usuarios sólo son válidas durante 90 días. Después, IdM pide a los usuarios que las cambien.

Duración mínima

La cantidad mínima de tiempo en horas que debe pasar entre dos operaciones de cambio de contraseña.

Duración mínima = 1

Después de que los usuarios cambien sus contraseñas, deben esperar al menos 1 hora antes de volver a cambiarlas.

Tamaño de la historia

El número de contraseñas anteriores que se almacenan. Un usuario no puede reutilizar una contraseña de su historial de contraseñas, pero puede reutilizar contraseñas antiguas que no están almacenadas.

Tamaño del historial = 0

En este caso, el historial de contraseñas está vacío y los usuarios pueden reutilizar cualquiera de sus contraseñas anteriores.

Clases de personajes

El número de clases de caracteres diferentes que el usuario debe utilizar en la contraseña. Las clases de caracteres son:

* Caracteres en mayúsculas

* Caracteres en minúscula

* Dígitos

* Caracteres especiales, como la coma (,), el punto (.), el asterisco (*)

* Otros caracteres UTF-8

El uso de un carácter tres o más veces seguidas disminuye la clase de carácter en uno. Por ejemplo:

* Secret1 tiene 3 clases de caracteres: mayúsculas, minúsculas y dígitos

* Secret111 tiene 2 clases de caracteres: mayúsculas, minúsculas, dígitos, y una penalización de -1 por usar 1 repetidamente

Clases de caracteres = 0

El número de clases requerido por defecto es 0. Para configurar el número, ejecute el comando ipa pwpolicy-mod con la opción --minclasses.

Véase también la nota de Importante debajo de esta tabla.

Longitud mínima

El número mínimo de caracteres de una contraseña.

Longitud mínima = 8

Los usuarios no pueden utilizar contraseñas de menos de 8 caracteres.

Fallos máximos

El número máximo de intentos de inicio de sesión fallidos antes de que IdM bloquee la cuenta de usuario.

Máximo de fallos = 6

IdM bloquea la cuenta de usuario cuando el usuario introduce una contraseña incorrecta 7 veces seguidas.

Intervalo de restablecimiento de fallos

La cantidad de tiempo en segundos después de la cual IdM restablece el número actual de intentos de inicio de sesión fallidos.

Intervalo de restablecimiento de fallos = 60

Si el usuario espera más de 1 minuto después del número de intentos fallidos de inicio de sesión definidos en Max failures, el usuario puede intentar iniciar sesión de nuevo sin arriesgarse a un bloqueo de la cuenta de usuario.

Duración del bloqueo

La cantidad de tiempo en segundos que la cuenta de usuario se bloquea después del número de intentos fallidos de inicio de sesión definidos en Max failures.

Duración del bloqueo = 600

Los usuarios con cuentas bloqueadas no pueden conectarse durante 10 minutos.

Importante

Utilice el alfabeto inglés y los símbolos comunes para el requisito de clases de caracteres si tiene un conjunto diverso de hardware que puede no tener acceso a caracteres y símbolos internacionales. Para más información sobre las políticas de clases de caracteres en las contraseñas, consulte ¿Qué caracteres son válidos en una contraseña? en Red Hat Knowledgebase.

34.3. Garantizar la presencia de una política de contraseñas en IdM mediante un playbook de Ansible

En esta sección se describe cómo garantizar la presencia de una política de contraseñas en Identity Management (IdM) mediante un playbook de Ansible.

En la política de contraseñas predeterminada de global_policy en IdM, el número de clases de caracteres diferentes en la contraseña se establece en 0. El tamaño del historial también se establece en 0.

Complete este procedimiento para aplicar una política de contraseñas más fuerte para un grupo de IdM utilizando un libro de jugadas de Ansible.

Nota

Sólo puede definir una política de contraseñas para un grupo de IdM. No se puede definir una política de contraseñas para un usuario individual.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
  • Conoce la contraseña del administrador de IdM.
  • El grupo para el que se está asegurando la presencia de una política de contraseñas existe en IdM.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina el FQDN de su servidor IdM en la sección [ipaserver]:

    [ipaserver]
    server.idm.example.com
  2. Cree su archivo Ansible playbook que defina la política de contraseñas cuya presencia desea asegurar. Para simplificar este paso, copie y modifique el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/pwpolicy/pwpolicy_present.yml:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure presence of pwpolicy for group ops
        ipapwpolicy:
          ipaadmin_password: MySecret123
          name: ops
          minlife: 7
          maxlife: 49
          history: 5
          priority: 1
          lockouttime: 300
          minlength: 8
          minclasses: 4
          maxfail: 3
          failinterval: 5

    Para conocer el significado de cada una de las variables, consulte Atributos de la política de contraseñas.

  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/new_pwpolicy_present.yml

Ha utilizado con éxito un libro de jugadas de Ansible para garantizar que una política de contraseñas para el grupo ops esté presente en IdM.

Importante

La prioridad de la política de contraseñas ops se establece en 1, mientras que la política de contraseñas global_policy no tiene establecida ninguna prioridad. Por esta razón, la política ops sustituye automáticamente a global_policy para el grupo ops y se aplica inmediatamente.

global_policy sirve como política de reserva cuando no se establece ninguna política de grupo para un usuario, y nunca puede tener prioridad sobre una política de grupo.

Recursos adicionales

  • Para obtener más detalles sobre el uso de Ansible para definir las políticas de contraseñas en IdM y sobre las variables del libro de jugadas, consulte el archivo README-pwpolicy.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/.
  • Para obtener más detalles sobre el funcionamiento de las prioridades de la política de contraseñas en IdM, consulte la documentación sobre las prioridades de la política de contraseñas en RHEL 7.

Capítulo 35. Gestión de las notificaciones de caducidad de las contraseñas

Puede utilizar la herramienta de notificación de contraseñas caducadas (EPN), proporcionada por el paquete ipa-client-epn, para crear una lista de usuarios de gestión de identidades (IdM) cuyas contraseñas caducan en un tiempo configurado. Para instalar, configurar y utilizar la herramienta EPN, consulte las secciones correspondientes.

35.1. ¿Qué es la herramienta de notificación de contraseña caducada?

La herramienta de notificación de contraseñas caducadas (EPN) es una herramienta independiente que puede utilizar para crear una lista de usuarios de gestión de identidades (IdM) cuyas contraseñas caducan en un tiempo configurado.

Los administradores de IdM pueden utilizar EPN para:

  • Muestra una lista de los usuarios afectados en formato JSON, que se crea cuando se ejecuta en modo dry-run.
  • Calcule cuántos correos electrónicos se enviarán para un día o rango de fechas determinado.
  • Envíe notificaciones de caducidad de la contraseña por correo electrónico a los usuarios.
  • Configure el sitio ipa-epn.timer para que ejecute la herramienta EPN diariamente y envíe un correo electrónico a los usuarios cuyas contraseñas caduquen dentro de los intervalos de fechas futuros definidos.
  • Personalice la notificación por correo electrónico que se enviará a los usuarios.
Nota

Si una cuenta de usuario está desactivada, no se envían notificaciones por correo electrónico si la contraseña va a caducar.

35.2. Instalación de la herramienta de notificación de caducidad de la contraseña

Este procedimiento describe cómo instalar la herramienta de notificación de contraseña caducada (EPN).

Requisitos previos

  • Instale la herramienta EPN en una réplica de Identity Management (IdM) o en un cliente IdM con un servidor SMTP Postfix local configurado como host inteligente.

Procedimiento

  • Instale la herramienta EPN:

    # dnf install ipa-client-epn

35.3. Ejecutar la herramienta EPN para enviar mensajes de correo electrónico a los usuarios cuyas contraseñas van a caducar

Este procedimiento describe cómo ejecutar la herramienta de Notificación de caducidad de contraseña (EPN) para enviar correos electrónicos a los usuarios cuyas contraseñas están caducando.

Nota

La herramienta EPN no tiene estado. Si la herramienta EPN no envía un correo electrónico a ninguno de los usuarios cuyas contraseñas caducan en un día determinado, la herramienta EPN no guarda una lista de esos usuarios.

Requisitos previos

Procedimiento

  1. Actualice el archivo de configuración de epn.conf para establecer las opciones para que la herramienta EPN notifique a los usuarios la próxima caducidad de la contraseña.

    # vi /etc/ipa/epn.conf
  2. Actualice la página notify_ttls según sea necesario. El valor predeterminado es notificar a los usuarios cuyas contraseñas caducan en 28, 14, 7, 3 y 1 día(s).

    notify_ttls = 28, 14, 7, 3, 1
  3. Configure su servidor SMTP y su puerto:

    smtp_server = localhost
    smtp_port = 25
  4. Especifique la dirección de correo electrónico desde la que se envía la notificación de caducidad del correo electrónico. Los correos electrónicos que no se entregan se devuelven a esta dirección.

    mail_from =admin-email@example.com
  5. Guarde el archivo /etc/ipa/epn.conf.
  6. Ejecute la herramienta EPN en modo de ejecución en seco para generar una lista de los usuarios a los que se enviaría la notificación de caducidad de la contraseña por correo electrónico si ejecutara la herramienta sin la opción --dry-run.

    ipa-epn --dry-run
    [
        {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-04-17 15:51:53",
         "mail": "['user5@ipa.test']"
        }
    ]
    [
        {
         "uid": "user6",
         "cn": "user 6",
         "krbpasswordexpiration": "2020-12-17 15:51:53",
         "mail": "['user5@ipa.test']"
         }
    ]
    The IPA-EPN command was successful
    Nota

    Si la lista de usuarios devuelta es muy grande y ejecuta la herramienta sin la opción --dry-run, esto podría causar un problema con su servidor de correo electrónico.

  7. Ejecute la herramienta EPN sin la opción --dry-run para enviar correos electrónicos de caducidad a la lista de todos los usuarios devueltos cuando ejecutó la herramienta EPN en modo de ejecución en seco:

    ipa-epn
    [
      {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-10-01 15:51:53",
         "mail": "['user5@ipa.test']"
      }
    ]
    [
      {
        "uid": "user6",
        "cn": "user 6",
        "krbpasswordexpiration": "2020-12-17 15:51:53",
        "mail": "['user5@ipa.test']"
      }
    ]
    The IPA-EPN command was successful
  8. Puede añadir EPN a cualquier sistema de monitorización e invocarlo con las opciones --from-nbdays y --to-nbdays para determinar cuántas contraseñas de usuarios van a caducar en un plazo de tiempo determinado:

    # ipa-epn --del-día 8 --al-día 12
    Nota

    Si invoca la herramienta EPN con las opciones --from-nbdays y --to-nbdays, se ejecuta automáticamente en modo de ejecución en seco.

Pasos de verificación

  • Ejecute la herramienta EPN y compruebe que se envía una notificación por correo electrónico.

Recursos adicionales

  • Véase la página de manual ipa-epn.
  • Véase la página de manual epn.conf.

35.4. Habilitar el temporizador ipa-epn.timer para que envíe un correo electrónico a todos los usuarios cuyas contraseñas caduquen

Este procedimiento describe cómo utilizar ipa-epn.timer para ejecutar la herramienta de notificación de contraseñas caducadas (EPN) para enviar correos electrónicos a los usuarios cuyas contraseñas están caducando. ipa-epn.timer analiza el archivo epn.conf y envía un correo electrónico a los usuarios cuyas contraseñas caducan dentro de los intervalos de fechas futuras definidos en ese archivo.

Requisitos previos

Procedimiento

  • Inicie el ipa-epn.timer:

    systemctl start ipa-epn.timer

Una vez que inicie el temporizador, por defecto, la herramienta EPN se ejecuta todos los días a la 1 de la madrugada.

Recursos adicionales

  • Consulte la página de manual ipa-epn.

35.5. Modificación de la plantilla de correo electrónico de notificación de contraseña caducada

Este procedimiento describe cómo personalizar la plantilla del mensaje de correo electrónico de notificación de contraseña caducada (EPN).

Requisitos previos

  • El paquete ipa-client-epn está instalado.

Procedimiento

  1. Abra la plantilla de mensajes EPN:

    # vi /etc/ipa/epn/expire_msg.template
  2. Actualice el texto de la plantilla según sea necesario.

    Hi {{ fullname }},
    
    Your password will expire on {{ expiration }}.
    
    Please change it as soon as possible.

    Puede utilizar las siguientes variables en la plantilla.

    • ID de usuario: uid
    • Nombre completo: fullname
    • Nombre de pila: first
    • Nombre: apellido
    • Fecha de caducidad de la contraseña: caducidad
  3. Guarde el archivo de la plantilla de mensajes.

Pasos de verificación

  • Ejecute la herramienta EPN y compruebe que la notificación por correo electrónico contiene el texto actualizado.

Recursos adicionales

  • Consulte la página de manual ipa-epn.

Capítulo 36. Conceder acceso sudo a un usuario IdM en un cliente IdM

36.1. Acceso Sudo en un cliente IdM

Los administradores del sistema pueden conceder acceso a sudo para permitir a los usuarios no root ejecutar comandos administrativos que normalmente están reservados para el usuario root. En consecuencia, cuando los usuarios necesitan ejecutar un comando administrativo normalmente reservado para el usuario root, preceden ese comando con sudo. Después de introducir su contraseña, el comando se ejecuta como si fuera el usuario root.

Si un host de Red Hat Enterprise Linux (RHEL) 8 está inscrito como cliente de Gestión de Identidades (IdM), puede especificar las reglas de sudo que definen qué usuarios de IdM pueden realizar qué comandos en el host de las siguientes maneras:

  • Localmente en el archivo /etc/sudoers
  • De forma centralizada en IdM

En este capítulo se describe la creación de una regla central sudo para un cliente IdM mediante la interfaz web de IdM. Para obtener más detalles sobre la creación de reglas locales de sudo en un host RHEL 8, consulte Administrar el acceso a sudo.

Tenga en cuenta que también puede definir reglas centrales de IdM sudo utilizando la interfaz de línea de comandos de IdM.

36.2. Conceder acceso sudo a un usuario de IdM en un cliente de IdM mediante la interfaz web de IdM

En Gestión de identidades (IdM), puede conceder acceso a sudo para un comando específico a una cuenta de usuario IdM en un host IdM específico. En primer lugar, añada un comando sudo y, a continuación, cree una regla sudo para uno o varios comandos.

Complete este procedimiento para crear la regla sudo idm_user_reboot para conceder a idm_user el permiso para ejecutar el comando /usr/sbin/reboot en la máquina idmclient.

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.
  • Ha creado una cuenta de usuario para idm_user en IdM y ha desbloqueado la cuenta creando una contraseña para el usuario. Para obtener más detalles sobre cómo añadir un nuevo usuario de IdM mediante la interfaz de línea de comandos, consulte Añadir usuarios mediante la línea de comandos.
  • No se ha creado ninguna cuenta local idm_user en idmclient. El usuario idm_user no aparece en el archivo local /etc/passwd.

Procedimiento

  1. Añade el comando /usr/sbin/reboot a la base de datos de comandos de IdM sudo:

    1. Navegue hasta PolicySudoSudo Commands.
    2. Haga clic en Add en la esquina superior derecha para abrir el cuadro de diálogo Add sudo command.
    3. Introduzca el comando que desea que el usuario pueda realizar utilizando sudo: /usr/sbin/reboot.

      Figura 36.1. Añadir el comando sudo de IdM

      adding IdM sudo command
    4. Haga clic en Add.
  2. Utilice la nueva entrada de comando sudo para crear una regla sudo que permita a idm_user reiniciar la máquina idmclient:

    1. Navegue hasta PolicySudoSudo rules.
    2. Haga clic en Add en la esquina superior derecha para abrir el cuadro de diálogo Add sudo rule.
    3. Introduzca el nombre de la regla sudo: idm_user_reboot.
    4. Haga clic en Add and Edit.
    5. Especifica el usuario:

      1. En la sección Who, marque el botón de opción Specified Users and Groups.
      2. En la subsección User category the rule applies to, haga clic en Add para abrir el cuadro de diálogo Add users into sudo rule "idm_user_reboot".
      3. En el cuadro de diálogo Add users into sudo rule "idm_user_reboot", en la columna Available, marque la casilla idm_user y muévala a la columna Prospective.
      4. Haga clic en Add.
    6. Especifica el host:

      1. En la sección Access this host, marque el botón de opción Specified Hosts and Groups.
      2. En la subsección Host category this rule applies to, haga clic en Add para abrir el cuadro de diálogo Add hosts into sudo rule "idm_user_reboot".
      3. En el cuadro de diálogo Add hosts into sudo rule "idm_user_reboot", en la columna Available, marque la casilla idmclient.idm.example.com y muévala a la columna Prospective.
      4. Haga clic en Add.
      1. Especifica los comandos:

        1. En la subsección Command category the rule applies to de la sección Run Commands, marque el botón de opción Specified Commands and Groups.
        2. En la subsección Sudo Allow Commands, haga clic en Add para abrir el cuadro de diálogo Add allow sudo commands into sudo rule "idm_user_reboot".
        3. En el cuadro de diálogo Add allow sudo commands into sudo rule "idm_user_reboot", en la columna Available, marque la casilla /usr/sbin/reboot y muévala a la columna Prospective.
        4. Haga clic en Add para volver a la página idm_sudo_reboot.

          Figura 36.2. Añadir la regla sudo de IdM

          IdM sudo rule WebUI
    7. Haga clic en Save en la esquina superior izquierda.

La nueva regla está activada por defecto.

Pasos de verificación

Comprueba que la regla sudo que has configurado en el servidor IdM funciona en idmclient verificando que idm_user puede ahora reiniciar idmclient utilizando sudo. Ten en cuenta que la propagación de los cambios del servidor al cliente puede tardar unos minutos.

  1. Inicie sesión en idmclient como idm_user.
  2. Reinicie la máquina utilizando sudo. Introduzca la contraseña de idm_user cuando se le solicite:

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

Si sudo está configurado correctamente, la máquina se reinicia.

36.3. Uso de un libro de jugadas de Ansible para garantizar el acceso sudo de un usuario de IdM en un cliente de IdM

En la gestión de identidades (IdM), puede asegurarse de que sudo conceda el acceso a un comando específico a una cuenta de usuario IdM en un host IdM específico.

Completa este procedimiento para asegurarte de que existe una regla sudo llamada idm_user_reboot. La regla concede a idm_user el permiso para ejecutar el comando /usr/sbin/reboot en la máquina idmclient.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaservers:

    [ipaservers]
    server.idm.example.com
  2. Añade uno o más comandos de sudo:

    1. Cree un playbook de Ansible ensure-reboot-sudocmd-is-present.yml que garantice la presencia del comando /usr/sbin/reboot en la base de datos de IdM de los comandos sudo. Para simplificar este paso, puede copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml:

      ---
      - name: Playbook to manage sudo command
        hosts: ipaserver
        become: true
      
        tasks:
        # Ensure sudo command is present
        - ipasudocmd:
            ipaadmin_password: MySecret123
            name: /usr/sbin/reboot
            state: present
    2. Ejecuta el libro de jugadas:

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
  3. Cree una regla sudo que haga referencia a los comandos:

    1. Cree un playbook de Ansible ensure-sudorule-for-idmuser-on-idmclient-is-present.yml que utilice la entrada del comando sudo para asegurar la presencia de una regla sudo. La regla sudo permite a idm_user reiniciar la máquina idmclient. Para simplificar este paso, puede copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml:

      ---
      - name: Tests
        hosts: ipaserver
        become: true
      
        tasks:
        # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient
        - ipasudorule:
            ipaadmin_password: MySecret123
            name: idm_user_reboot
            description: A test sudo rule.
            allow_sudocmd: /usr/sbin/reboot
            host: idmclient.idm.example.com
            user: idm_user
            state: present
    2. Ejecuta el libro de jugadas:

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml

Pasos de verificación

Compruebe que la regla sudo cuya presencia ha asegurado en el servidor IdM funciona en idmclient verificando que idm_user puede reiniciar idmclient utilizando sudo. Tenga en cuenta que los cambios realizados en el servidor pueden tardar unos minutos en surtir efecto en el cliente.

  1. Inicie sesión en idmclient como idm_user.
  2. Reinicie la máquina utilizando sudo. Introduzca la contraseña de idm_user cuando se le solicite:

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

Si sudo está configurado correctamente, la máquina se reinicia.

Materiales adicionales

  • Para obtener más detalles sobre cómo aplicar los comandos, grupos de comandos y reglas de sudo en IdM utilizando un libro de jugadas de Ansible, incluidas las descripciones de las variables del libro de jugadas, consulte los archivos Markdown README-sudocmd.md, README-sudocmdgroup.md y README-sudorule.md disponibles en el directorio /usr/share/doc/ansible-freeipa/.

Capítulo 37. Garantizar la presencia de las reglas de control de acceso basadas en el host en IdM utilizando libros de juego de Ansible

Este capítulo describe las políticas de acceso basadas en el host de Identity Management (IdM) y cómo definirlas usando Ansible.

Ansible es una herramienta de automatización que se utiliza para configurar sistemas, desplegar software y realizar actualizaciones continuas. Incluye soporte para la gestión de identidades (IdM).

37.1. Reglas de control de acceso basadas en el host en IdM

Las reglas de control de acceso basado en host (HBAC) definen qué usuarios o grupos de usuarios pueden acceder a qué hosts o grupos de hosts utilizando qué servicios o servicios de un grupo de servicios. Como administrador del sistema, puede utilizar las reglas HBAC para lograr los siguientes objetivos:

  • Limite el acceso a un sistema específico de su dominio a los miembros de un grupo de usuarios concreto.
  • Permitir sólo un servicio específico para acceder a los sistemas en su dominio.

Por defecto, IdM está configurado con una regla HBAC por defecto llamada allow_all, que significa acceso universal a cada host para cada usuario a través de cada servicio relevante en todo el dominio de IdM.

Puede ajustar el acceso a diferentes hosts sustituyendo la regla predeterminada allow_all por su propio conjunto de reglas HBAC. Para una gestión centralizada y simplificada del control de acceso, puede aplicar las reglas HBAC a grupos de usuarios, grupos de hosts o grupos de servicios en lugar de a usuarios, hosts o servicios individuales.

37.2. Garantizar la presencia de una regla HBAC en IdM mediante un libro de jugadas de Ansible

En esta sección se describe cómo garantizar la presencia de una regla de control de acceso basada en el host (HBAC) en Identity Management (IdM) mediante un libro de jugadas de Ansible.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file, y defina en él ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Cree su archivo Ansible playbook que defina la política HBAC cuya presencia desea asegurar. Para simplificar este paso, puede copiar y modificar el ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/hbacrule/ensure-hbacrule-allhosts-present.yml:

    ---
    - name: Playbook to handle hbacrules
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure idm_user can access client.idm.example.com via the sshd service
      - ipahbacrule:
          ipaadmin_password: MySecret123
          name: login
          user: idm_user
          host: client.idm.example.com
          hbacsvc:
          - sshd
          state: present
  3. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-new-hbacrule-present.yml

Pasos de verificación

  1. Inicie sesión en la interfaz web de IdM como administrador.
  2. Navegue hasta PolicyHost-Based-Access-ControlHBAC Test.
  3. En la pestaña Who, seleccione idm_user.
  4. En la pestaña Accessing, seleccione client.idm.example.com.
  5. En la pestaña Via service, seleccione sshd.
  6. En la pestaña Rules, seleccione login.
  7. En la pestaña Run test, haga clic en el botón Run test. Si ve ACCESO CONCEDIDO, la regla HBAC se ha implementado con éxito.

Recursos adicionales

  • Para obtener más detalles y ejemplos sobre la configuración de los servicios HBAC, grupos de servicios y reglas mediante Ansible, consulte los archivos Markdown README-hbacsvc.md, README-hbacsvcgroup.md y README-hbacrule.md. Estos archivos están disponibles en el directorio /usr/share/doc/ansible-freeipa. Consulte también los playbooks disponibles en los subdirectorios correspondientes del directorio /usr/share/doc/ansible-freeipa/playbooks.

Capítulo 38. Certificados de clave pública en la gestión de identidades

Este capítulo describe los certificados de clave pública X.509, que se utilizan para autenticar usuarios, hosts y servicios en la gestión de identidades (IdM). Además de la autenticación, los certificados X.509 también permiten la firma digital y el cifrado para proporcionar privacidad, integridad y no repudio.

Un certificado contiene la siguiente información:

  • El sujeto que el certificado autentifica.
  • El emisor, es decir, la CA que ha firmado el certificado.
  • La fecha de inicio y fin de la validez del certificado.
  • Los usos válidos del certificado.
  • La clave pública del sujeto.

Un mensaje cifrado por la clave pública sólo puede ser descifrado por una clave privada correspondiente. Mientras que un certificado y la clave pública que incluye pueden hacerse públicos, el usuario, el host o el servicio deben mantener su clave privada en secreto.

38.1. Autoridades de certificación en IdM

Las autoridades de certificación operan en una jerarquía de confianza. En un entorno IdM con una Autoridad de Certificación (CA) interna, todos los hosts, usuarios y servicios IdM confían en los certificados que han sido firmados por la CA. Además de esta CA raíz, IdM admite sub-CAs a las que la CA raíz ha concedido la capacidad de firmar certificados a su vez. Con frecuencia, los certificados que estas sub-CAs pueden firmar son certificados de un tipo específico, por ejemplo, certificados VPN. Por último, IdM admite el uso de CAs externas. La siguiente tabla presenta las particularidades del uso de los distintos tipos de CA en IdM.

Tabla 38.1. Comparación del uso de CAs integradas y externas en IdM

Nombre de la ACDescripciónUtiliceEnlaces útiles

El ipa CA

Una AC integrada basada en el proyecto Dogtag upstream

Las CAs integradas pueden crear, revocar y emitir certificados para usuarios, hosts y servicios.

Utilizar la CA ipa para solicitar un nuevo certificado de usuario y exportarlo al cliente

Sub-CAs de IdM

Una CA integrada que está subordinada a la CA ipa

Las sub-CAs de IdM son CAs a las que la CA de ipa ha concedido la capacidad de firmar certificados. Con frecuencia, estos certificados son de un tipo específico, por ejemplo, certificados VPN.

Restringir una aplicación para que confíe sólo en un subconjunto de certificados

CAs externas

Una CA externa es una CA distinta de la CA de IdM integrada o de sus sub-CAs.

Mediante las herramientas de IdM, se pueden añadir certificados emitidos por estas CA a usuarios, servicios o hosts, así como eliminarlos.

Gestión de certificados emitidos por CAs externas en la documentación de RHEL 7

Desde el punto de vista del certificado, no hay diferencia entre estar firmado por una CA IdM autofirmada y estarlo externamente.

El papel de la AC incluye los siguientes propósitos:

  • Emite certificados digitales.
  • Al firmar un certificado, se certifica que el sujeto nombrado en el certificado posee una clave pública. El sujeto puede ser un usuario, un host o un servicio.
  • Puede revocar certificados y proporciona el estado de revocación a través de las listas de revocación de certificados (CRL) y el protocolo de estado de los certificados en línea (OCSP).

Recursos adicionales

38.2. Comparación de certificados y Kerberos

Los certificados cumplen una función similar a la que realizan los tickets de Kerberos. Kerberos es un protocolo de autenticación de redes informáticas que funciona a base de tickets para permitir que los nodos que se comunican a través de una red no segura demuestren su identidad entre sí de forma segura. La siguiente tabla muestra una comparación entre Kerberos y los certificados X.509:

Tabla 38.2. Comparación de certificados y Kerberos

Characteristic

Kerberos

X.509

Authentication

Privacy

Opcional

Integrity

Opcional

Type of cryptography involved

Simétrico

Asimétrico

Default validity

Corto (1 día)

Largo (2 años)

Por defecto, Kerberos en la gestión de identidades sólo garantiza la identidad de las partes que se comunican.

38.3. Ventajas e inconvenientes del uso de certificados para autenticar a los usuarios en IdM

Las ventajas de utilizar certificados para autenticar a los usuarios en IdM incluyen los siguientes puntos:

  • Un PIN que protege la clave privada de una tarjeta inteligente suele ser menos complejo y más fácil de recordar que una contraseña normal.
  • Dependiendo del dispositivo, una clave privada almacenada en una tarjeta inteligente no puede ser exportada. Esto proporciona una seguridad adicional.
  • Las tarjetas inteligentes pueden hacer que el cierre de sesión sea automático: IdM puede configurarse para que los usuarios cierren la sesión cuando retiren la tarjeta inteligente del lector.
  • El robo de la clave privada requiere el acceso físico real a una tarjeta inteligente, lo que hace que las tarjetas inteligentes sean seguras contra los ataques de piratería.
  • La autenticación con tarjeta inteligente es un ejemplo de autenticación de dos factores: requiere tanto algo que tienes (la tarjeta) como algo que sabes (el PIN).
  • Las tarjetas inteligentes son más flexibles que las contraseñas porque proporcionan las claves que pueden utilizarse para otros fines, como el cifrado del correo electrónico.
  • El uso de tarjetas inteligentes en máquinas compartidas que son clientes de IdM no suele plantear problemas de configuración adicionales para los administradores de sistemas. De hecho, la autenticación con tarjeta inteligente es una opción ideal para las máquinas compartidas.

Las desventajas de usar certificados para autenticar usuarios en IdM incluyen los siguientes puntos:

  • Los usuarios pueden perder u olvidar traer su tarjeta inteligente o su certificado y quedar efectivamente bloqueados.
  • Si se escribe mal el PIN varias veces, la tarjeta puede quedar bloqueada.
  • Por lo general, hay un paso intermedio entre la solicitud y la autorización por parte de algún tipo de responsable de seguridad o aprobador. En IdM, el responsable de seguridad o el administrador debe ejecutar el comando ipa cert-request.
  • Las tarjetas inteligentes y los lectores tienden a ser específicos del proveedor y del controlador: aunque se pueden utilizar muchos lectores para diferentes tarjetas, una tarjeta inteligente de un proveedor específico podría no funcionar en el lector de otro proveedor o en el tipo de lector para el que no fue diseñada.
  • Los certificados y las tarjetas inteligentes tienen una empinada curva de aprendizaje para los administradores.

Capítulo 39. Gestión de certificados para usuarios, hosts y servicios mediante la CA de IdM integrada

Este capítulo describe cómo gestionar los certificados en la Gestión de Identidades (IdM) utilizando la CA integrada, la CA ipa y sus sub-CAs.

Este capítulo contiene las siguientes secciones:

También puede solicitar nuevos certificados para un servicio a la CA de IdM mediante la utilidad certmonger. Para obtener más información, consulte Solicitud de nuevos certificados para un servicio a la CA IdM mediante certmonger.

Requisitos previos

39.1. Solicitud de nuevos certificados para un usuario, host o servicio mediante la interfaz web de IdM

Esta sección describe cómo utilizar la interfaz web de gestión de identidades (IdM) para solicitar un nuevo certificado para cualquier entidad IdM a las autoridades de certificación (CA) de IdM integradas: la CA de ipa o cualquiera de sus sub-CA.

Las entidades de IdM incluyen:

  • Usuarios
  • Anfitriones
  • Servicios
Importante

Los servicios suelen ejecutarse en nodos de servicio dedicados en los que se almacenan las claves privadas. Copiar la clave privada de un servicio en el servidor de IdM se considera inseguro. Por lo tanto, al solicitar un certificado para un servicio, cree la solicitud de firma de certificado (CSR) en el nodo de servicio.

Requisitos previos

  • Su implementación de IdM contiene una CA integrada.
  • Ha iniciado la sesión en la interfaz web de IdM como administrador de IdM.

Procedimiento

  1. En la pestaña Identity, seleccione la subpestaña Users, Hosts, o Services.
  2. Haga clic en el nombre del usuario, host o servicio para abrir su página de configuración.

    Figura 39.1. Lista de anfitriones

    hosts list
  3. Haga clic en AccionesNuevo certificado.
  4. Opcional: Seleccione la CA emisora y el ID del perfil.
  5. Siga las instrucciones para utilizar la utilidad de línea de comandos (CLI) certutil en la pantalla.
  6. Haga clic en el tema.

39.2. Solicitud de nuevos certificados para un usuario, host o servicio a la CA IdM mediante certutil

Puede utilizar la utilidad certutil para solicitar un certificado para un usuario, host o servicio de gestión de identidades (IdM) en situaciones estándar de IdM. Para garantizar que un alias de Kerberos de host o servicio pueda utilizar un certificado, utilice la utilidad openssl para solicitar un certificado.

Esta sección describe cómo solicitar un certificado para un usuario, host o servicio de IdM a ipa, la autoridad de certificación (CA) de IdM, utilizando certutil.

Importante

Los servicios suelen ejecutarse en nodos de servicio dedicados en los que se almacenan las claves privadas. Copiar la clave privada de un servicio en el servidor de IdM se considera inseguro. Por lo tanto, al solicitar un certificado para un servicio, cree la solicitud de firma de certificado (CSR) en el nodo de servicio.

Requisitos previos

  • Su implementación de IdM contiene una CA integrada.
  • Has iniciado sesión en la interfaz de línea de comandos (CLI) de IdM como administrador de IdM.

Procedimiento

  1. Cree un directorio temporal para la base de datos de certificados:

    # mkdir ~/certdb/
  2. Cree una nueva base de datos temporal de certificados, por ejemplo:

    # certutil -N -d ~/certdb/
  3. Cree la CSR y redirija la salida a un archivo. Por ejemplo, para crear una CSR para un certificado de 4096 bits y establecer el asunto como CN=server.example.com,O=EXAMPLE.COM:

    # certutil -R -d ~/certdb/ -a -g 4096 -s "CN=server.example.com,O=EXAMPLE.COM" -8 server.example.com > certificate_request.csr
  4. Envíe el archivo de solicitud de certificado a la CA que se ejecuta en el servidor IdM. Especifique la entidad de seguridad de Kerberos que se asociará con el certificado recién emitido:

    # ipa cert-request certificate_request.csr --principal=host/server.example.com

    El comando ipa cert-request en IdM utiliza los siguientes valores por defecto:

    • El perfil del certificado caIPAserviceCert

      Para seleccionar un perfil personalizado, utilice la opción --profile-id.

    • La CA raíz de IdM integrada, ipa

      Para seleccionar una sub-CA, utilice la opción --ca.

Recursos adicionales

39.3. Solicitud de nuevos certificados para un usuario, host o servicio a la CA IdM mediante openssl

Puede utilizar la utilidad openssl para solicitar un certificado para un host o servicio de gestión de identidades (IdM) si desea asegurarse de que el alias de Kerberos del host o servicio puede utilizar el certificado. En situaciones estándar, considere la posibilidad de solicitar un nuevo certificado mediante la utilidad certutil.

Esta sección describe cómo solicitar un certificado para un host o servicio de IdM a ipa, la autoridad de certificación de IdM, utilizando openssl.

Importante

Los servicios suelen ejecutarse en nodos de servicio dedicados en los que se almacenan las claves privadas. Copiar la clave privada de un servicio en el servidor de IdM se considera inseguro. Por lo tanto, al solicitar un certificado para un servicio, cree la solicitud de firma de certificado (CSR) en el nodo de servicio.

Requisitos previos

  • Su implementación de IdM contiene una CA integrada.
  • Has iniciado sesión en la interfaz de línea de comandos (CLI) de IdM como administrador de IdM.

Procedimiento

  1. Cree uno o varios alias para su entidad de crédito Kerberos test/server.example.com. Por ejemplo, test1/server.example.com y test2/server.example.com.
  2. En el CSR, añada un subjectAltName para dnsName (server.example.com) y otherName (test2/server.example.com). Para ello, configure el archivo openssl.conf para incluir la siguiente línea que especifica el UPN otherName y subjectAltName:

    otherName=1.3.6.1.4.1.311.20.2.3;UTF8:test2/server.example.com@EXAMPLE.COM
    DNS.1 = server.example.com
  3. Cree una solicitud de certificado utilizando openssl:

    openssl req -new -newkey rsa:2048 -keyout test2service.key -sha256 -nodes -out certificate_request.csr -config openssl.conf
  4. Envíe el archivo de solicitud de certificado a la CA que se ejecuta en el servidor IdM. Especifique la entidad de seguridad de Kerberos que se asociará con el certificado recién emitido:

    # ipa cert-request certificate_request.csr --principal=host/server.example.com

    El comando ipa cert-request en IdM utiliza los siguientes valores por defecto:

    • El perfil del certificado caIPAserviceCert

      Para seleccionar un perfil personalizado, utilice la opción --profile-id.

    • La CA raíz de IdM integrada, ipa

      Para seleccionar una sub-CA, utilice la opción --ca.

Recursos adicionales

39.4. Recursos adicionales

Capítulo 40. Conversión de los formatos de los certificados para que funcionen con IdM

Esta historia de usuario describe cómo asegurarse de que usted, como administrador del sistema IdM, está utilizando el formato correcto de un certificado con comandos IdM específicos. Esto es útil, por ejemplo, en las siguientes situaciones:

40.1. Formatos y codificaciones de los certificados en IdM

La autenticación de certificados, incluida la autenticación con tarjeta inteligente en IdM, se realiza comparando el certificado que presenta el usuario con el certificado, o los datos del certificado, que están almacenados en el perfil IdM del usuario.

Configuración del sistema

Lo que se almacena en el perfil IdM es sólo el certificado, no la clave privada correspondiente. Durante la autenticación, el usuario también debe demostrar que está en posesión de la clave privada correspondiente. El usuario lo hace presentando un archivo PKCS #12 que contenga tanto el certificado como la clave privada o presentando dos archivos: uno que contenga el certificado y otro que contenga la clave privada.

Por lo tanto, procesos como la carga de un certificado en un perfil de usuario sólo aceptan archivos de certificado que no contengan la clave privada.

Del mismo modo, cuando un administrador de sistemas le proporcione un certificado de CA externa, sólo le facilitará los datos públicos: el certificado sin la clave privada. La utilidad ipa-advise para configurar el servidor IdM o el cliente IdM para la autenticación con tarjeta inteligente espera que el archivo de entrada contenga el certificado de la CA externa pero no la clave privada.

Codificaciones de los certificados

Hay dos codificaciones de certificados comunes: El correo electrónico con privacidad (PEM) y las reglas de codificación distinguidas (DER). El formato base64 es casi idéntico al formato PEM pero no contiene la cabecera y el pie de página -----BEGIN CERTIFICATE-----/-----END CERTIFICATE-----.

Un certificado codificado con DER es un archivo binario de certificado digital X509. Como archivo binario, el certificado no es legible para las personas. Los archivos DER utilizan a veces la extensión de nombre de archivo .der, pero los archivos con las extensiones de nombre de archivo .crt y .cer también contienen a veces certificados DER. Los archivos DER que contienen claves pueden llamarse .key.

Un certificado que ha sido codificado utilizando PEM Base64 es un archivo legible para el ser humano. El archivo contiene datos blindados ASCII (Base64) precedidos de una línea "-----BEGIN ...". Los archivos PEM utilizan a veces la extensión de nombre de archivo .pem, pero los archivos con las extensiones de nombre de archivo .crt y .cer también contienen a veces certificados PEM. Los archivos PEM que contienen claves pueden denominarse .key.

Los diferentes comandos de ipa tienen diferentes limitaciones en cuanto a los tipos de certificados que aceptan. Por ejemplo, el comando ipa user-add-cert sólo acepta certificados codificados en el formato base64, pero ipa-server-certinstall acepta los certificados PEM, DER, PKCS #7, PKCS #8 y PKCS #12.

Tabla 40.1. Codificaciones de los certificados

Formato de codificaciónLectura humanaExtensiones comunes de nombres de archivosEjemplos de comandos IdM que aceptan el formato de codificación

PEM/base64

.pem, .crt, .cer

ipa user-add-cert, ipa-server-certinstall, ..

DER

No

.der, .crt, .cer

ipa-server-certinstall, ..

Sección 40.4, “Comandos y formatos relacionados con los certificados en IdM” enumera otros comandos de ipa con los formatos de certificado que aceptan los comandos.

Autenticación de usuarios

Al utilizar la interfaz web para acceder a IdM, el usuario demuestra que está en posesión de la clave privada correspondiente al certificado al tener ambos almacenados en la base de datos del navegador.

Al utilizar la CLI para acceder a IdM, el usuario demuestra que está en posesión de la clave privada correspondiente al certificado mediante uno de los siguientes métodos:

  • El usuario añade, como valor del parámetro X509_user_identity del comando kinit -X, la ruta de acceso al módulo de tarjeta inteligente que está conectado a la tarjeta inteligente que contiene tanto el certificado como la clave:

    $ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' idm_user
  • El usuario añade dos archivos como valores del parámetro X509_user_identity del comando kinit -X, uno que contiene el certificado y el otro la clave privada:

    $ kinit -X X509_user_identity='FILE:`/path/to/cert.pem,/path/to/cert.key`' idm_user

Comandos de certificado útiles

Para ver los datos del certificado, como el asunto y el emisor:

$ openssl x509 -noout -text -in ca.pem

Para comparar en qué líneas se diferencian dos certificados:

$ diff cert1.crt cert2.crt

Para comparar en qué líneas difieren dos certificados con la salida mostrada en dos columnas:

$ diff cert1.crt cert2.crt -y

40.2. Conversión de un certificado externo para cargarlo en una cuenta de usuario de IdM

Esta sección describe cómo asegurarse de que un certificado externo está correctamente codificado y formateado antes de añadirlo a una entrada de usuario.

Requisitos previos

  • Si su certificado fue emitido por una autoridad de certificados de Active Directory y utiliza la codificación PEM, asegúrese de que el archivo PEM se haya convertido al formato UNIX. Para convertir un archivo, utilice la utilidad dos2unix proporcionada por el paquete epónimo.

40.2.1. Convertir un certificado externo en la CLI de IdM y cargarlo en una cuenta de usuario de IdM

IdM CLI sólo acepta un certificado de PEM del que se han eliminado la primera y la última línea (-----BEGIN CERTIFICATE----- y -----END CERTIFICATE-----).

Procedimiento

  1. Convierte el certificado al formato PEM:

    • Si su certificado está en el formato DER:

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • Si su archivo está en el formato PKCS #12, cuyas extensiones de nombre de archivo comunes son .pfx y .p12, y contiene un certificado, una clave privada y posiblemente otros datos, extraiga el certificado utilizando la utilidad openssl pkcs12. Cuando se le solicite, introduzca la contraseña que protege la clave privada almacenada en el archivo:

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. Obtenga las credenciales del administrador:

    $ kinit admin
  3. Añada el certificado a la cuenta de usuario utilizando el IdM CLI siguiendo uno de los siguientes métodos:

    • Elimine la primera y la última línea (-----BEGIN CERTIFICATE----- y -----END CERTIFICATE-----) del archivo PEM utilizando la utilidad sed antes de añadir la cadena al comando ipa user-add-cert:

      $ ipa user-add-cert some_user --certificate="$(sed -e '/BEGIN CERTIFICATE/d;/END CERTIFICATE/d' cert.pem)"
    • Copie y pegue el contenido del archivo del certificado sin las líneas primera y última (-----BEGIN CERTIFICATE----- y -----END CERTIFICATE-----) en el comando ipa user-add-cert:

      $ ipa user-add-cert some_user --certificate=MIIDlzCCAn gAwIBAgIBATANBgkqhki...
      Nota

      No puede pasar un archivo PEM que contenga el certificado como entrada al comando ipa user-add-cert directamente, sin eliminar primero la primera y la última línea (-----BEGIN CERTIFICATE----- y -----END CERTIFICATE-----):

      $ ipa user-add-cert some_user --cert=some_user_cert.pem

      Este comando da como resultado el mensaje de error "ipa: ERROR: Base64 decoding failed: Padding\Nincorrecto" mensaje de error.

  4. Opcionalmente, para comprobar si el certificado fue aceptado por el sistema:

    [idm_user@r8server]$ ipa user-show some_user

40.2.2. Convertir un certificado externo en la interfaz web de IdM para cargarlo en una cuenta de usuario de IdM:

Procedimiento

  1. Utilizando el CLI, convierta el certificado al formato PEM:

    • Si su certificado está en el formato DER:

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • Si su archivo está en el formato PKCS #12, cuyas extensiones de nombre de archivo comunes son .pfx y .p12, y contiene un certificado, una clave privada y posiblemente otros datos, extraiga el certificado utilizando la utilidad openssl pkcs12. Cuando se le solicite, introduzca la contraseña que protege la clave privada almacenada en el archivo:

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. Abra el certificado en un editor y copie su contenido. Puedes incluir las líneas de encabezado y pie de página "-----BEGIN CERTIFICATE-----" y "-----END CERTIFICATE-----", pero no es necesario, ya que la interfaz web de IdM acepta los formatos PEM y base64.
  3. En la interfaz web de IdM, inicie sesión como responsable de seguridad.
  4. Vaya a IdentityUserssome_user.
  5. Haga clic en Add junto a Certificates.
  6. Pegue el contenido del certificado en formato PEM en la ventana que se abre.
  7. Haga clic en Add.

Si el certificado ha sido aceptado por el sistema, podrá verlo en la lista de Certificates en el perfil del usuario.

40.3. Preparación para cargar un certificado en el navegador

Antes de importar un certificado de usuario en el navegador, asegúrese de que el certificado y la clave privada correspondiente están en un formato PKCS #12. Hay dos situaciones comunes que requieren un trabajo preparatorio adicional:

A continuación, para importar al navegador tanto el certificado de la CA en el formato PEM como el certificado del usuario en el formato PKCS #12, siga los procedimientos de Configuración de un navegador para habilitar la autenticación de certificados y Autenticación en la interfaz web de gestión de identidades con un certificado como usuario de gestión de identidades.

40.3.1. Exportación de un certificado y una clave privada de una base de datos NSS a un archivo PKCS #12

Procedimiento

  1. Utilice el comando pk12util para exportar el certificado de la base de datos NSS al formato PKCS12. Por ejemplo, para exportar el certificado con el apodo some_user desde la base de datos del NSS almacenada en el directorio ~/certdb al archivo ~/some_user.p12:

    $ pk12util -d ~/certdb -o ~/some_user.p12 -n some_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  2. Establezca los permisos adecuados para el archivo .p12:

    # chmod 600 ~/some_user.p12

    Dado que el archivo PKCS #12 también contiene la clave privada, debe estar protegido para evitar que otros usuarios utilicen el archivo. De lo contrario, podrían suplantar al usuario.

40.3.2. Combinación de archivos PEM de certificados y claves privadas en un archivo PKCS #12

Esta sección describe cómo combinar un certificado y la clave correspondiente almacenados en archivos PEM separados en un archivo PKCS #12.

Procedimiento

  • Para combinar un certificado almacenado en certfile.cer y una clave almacenada en certfile.key en un archivo certfile.p12 que contiene tanto el certificado como la clave:

    $ openssl pkcs12 -export -in certfile.cer -inkey certfile.key -out certfile.p12

40.4. Comandos y formatos relacionados con los certificados en IdM

La tabla Comandos y formatos de certificados de Id M muestra los comandos relacionados con los certificados en IdM con los formatos aceptables.

Tabla 40.2. Comandos y formatos del certificado IdM

ComandoFormatos aceptablesNotas

ipa user-add-cert some_user --certificate

certificado PEM base64

 

ipa-server-certinstall

Certificado PEM y DER; cadena de certificados PKCS#7; PKCS#8 y clave privada sin procesar; certificado y clave privada PKCS#12

 

ipa-cacert-manage install

DER; PEM; PKCS#7

 

ipa-cacert-manage renew --external-cert-file

Certificado PEM y DER; cadena de certificados PKCS#7

 

ipa-ca-install --external-cert-file

Certificado PEM y DER; cadena de certificados PKCS#7

 

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

N/A

Crea el archivo file.pem codificado en PEM con el certificado que tiene el número de serie <cert_serial>.

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

N/A

Crea el archivo file.pem codificado en PEM con el certificado que tiene el número de serie <cert_serial>. Si se utiliza la opción --chain, el archivo PEM contiene el certificado incluyendo la cadena del mismo.

ipa cert-request --certificate-out=FILE /path/to/req.csr

N/A

Crea el archivo req.csr en formato PEM con el nuevo certificado.

ipa cert-request --certificate-out=FILE /path/to/req.csr

N/A

Crea el archivo req.csr en formato PEM con el nuevo certificado. Si se utiliza la opción --chain, el archivo PEM contiene el certificado incluyendo la cadena del mismo.

Capítulo 41. Creación y gestión de perfiles de certificado en la Gestión de Identidades

Los perfiles de certificado son utilizados por la Autoridad de Certificación (CA) cuando firma certificados para determinar si una solicitud de firma de certificado (CSR) es aceptable y, en caso afirmativo, qué características y extensiones están presentes en el certificado. Un perfil de certificado está asociado a la emisión de un tipo concreto de certificado. Al combinar los perfiles de certificado y las listas de control de acceso (ACL) de la CA, puede definir y controlar el acceso a los perfiles de certificado personalizados.

Al describir cómo crear perfiles de certificado, los procedimientos utilizan los certificados S/MIME como ejemplo. Algunos programas de correo electrónico admiten el correo electrónico firmado y cifrado digitalmente mediante el protocolo Secure Multipurpose Internet Mail Extension (S/MIME). El uso de S/MIME para firmar o cifrar mensajes de correo electrónico requiere que el remitente del mensaje tenga un certificado S/MIME.

41.1. ¿Qué es un modelo de certificado?

Puede utilizar los perfiles de certificado para determinar el contenido de los certificados, así como las restricciones para la emisión de los mismos, como las siguientes:

  • El algoritmo de firma que se utilizará para cifrar la solicitud de firma de certificado.
  • La validez por defecto del certificado.
  • Los motivos de revocación que pueden utilizarse para revocar un certificado.
  • Si el nombre común del mandante se copia en el campo de nombre alternativo del sujeto.
  • Las características y extensiones que deben estar presentes en el certificado.

Un único perfil de certificado se asocia a la emisión de un tipo concreto de certificado. Puede definir diferentes perfiles de certificado para usuarios, servicios y hosts en IdM. IdM incluye por defecto los siguientes perfiles de certificado:

  • caIPAserviceCert
  • IECUserRoles
  • KDCs_PKINIT_Certs (utilizado internamente)

Además, puede crear e importar perfiles personalizados, que le permiten emitir certificados para fines específicos. Por ejemplo, puede restringir el uso de un perfil concreto a un solo usuario o grupo, impidiendo que otros usuarios y grupos utilicen ese perfil para emitir un certificado para la autenticación. Para crear perfiles de certificado personalizados, utilice el comando ipa certprofile.

Recursos adicionales

  • Para obtener información sobre el comando ipa certprofile, ejecute el comando ipa help certprofile.

41.2. Creación de un modelo de certificado

Este procedimiento describe cómo crear un perfil de certificado a través de la línea de comandos mediante la creación de un archivo de configuración del perfil para solicitar certificados S/MIME.

Procedimiento

  1. Cree un perfil personalizado copiando un perfil predeterminado existente:

    $ ipa certprofile-show --out smime.cfg caIPAserviceCert
    ------------------------------------------------
    Profile configuration stored in file 'smime.cfg'
    ------------------------------------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
  2. Abra el archivo de configuración del perfil recién creado en un editor de texto.

    $ vi  smime.cfg
  3. Cambie el Profile ID por un nombre que refleje el uso del perfil, por ejemplo smime.

    Nota

    Cuando se importa un perfil recién creado, el campo profileId, si está presente, debe coincidir con el ID especificado en la línea de comandos.

  4. Actualice la configuración de Uso de Clave Extendida. La configuración por defecto de la extensión Extended Key Usage es para la autenticación del servidor y del cliente TLS. Por ejemplo, para S/MIME, el Uso de Clave Extendida debe configurarse para la protección del correo electrónico:

    policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.4
  5. Importe el nuevo perfil:

    $ ipa certprofile-import smime --file smime.cfg \
      --desc "S/MIME certificates" --store TRUE
    
    ------------------------
    Imported profile "smime"
    ------------------------
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE

Pasos de verificación

  • Compruebe que se ha importado el nuevo modelo de certificado:

    $ ipa certprofile-find
    
    ------------------
    4 profiles matched
    ------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
    
      Profile ID: IECUserRoles
      Profile description: User profile that includes IECUserRoles extension from request
      Store issued certificates: TRUE
    
      Profile ID: KDCs_PKINIT_Certs
      Profile description: Profile for PKINIT support by KDCs
      Store issued certificates: TRUE
    
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE
    ----------------------------
    Number of entries returned 4
    ----------------------------

Recursos adicionales

  • Para más detalles sobre el complemento certprofile, ejecute el comando ipa help certprofile.
  • Para más información sobre la extensión del uso de la clave extendida, véase RFC 5280, sección 4.2.1.12.

41.3. ¿Qué es una lista de control de acceso CA?

Las reglas de la lista de control de acceso de la autoridad de certificación (CA ACL) definen qué perfiles pueden utilizarse para emitir certificados a qué mandantes. Para ello se pueden utilizar, por ejemplo, las ACL de la CA:

  • Determinar qué usuario, host o servicio puede recibir un certificado con un perfil determinado
  • Determinar qué autoridad de certificación IdM o sub-CA está autorizada a emitir el certificado

Por ejemplo, mediante las CA ACL, puede restringir el uso de un perfil destinado a los empleados que trabajan desde una oficina situada en Londres sólo a los usuarios que sean miembros del grupo de usuarios de IdM relacionado con la oficina de Londres.

La utilidad ipa caacl para la gestión de reglas CA ACL permite a los usuarios con privilegios añadir, visualizar, modificar o eliminar una CA ACL especificada.

Recursos adicionales

  • Para obtener información sobre el comando ipa caacl, ejecute el comando ipa help caacl.

41.4. Definición de una ACL de CA para controlar el acceso a los perfiles de certificado

Este procedimiento describe cómo utilizar la utilidad caacl para definir una regla de lista de control de acceso (ACL) de CA para permitir a los usuarios de un grupo el acceso a un perfil de certificado personalizado. En este caso, el procedimiento describe cómo crear un grupo de usuarios S/MIME y una ACL de CA para permitir a los usuarios de ese grupo el acceso al perfil de certificado smime.

Requisitos previos

  • Asegúrate de haber obtenido las credenciales de administrador de IdM.

Procedimiento

  1. Cree un nuevo grupo para los usuarios del modelo de certificado:

    $ ipa group-add smime_users_group
    ---------------------------------
    Added group "smime users group"
    ---------------------------------
      Group name: smime_users_group
      GID: 75400001
  2. Cree un nuevo usuario para añadirlo al grupo smime_user_group:

    $ ipa user-add smime_user
    First name: smime
    Last name: user
    ----------------------
    Added user "smime_user"
    ----------------------
      User login: smime_user
      First name: smime
      Last name: user
      Full name: smime user
      Display name: smime user
      Initials: TU
      Home directory: /home/smime_user
      GECOS: smime user
      Login shell: /bin/sh
      Principal name: smime_user@IDM.EXAMPLE.COM
      Principal alias: smime_user@IDM.EXAMPLE.COM
      Email address: smime_user@idm.example.com
      UID: 1505000004
      GID: 1505000004
      Password: False
      Member of groups: ipausers
      Kerberos keys available: False
  3. Añada el smime_user al grupo smime_users_group:

    $ ipa group-add-member smime_users_group --users=smime_user
      Group name: smime_users_group
      GID: 1505000003
      Member users: smime_user
    -------------------------
    Number of members added 1
    -------------------------
  4. Cree la ACL de la CA para permitir que los usuarios del grupo accedan al perfil del certificado:

    $ ipa caacl-add smime_acl
    ------------------------
    Added CA ACL "smime_acl"
    ------------------------
      ACL name: smime_acl
      Enabled: TRUE
  5. Añada el grupo de usuarios a la ACL de la CA:

    $ ipa caacl-add-user smime_acl --group smime_users_group
      ACL name: smime_acl
      Enabled: TRUE
      User Groups: smime_users_group
    -------------------------
    Number of members added 1
    -------------------------
  6. Añada el modelo de certificado a la ACL de la CA:

    $ ipa caacl-add-profile smime_acl --certprofile smime
      ACL name: smime_acl
      Enabled: TRUE
      Profiles: smime
      User Groups: smime_users_group
    -------------------------
    Number of members added 1
    -------------------------

Pasos de verificación

  • Vea los detalles de la CA ACL que ha creado:

    $ ipa caacl-show smime_acl
      ACL name: smime_acl
      Enabled: TRUE
      Profiles: smime
      User Groups: smime_users_group
    ...

Recursos adicionales

  • Véase la página de manual ipa.
  • Para más detalles sobre el comando ipa caacl, consulte el comando ipa help caacl.

41.5. Uso de perfiles de certificado y ACLs de CA para emitir certificados

Puede solicitar certificados utilizando un perfil de certificado cuando lo permitan las listas de control de acceso (ACL) de la autoridad de certificación. Este procedimiento describe cómo solicitar un certificado S/MIME para un usuario que utiliza un perfil de certificado personalizado al que se le ha concedido acceso a través de una ACL de la CA.

Requisitos previos

  • Su modelo de certificado ha sido creado.
  • Se ha creado una CA ACL que permite al usuario utilizar el perfil de certificado requerido para solicitar un certificado.
Nota

Puede omitir la comprobación de CA ACL si el usuario que realiza el comando cert-request:

  • Es el usuario de admin.
  • Tiene el permiso de Request Certificate ignoring CA ACLs.

Procedimiento

  1. Generar una solicitud de certificado para el usuario. Por ejemplo, utilizando OpenSSL:

    $ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=smime_user'
  2. Solicita un nuevo certificado para el usuario a la CA IdM:

    $ ipa cert-request cert.csr --principal=smime_user --profile-id=smime

    Opcionalmente, pase la opción --ca sub-CA_name al comando para solicitar el certificado de una sub-CA en lugar de la CA raíz.

Pasos de verificación

  • Compruebe que el certificado recién emitido se asigna al usuario:

    $ ipa user-show user
      User login: user
      ...
      Certificate: MIICfzCCAWcCAQA...
      ...

Recursos adicionales

  • Véase la página de manual ipa(a).
  • Para más detalles sobre el comando ipa user-show, consulte el comando ipa help user-show.
  • Para más detalles sobre el comando ipa cert-request, consulte el comando ipa help cert-request.
  • Véase la página de manual openssl(lssl).

41.6. Modificación de un modelo de certificado

Este procedimiento describe cómo modificar los perfiles de certificado directamente a través de la línea de comandos utilizando el comando ipa certprofile-mod.

Procedimiento

  1. Determine el ID del modelo de certificado que está modificando. Para mostrar todos los modelos de certificado almacenados actualmente en IdM:

    # ipa certprofile-find
    
    ------------------
    4 profiles matched
    ------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
    
      Profile ID: IECUserRoles
      ...
    
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE
    --------------------------
    Number of entries returned
    --------------------------
  2. Modifique la descripción del modelo de certificado. Por ejemplo, si ha creado un modelo de certificado personalizado para certificados S/MIME utilizando un modelo existente, cambie la descripción de acuerdo con el nuevo uso:

    # ipa certprofile-mod smime --desc "New certificate profile description"
    ------------------------------------
    Modified Certificate Profile "smime"
    ------------------------------------
        Profile ID: smime
        Profile description: New certificate profile description
        Store issued certificates: TRUE
  3. Abra su archivo de perfil de certificado de cliente en un editor de texto y modifíquelo para adaptarlo a sus necesidades:

    # vi smime.cfg

    Para más detalles sobre las opciones que pueden configurarse en el archivo de configuración del modelo de certificado, consulte Parámetros de configuración del modelo de certificado.

  4. Actualice el archivo de configuración del perfil de certificado existente:

    # ipa certprofile-mod _profile_ID_ --file=smime.cfg

Pasos de verificación

  • Verifique que el perfil del certificado ha sido actualizado:

    $ ipa certprofile-show smime
      Profile ID: smime
      Profile description: New certificate profile description
      Store issued certificates: TRUE

Recursos adicionales

  • Véase la página de manual ipa(a).
  • Para más detalles sobre el comando ipa certprofile-mod, consulte el comando ipa help certprofile-mod.

41.7. Parámetros de configuración del modelo de certificado

Los parámetros de configuración del perfil de certificado se almacenan en un archivo profile_name.cfg en el directorio del perfil de la CA, /var/lib/pki/pki-tomcat/ca/profiles/ca. Todos los parámetros de un modelo (valores predeterminados, entradas, salidas y restricciones) se configuran en un único conjunto de políticas. Un conjunto de políticas para un modelo de certificado tiene el nombre policyset.policyName.policyNumber. Por ejemplo, para el conjunto de políticas serverCertSet:

policyset.list=serverCertSet
policyset.serverCertSet.list=1,2,3,4,5,6,7,8
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=pki-ipa, O=IPA
policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl
policyset.serverCertSet.2.constraint.name=Validity Constraint
policyset.serverCertSet.2.constraint.params.range=740
policyset.serverCertSet.2.constraint.params.notBeforeCheck=false
policyset.serverCertSet.2.constraint.params.notAfterCheck=false
policyset.serverCertSet.2.default.class_id=validityDefaultImpl
policyset.serverCertSet.2.default.name=Validity Default
policyset.serverCertSet.2.default.params.range=731
policyset.serverCertSet.2.default.params.startTime=0

Cada conjunto de políticas contiene una lista de políticas configuradas para el perfil de certificado por número de ID de política en el orden en que deben evaluarse. El servidor evalúa cada conjunto de políticas para cada solicitud que recibe. Cuando se recibe una única solicitud de certificado, se evalúa un conjunto y se ignoran los demás conjuntos del perfil. Cuando se emiten pares de claves dobles, el primer conjunto de políticas se evalúa para la primera solicitud de certificado y el segundo conjunto se evalúa para la segunda solicitud de certificado. No se necesita más de un conjunto de políticas cuando se emiten certificados individuales ni más de dos conjuntos cuando se emiten pares de claves dobles.

Tabla 41.1. Parámetros del archivo de configuración del modelo de certificado

ParámetroDescripción

desc

Una descripción de texto libre del modelo de certificado, que se muestra en la página de entidades finales. Por ejemplo, desc=This certificate profile is for enrolling server certificates with agent authentication.

activar

Habilita el perfil para que sea accesible a través de la página de entidades finales. Por ejemplo, enable=true.

auth.instance_id

Establece el complemento del gestor de autenticación que se utilizará para autenticar la solicitud de certificado. Para la inscripción automática, la CA emite un certificado inmediatamente si la autenticación es correcta. Si la autenticación falla o no se especifica ningún complemento de autenticación, la solicitud se pone en cola para ser aprobada manualmente por un agente. Por ejemplo, auth.instance_id=AgentCertAuth.

authz.acl

Especifica la restricción de autorización. Se utiliza principalmente para establecer la lista de control de acceso (ACL) de evaluación de grupos. Por ejemplo, el parámetro caCMCUserCert requiere que el firmante de la solicitud de CMC pertenezca al grupo de agentes gestores de certificados:

authz.acl=group="Certificate Manager Agents

En la renovación de certificados de usuario basada en directorios, esta opción se utiliza para garantizar que el solicitante original y el usuario actualmente autenticado son el mismo. Una entidad debe autenticarse (vincularse o, esencialmente, iniciar sesión en el sistema) antes de que se pueda evaluar la autorización.

nombre

El nombre del modelo de certificado. Por ejemplo, name=Agent-Authenticated Server Certificate Enrollment. Este nombre se muestra en la página de inscripción o renovación de los usuarios finales.

lista.de entrada

Enumera las entradas permitidas para el modelo de certificado por su nombre. Por ejemplo, input.list=i1,i2.

input.input_id.class_id

Indica el nombre de la clase java para la entrada por el ID de la entrada (el nombre de la entrada que aparece en input.list). Por ejemplo, input.i1.class_id=certReqInputImpl.

lista de salida

Enumera los posibles formatos de salida del modelo de certificado por su nombre. Por ejemplo, output.list=o1.

output.output_id.class_id

Especifica el nombre de la clase java para el formato de salida nombrado en output.list. Por ejemplo, output.o1.class_id=certOutputImpl.

lista de políticas

Enumera las reglas de perfil de certificado configuradas. Para los certificados duales, un conjunto de reglas se aplica a la clave de firma y el otro a la clave de cifrado. Los certificados individuales sólo utilizan un conjunto de reglas de perfil de certificado. Por ejemplo, policyset.list=serverCertSet.

policyset.policyset_id.list

Enumera las políticas del conjunto de políticas configuradas para el modelo de certificado por número de identificación de política en el orden en que deben evaluarse. Por ejemplo, policyset.serverCertSet.list=1,2,3,4,5,6,7,8.

conjunto_de_políticas.número_de_políticas.restricción.class_id

Indica el nombre de la clase java del complemento de restricción establecido para el valor predeterminado configurado en la regla del perfil. Por ejemplo, policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl.

conjunto_de_políticas.número_de_políticas.nombre.de.restricción

Proporciona el nombre definido por el usuario de la restricción. Por ejemplo, policyset.serverCertSet.1.constraint.name=Restricción del nombre del sujeto.

policyset.policyset_id.policy_number.constraint.params.attribute

Especifica un valor para un atributo permitido para la restricción. Los posibles atributos varían en función del tipo de restricción. Por ejemplo, policyset.serverCertSet.1.constraint.params.pattern=CN=.*.

policyset.policyset_id.policy_number.default.class_id

Da el nombre de la clase java para el conjunto por defecto en la regla del perfil. Por ejemplo, policyset.serverCertSet.1.default.class_id=userSubjectNameDefaultImpl

conjunto_de_políticas.número_de_políticas.predeterminado.nombre

Proporciona el nombre definido por el usuario del valor predeterminado. Por ejemplo, policyset.serverCertSet.1.default.name=Nombre por defecto

policyset.policyset_id.policy_number.default.params.attribute

Especifica un valor para un atributo permitido para el valor predeterminado. Los atributos posibles varían en función del tipo de valor predeterminado. Por ejemplo, policyset.serverCertSet.1.default.params.name=CN=(Nombre)$request.requestor_name$.

Capítulo 42. Gestión de la validez de los certificados en IdM

En la Gestión de Identidades (IdM), se puede gestionar la validez tanto de los certificados ya existentes como de los que se quieran emitir en el futuro, pero los métodos son diferentes.

Gestión de la validez de un certificado existente emitido por la CA IdM

En IdM están disponibles los siguientes métodos para ver la fecha de caducidad de un certificado:

Puede gestionar la validez de un certificado ya existente que haya sido emitido por la CA IdM de las siguientes maneras:

Gestionar la validez de los futuros certificados emitidos por la CA IdM

Para gestionar la validez de futuros certificados emitidos por la CA de IdM, modifique, importe o cree un modelo de certificado. Para obtener más información, consulte Creación y gestión de perfiles de certificado en Gestión de identidades.

42.1. Ver la fecha de caducidad de un certificado

42.1.1. Ver la fecha de caducidad de un certificado en IdM WebUI

Puedes utilizar IdM WebUI para ver la fecha de caducidad de todos los certificados que han sido emitidos por IdM CA.

Requisitos previos

  • Asegúrese de haber obtenido las credenciales del administrador.

Procedimiento

  1. En el menú Authentication, haga clic en Certificates > Certificates.
  2. Haga clic en el número de serie del certificado para abrir la página de información del certificado.

    Figura 42.1. Lista de certificados

    host cert list
  3. En la página de información del certificado, localice la información de Expires On.

42.1.2. Visualización de la fecha de caducidad de un certificado en la CLI

Puede utilizar la interfaz de línea de comandos (CLI) para ver la fecha de caducidad de un certificado.

Procedimiento

  • Utilice la utilidad openssl para abrir el archivo en un formato legible:

    $ openssl x509 -noout -text -in ca.pem
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 1 (0x1)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O = IDM.EXAMPLE.COM, CN = Certificate Authority
            Validity
                Not Before: Oct 30 19:39:14 2017 GMT
                Not After : Oct 30 19:39:14 2037 GMT

42.2. Revocación de certificados con las CAs de IdM integradas

42.2.1. Motivos de revocación de certificados

Un certificado revocado no es válido y no puede utilizarse para la autenticación. Todas las revocaciones son permanentes, excepto la razón 6: Certificate Hold.

El motivo de revocación por defecto es 0: unspecified.

Tabla 42.1. Motivos de revocación

IDRazónExplicación

0

Sin especificar

 

1

Clave comprometida

La clave que emitió el certificado ya no es de confianza.

Posibles causas: pérdida del token, acceso incorrecto al archivo.

2

CA Comprometida

La CA que emitió el certificado ya no es de confianza.

3

Cambio de afiliación

Posibles causas:

* Una persona ha dejado la empresa o se ha trasladado a otro departamento.

* Se está retirando un host o servicio.

4

Sustituido

Un nuevo certificado ha sustituido al actual.

5

Cese de la actividad

El host o el servicio está siendo retirado.

6

Certificado de retención

El certificado se revoca temporalmente. Puede restaurar el certificado más tarde.

8

Eliminar de CRL

El certificado no está incluido en la lista de revocación de certificados (CRL).

9

Privilegio retirado

El usuario, el host o el servicio ya no pueden utilizar el certificado.

10

Compromiso de autoridad de atributos (AA)

El certificado AA ya no es de confianza.

42.2.2. Revocación de certificados con las CA de IdM integradas mediante IdM WebUI

Si sabe que ha perdido la clave privada de su certificado, debe revocar el certificado para evitar su uso indebido. Complete este procedimiento para utilizar la IdM WebUI para revocar un certificado emitido por la CA de IdM.

Procedimiento

  1. Haga clic en Authentication > Certificates > Certificates.
  2. Haga clic en el número de serie del certificado para abrir la página de información del certificado.

    Figura 42.2. Lista de certificados

    host cert list
  3. En la página de información del certificado, haga clic en AccionesRevocar certificado.
  4. Seleccione el motivo de la revocación y haga clic en Revocar. Consulte Sección 42.2.1, “Motivos de revocación de certificados” para obtener más detalles.

42.2.3. Revocación de certificados con las CA de IdM integradas mediante la CLI de IdM

Si sabe que ha perdido la clave privada de su certificado, debe revocar el certificado para evitar su uso indebido. Complete este procedimiento para utilizar la CLI de IdM para revocar un certificado emitido por la CA de IdM.

Procedimiento

Por ejemplo, para revocar el certificado con número de serie 1032 por el motivo 1: Key Compromised, introduzca:

$ ipa cert-revoke 1032 --revocation-reason=1

Para más detalles sobre la solicitud de un nuevo certificado, consulte la siguiente documentación:

42.3. Restauración de certificados con las CAs de IdM integradas

Si ha revocado un certificado por la razón 6: Certificate Hold, puede restaurarlo de nuevo si la clave privada del certificado no se ha visto comprometida. Para restaurar un certificado, utilice uno de los siguientes procedimientos:

42.3.1. Restauración de certificados con las CA de IdM integradas mediante IdM WebUI

Realice este procedimiento para utilizar la WebUI de IdM para restaurar un certificado de IdM que haya sido revocado por la razón 6: Certificate Hold.

Procedimiento

  1. En el menú Authentication, haga clic en Certificates > Certificates.
  2. Haga clic en el número de serie del certificado para abrir la página de información del certificado.

    Figura 42.3. Lista de certificados

    host cert list
  3. En la página de información del certificado, haga clic en AccionesRestaurar certificado.

42.3.2. Restauración de certificados con las CA de IdM integradas mediante la CLI de IdM

Realice este procedimiento para utilizar la CLI de IdM para restaurar un certificado de IdM que haya sido revocado por el motivo 6: Certificate Hold.

Procedimiento

  • Utilice el comando ipa cert-remove-hold y especifique el número de serie del certificado. Por ejemplo:

    $ ipa cert-remove-hold 1032

Capítulo 43. Configuración de reglas de asignación de certificados en la Gestión de Identidades

43.1. Reglas de asignación de certificados para configurar la autenticación en tarjetas inteligentes

Las reglas de mapeo de certificados son una forma conveniente de permitir que los usuarios se autentiquen usando certificados en escenarios en los que el administrador de la Gestión de Identidades (IdM) no tiene acceso a los certificados de ciertos usuarios. Esta falta de acceso suele deberse a que los certificados han sido emitidos por una autoridad de certificación externa. Un caso de uso especial lo representan los certificados emitidos por el Sistema de Certificados de un Directorio Activo (AD) con el que el dominio IdM mantiene una relación de confianza.

Las reglas de asignación de certificados también son convenientes si el entorno de IdM es grande con muchos usuarios que utilizan tarjetas inteligentes. En esta situación, añadir certificados completos puede ser complicado. El asunto y el emisor son predecibles en la mayoría de los casos y, por lo tanto, son más fáciles de añadir con antelación que el certificado completo. Como administrador del sistema, puede crear una regla de asignación de certificados y añadir datos de asignación de certificados a una entrada de usuario incluso antes de que se emita un certificado para un usuario concreto. Una vez emitido el certificado, el usuario puede iniciar sesión utilizando el certificado, aunque el certificado completo no se haya cargado todavía en la entrada de usuario.

Además, como los certificados deben renovarse a intervalos regulares, las reglas de asignación de certificados reducen la carga administrativa. Cuando se renueva el certificado de un usuario, el administrador no tiene que actualizar la entrada del usuario. Por ejemplo, si la asignación se basa en los valores de Subject y Issuer, y si el nuevo certificado tiene el mismo asunto y emisor que el anterior, la asignación sigue siendo válida. Si, por el contrario, se utilizara el certificado completo, el administrador tendría que cargar el nuevo certificado en la entrada de usuario para sustituir al antiguo.

Para configurar la asignación de certificados:

  1. Un administrador tiene que cargar los datos de asignación del certificado (normalmente el emisor y el asunto) o el certificado completo en una cuenta de usuario.
  2. Un administrador tiene que crear una regla de asignación de certificados para permitir el inicio de sesión en IdM de un usuario

    1. cuya cuenta contiene una entrada de datos de asignación de certificados
    2. cuya entrada de datos de asignación de certificados coincide con la información del certificado

    Para obtener detalles sobre los componentes individuales que conforman una regla de correspondencia y cómo obtenerlos y utilizarlos, consulte Componentes de una regla de correspondencia de identidad en IdM y Obtención del emisor de un certificado para su uso en una regla de correspondencia.

Después, cuando el usuario final presenta el certificado, almacenado en el sistema de archivos o en una tarjeta inteligente, la autenticación se realiza con éxito.

43.1.1. Reglas de asignación de certificados para fideicomisos con dominios de Active Directory

En esta sección se describen los diferentes casos de uso de la asignación de certificados que son posibles si una implementación de IdM está en una relación de confianza con un dominio de Active Directory (AD).

Las reglas de asignación de certificados son una forma práctica de permitir el acceso a los recursos de IdM a los usuarios que tienen certificados de tarjeta inteligente emitidos por el sistema de certificados AD de confianza. Dependiendo de la configuración de AD, son posibles los siguientes escenarios:

  • Si el certificado es emitido por AD pero el usuario y el certificado están almacenados en IdM, el mapeo y todo el procesamiento de la solicitud de autenticación tiene lugar en el lado de IdM. Para obtener detalles sobre la configuración de este escenario, consulte Configuración de la asignación de certificados para usuariosalmacenados en IdM
  • Si el usuario está almacenado en AD, el procesamiento de la solicitud de autenticación tiene lugar en AD. Hay tres subcasos diferentes:

43.1.2. Componentes de una regla de asignación de identidades en IdM

Esta sección describe los componentes de un identity mapping rule en IdM y cómo configurarlos. Cada componente tiene un valor por defecto que se puede anular. Puede definir los componentes en la interfaz web o en la CLI. En la CLI, la regla de asignación de identidades se crea mediante el comando ipa certmaprule-add.

Regla de asignación

El componente de regla de asignación asocia (o maps) un certificado con una o más cuentas de usuario. La regla define un filtro de búsqueda LDAP que asocia un certificado con la cuenta de usuario prevista.

Los certificados emitidos por diferentes autoridades de certificación (CA) pueden tener diferentes propiedades y pueden ser utilizados en diferentes dominios. Por lo tanto, IdM no aplica las reglas de asignación de forma incondicional, sino sólo a los certificados apropiados. Los certificados apropiados se definen mediante matching rules.

Tenga en cuenta que si deja vacía la opción de regla de asignación, los certificados se buscan en el atributo userCertificate como un archivo binario codificado con DER.

Defina la regla de asignación en la CLI utilizando la opción --maprule.

Regla de concordancia

El componente de la regla de correspondencia selecciona un certificado al que desea aplicar la regla de asignación. La regla de correspondencia por defecto coincide con los certificados con el uso de digitalSignature key y clientAuth extended key.

Defina la regla de coincidencia en la CLI utilizando la opción --matchrule.

Lista de dominios

La lista de dominios especifica los dominios de identidad en los que desea que IdM busque los usuarios al procesar las reglas de asignación de identidad. Si se deja la opción sin especificar, IdM busca los usuarios sólo en el dominio local al que pertenece el cliente IdM.

Defina el dominio en la CLI utilizando la opción --domain.

Prioridad

Cuando hay varias reglas aplicables a un certificado, la regla con mayor prioridad tiene prioridad. Todas las demás reglas se ignoran.

  • Cuanto menor sea el valor numérico, mayor será la prioridad de la regla de asignación de identidad. Por ejemplo, una regla con prioridad 1 tiene mayor prioridad que una regla con prioridad 2.
  • Si una regla no tiene un valor de prioridad definido, tiene la prioridad más baja.

Defina la prioridad de la regla de asignación en la CLI utilizando la opción --priority.

Ejemplo de regla de asignación de certificados

Definir, mediante la CLI, una regla de asignación de certificados denominada simple_rule que permita la autenticación para un certificado emitido por el Smart Card CA de la organización EXAMPLE.ORG siempre que el Subject de dicho certificado coincida con una entrada certmapdata de una cuenta de usuario en IdM:

# ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

43.1.3. Obtención del emisor de un certificado para utilizarlo en una regla de concordancia

Este procedimiento describe cómo obtener la información del emisor de un certificado para poder copiarla y pegarla en la regla de correspondencia de una regla de asignación de certificados. Para obtener el formato del emisor requerido por una regla de correspondencia, utilice la utilidad openssl x509.

Requisitos previos

  • Tiene el certificado de usuario en formato .pem o .crt

Procedimiento

  1. Obtenga la información del usuario del certificado. Utilice la utilidad de visualización y firma de certificados openssl x509 con:

    • la opción -noout para evitar la salida de una versión codificada de la solicitud
    • la opción -issuer para imprimir el nombre del emisor
    • la opción -in para especificar el nombre del archivo de entrada del que se leerá el certificado
    • la opción -nameopt con el valor RFC2253 para mostrar la salida con el nombre distinguido relativo (RDN) más específico primero

      Si el archivo de entrada contiene un certificado de Gestión de Identidades, la salida del comando muestra que el Emisor está definido utilizando la información de Organisation:

      # openssl x509 -noout -issuer -in idm_user.crt -nameopt RFC2253
      issuer=CN=Certificate Authority,O=REALM.EXAMPLE.COM

      Si el archivo de entrada contiene un certificado de Active Directory, la salida del comando muestra que el Emisor está definido utilizando la información de Domain Component:

      # openssl x509 -noout -issuer -in ad_user.crt -nameopt RFC2253
      issuer=CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM
  2. Opcionalmente, para crear una nueva regla de asignación en la CLI basada en una regla de coincidencia que especifique que el emisor del certificado debe ser el AD-WIN2012R2-CA extraído del dominio ad.example.com y el asunto del certificado debe coincidir con la entrada certmapdata de una cuenta de usuario en IdM:

    # ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

Información adicional

Para obtener detalles sobre los formatos admitidos para la regla de correspondencia y la regla de asignación, y una explicación de los campos de prioridad y dominio, consulte la página de manual sss-certmap(5).

43.2. Configuración de la asignación de certificados para los usuarios almacenados en IdM

Esta historia de usuario describe los pasos que debe seguir un administrador del sistema para habilitar la asignación de certificados en IdM si el usuario para el que se está configurando la autenticación de certificados está almacenado en IdM.

Requisitos previos

  • El usuario tiene una cuenta en IdM.
  • El administrador dispone del certificado completo o de los datos de asignación del certificado para añadirlos a la entrada del usuario.

43.2.1. Añadir una regla de asignación de certificados en IdM

En este apartado se describe cómo configurar una regla de asignación de certificados para que los usuarios de IdM con certificados que cumplan las condiciones especificadas en la regla de asignación y en sus entradas de datos de asignación de certificados puedan autenticarse en IdM.

43.2.1.1. Añadir una regla de asignación de certificados en la interfaz web de IdM

  1. Inicie sesión en la interfaz web de IdM como administrador.
  2. Navegue hasta AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Haga clic en Add.

    Figura 43.1. Añadir una nueva regla de asignación de certificados en la interfaz web de IdM

    new certmaprule add
  4. Introduzca el nombre de la regla.
  5. Introduzca la regla de asignación. Por ejemplo, para que el IdM busque las entradas Issuer y Subject en cualquier certificado que se le presente, y base su decisión de autenticar o no en la información encontrada en estas dos entradas del certificado presentado:

    (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
  6. Introduzca la regla de coincidencia. Por ejemplo, para permitir sólo los certificados emitidos por la Smart Card CA de la organización EXAMPLE.ORG para autenticar a los usuarios en el IdM:

    <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG

    Figura 43.2. Introducción de los detalles de una regla de asignación de certificados en la interfaz web de IdM

    certmaprule add details1
  7. Haga clic en Add en la parte inferior del cuadro de diálogo para añadir la regla y cerrar el cuadro.
  8. El demonio de servicios de seguridad del sistema (SSSD) relee periódicamente las reglas de asignación de certificados. Para forzar que la regla recién creada se cargue inmediatamente, reinicie SSSD:

    # systemctl restart sssd

Ahora tiene configurada una regla de asignación de certificados que compara el tipo de datos especificados en la regla de asignación que encuentra en un certificado de tarjeta inteligente con los datos de asignación de certificados en sus entradas de usuario de IdM. Cuando encuentra una coincidencia, autentifica al usuario correspondiente.

43.2.1.2. Adición de una regla de asignación de certificados en la CLI de IdM

  1. Obtenga las credenciales del administrador:

    # kinit admin
  2. Introduzca la regla de asignación y la regla de coincidencia en la que se basa la regla de asignación. Por ejemplo, para hacer que IdM busque las entradas Issuer y Subject en cualquier certificado presentado, y base su decisión de autenticar o no en la información encontrada en estas dos entradas del certificado presentado, reconociendo sólo los certificados emitidos por el Smart Card CA de la organización EXAMPLE.ORG:

    # ipa certmaprule-add rule_name --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "rule_name"
    -------------------------------------------------------
      Rule name: rule_name
      Mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
      Matching rule: <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG
      Enabled: TRUE
  3. El demonio de servicios de seguridad del sistema (SSSD) relee periódicamente las reglas de asignación de certificados. Para forzar que la regla recién creada se cargue inmediatamente, reinicie SSSD:

    # systemctl restart sssd

Ahora tiene configurada una regla de asignación de certificados que compara el tipo de datos especificados en la regla de asignación que encuentra en un certificado de tarjeta inteligente con los datos de asignación de certificados en sus entradas de usuario de IdM. Cuando encuentra una coincidencia, autentifica al usuario correspondiente.

43.2.2. Añadir datos de asignación de certificados a una entrada de usuario en IdM

En este apartado se describe cómo introducir datos de asignación de certificados en una entrada de usuario de IdM para que el usuario pueda autenticarse utilizando varios certificados siempre que todos ellos contengan los valores especificados en la entrada de datos de asignación de certificados.

43.2.2.1. Añadir datos de asignación de certificados a una entrada de usuario en la interfaz web de IdM

  1. Inicie sesión en la interfaz web de IdM como administrador.
  2. Navegue hasta UsersActive usersidm_user.
  3. Busque la opción Certificate mapping data y haga clic en Add.
  4. Si tiene el certificado de idm_user a su disposición:

    1. En la interfaz de línea de comandos, visualice el certificado utilizando la utilidad cat o un editor de texto:

      [root@server ~]# cat idm_user_certificate.pem
      -----BEGIN CERTIFICATE-----
      MIIFFTCCA/2gAwIBAgIBEjANBgkqhkiG9w0BAQsFADA6MRgwFgYDVQQKDA9JRE0u
      RVhBTVBMRS5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0x
      ODA5MDIxODE1MzlaFw0yMDA5MDIxODE1MzlaMCwxGDAWBgNVBAoMD0lETS5FWEFN
      [...output truncated...]
    2. Copie el certificado.
    3. En la interfaz web de IdM, haz clic en Add junto a Certificate y pega el certificado en la ventana que se abre.

      Figura 43.3. Añadir los datos de asignación del certificado de un usuario: certificado

      user add cert

      Alternativamente, si no tiene el certificado de idm_user a su disposición pero conoce el Issuer y el Subject del certificado, marque el botón de radio de Issuer and subject e introduzca los valores en las dos casillas respectivas.

      Figura 43.4. Añadir los datos de mapeo del certificado de un usuario: emisor y sujeto

      user add certdata
  5. Haga clic en Add.
  6. Opcionalmente, si tiene acceso al certificado completo en el formato .pem, verifique que el usuario y el certificado están vinculados:

    1. Utilice la utilidad sss_cache para invalidar el registro de idm_user en la caché de SSSD y forzar una recarga de la información de idm_user:

      # sss_cache -u idm_user
    2. Ejecute el comando ipa certmap-match con el nombre del archivo que contiene el certificado del usuario de IdM:

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      La salida confirma que ahora tiene datos de asignación de certificados añadidos a idm_user y que existe una regla de asignación correspondiente. Esto significa que puede utilizar cualquier certificado que coincida con los datos de asignación de certificados definidos para autenticarse como idm_user.

43.2.2.2. Adición de datos de asignación de certificados a una entrada de usuario en la CLI de IdM

  1. Obtenga las credenciales del administrador:

    # kinit admin
  2. Si dispone del certificado de idm_user, añada el certificado a la cuenta de usuario mediante el comando ipa user-add-cert:

    # CERT=`cat idm_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa user-add-certmapdata idm_user --certificate $CERT

    Alternativamente, si no tiene el certificado de idm_user a su disposición pero conoce el Issuer y el Subject del certificado de idm_user:

    # ipa user-add-certmapdata idm_user --subject "O=EXAMPLE.ORG,CN=test" --issuer "CN=Smart Card CA,O=EXAMPLE.ORG"
    --------------------------------------------
    Added certificate mappings to user "idm_user"
    --------------------------------------------
      User login: idm_user
      Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG
  3. Opcionalmente, si tiene acceso al certificado completo en el formato .pem, verifique que el usuario y el certificado están vinculados:

    1. Utilice la utilidad sss_cache para invalidar el registro de idm_user en la caché de SSSD y forzar una recarga de la información de idm_user:

      # sss_cache -u idm_user
    2. Ejecute el comando ipa certmap-match con el nombre del archivo que contiene el certificado del usuario de IdM:

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      La salida confirma que ahora tiene datos de asignación de certificados añadidos a idm_user y que existe una regla de asignación correspondiente. Esto significa que puede utilizar cualquier certificado que coincida con los datos de asignación de certificados definidos para autenticarse como idm_user.

43.3. Configuración de la asignación de certificados para usuarios cuya entrada de usuario de AD contiene el certificado completo

Esta historia de usuario describe los pasos necesarios para habilitar la asignación de certificados en IdM si la implementación de IdM está en confianza con Active Directory (AD), el usuario está almacenado en AD y la entrada de usuario en AD contiene el certificado completo.

Requisitos previos

  • El usuario no tiene una cuenta en IdM.
  • El usuario tiene una cuenta en AD que contiene un certificado.
  • El administrador de IdM tiene acceso a los datos en los que se puede basar la regla de asignación de certificados de IdM.

43.3.1. Adición de una regla de asignación de certificados para los usuarios cuya entrada AD contiene certificados completos

43.3.1.1. Añadir una regla de asignación de certificados en la interfaz web de IdM

  1. Inicie sesión en la interfaz web de IdM como administrador.
  2. Navegue hasta AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Haga clic en Add.

    Figura 43.5. Añadir una nueva regla de asignación de certificados en la interfaz web de IdM

    new certmaprule add
  4. Introduzca el nombre de la regla.
  5. Introduzca la regla de asignación. Para que todo el certificado que se presenta a IdM para la autenticación se compare con lo que está disponible en AD:

    (userCertificate;binary={cert!bin})
  6. Introduzca la regla de coincidencia. Por ejemplo, para permitir que sólo se autentifiquen los certificados emitidos por el AD-ROOT-CA del dominio AD.EXAMPLE.COM:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com

    Figura 43.6. Regla de asignación de certificados para un usuario con un certificado almacenado en AD

    certmaprule add details ad cert
  7. Haga clic en Add.
  8. El demonio de servicios de seguridad del sistema (SSSD) relee periódicamente las reglas de asignación de certificados. Para forzar la carga inmediata de la regla recién creada, reinicie SSSD en la CLI::

    # systemctl restart sssd

43.3.1.2. Adición de una regla de asignación de certificados en la CLI de IdM

  1. Obtenga las credenciales del administrador:

    # kinit admin
  2. Introduzca la regla de asignación y la regla de correspondencia en la que se basa la regla de asignación. Para que todo el certificado que se presenta para la autenticación sea comparado con lo que está disponible en AD, permitiendo sólo los certificados emitidos por el AD-ROOT-CA del dominio AD.EXAMPLE.COM para autenticar:

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. El demonio de servicios de seguridad del sistema (SSSD) relee periódicamente las reglas de asignación de certificados. Para forzar que la regla recién creada se cargue inmediatamente, reinicie SSSD:

    # systemctl restart sssd

43.4. Configuración de la asignación de certificados si AD está configurado para asignar certificados de usuario a cuentas de usuario

Esta historia de usuario describe los pasos necesarios para habilitar la asignación de certificados en IdM si la implementación de IdM está en confianza con Active Directory (AD), el usuario está almacenado en AD y la entrada de usuario en AD contiene datos de asignación de certificados.

Requisitos previos

  • El usuario no tiene una cuenta en IdM.
  • El usuario tiene una cuenta en AD que contiene el atributo altSecurityIdentities, el equivalente en AD del atributo IdM certmapdata.
  • El administrador de IdM tiene acceso a los datos en los que se puede basar la regla de asignación de certificados de IdM.

43.4.1. Añadir una regla de asignación de certificados si el dominio AD de confianza está configurado para asignar certificados de usuario

43.4.1.1. Añadir una regla de asignación de certificados en la interfaz web de IdM

  1. Inicie sesión en la interfaz web de IdM como administrador.
  2. Navegue hasta AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Haga clic en Add.

    Figura 43.7. Añadir una nueva regla de asignación de certificados en la interfaz web de IdM

    new certmaprule add
  4. Introduzca el nombre de la regla.
  5. Introduzca la regla de asignación. Por ejemplo, para hacer que AD DC busque las entradas Issuer y Subject en cualquier certificado presentado, y base su decisión de autenticar o no en la información encontrada en estas dos entradas del certificado presentado:

    (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
  6. Introduzca la regla de coincidencia. Por ejemplo, para permitir sólo los certificados emitidos por el AD-ROOT-CA del dominio AD.EXAMPLE.COM para autenticar a los usuarios en el IdM:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. Introduzca el dominio:

    ad.example.com

    Figura 43.8. Regla de asignación de certificados si AD está configurado para la asignación

    certmaprule add details ad map
  8. Haga clic en Add.
  9. El demonio de servicios de seguridad del sistema (SSSD) relee periódicamente las reglas de asignación de certificados. Para forzar la carga inmediata de la regla recién creada, reinicie SSSD en la CLI::

    # systemctl restart sssd

43.4.1.2. Adición de una regla de asignación de certificados en la CLI de IdM

  1. Obtenga las credenciales del administrador:

    # kinit admin
  2. Introduzca la regla de asignación y la regla de coincidencia en la que se basa la regla de asignación. Por ejemplo, para hacer que AD busque las entradas Issuer y Subject en cualquier certificado presentado, y sólo permita certificados emitidos por el AD-ROOT-CA del dominio AD.EXAMPLE.COM:

    # ipa certmaprule-add ad_configured_for_mapping_rule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})' --domain=ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "ad_configured_for_mapping_rule"
    -------------------------------------------------------
      Rule name: ad_configured_for_mapping_rule
      Mapping rule: (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. El demonio de servicios de seguridad del sistema (SSSD) relee periódicamente las reglas de asignación de certificados. Para forzar que la regla recién creada se cargue inmediatamente, reinicie SSSD:

    # systemctl restart sssd

43.4.2. Comprobación de los datos de asignación de certificados en el lado de AD

El atributo altSecurityIdentities es el equivalente en Active Directory (AD) del atributo de usuario certmapdata en IdM. Al configurar el mapeo de certificados en IdM en el escenario en el que un dominio AD de confianza está configurado para mapear certificados de usuario a cuentas de usuario, el administrador del sistema IdM necesita comprobar que el atributo altSecurityIdentities está configurado correctamente en las entradas de usuario en AD.

Para comprobar que AD contiene la información correcta para el usuario almacenado en AD, utilice el comando ldapsearch.

  • Por ejemplo, introduzca el siguiente comando para comprobar con el servidor adserver.ad.example.com que se dan las siguientes condiciones:

    • El atributo altSecurityIdentities se establece en la entrada de usuario de ad_user.
    • La regla del partido estipula que se aplican las siguientes condiciones:

      • El certificado que ad_user utiliza para autenticarse en AD fue emitido por AD-ROOT-CA del dominio ad.example.com.
      • El tema es <S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user:
    $ ldapsearch -o ldif-wrap=no -LLL -h adserver.ad.example.com \
    -p 389 -D cn=Administrator,cn=users,dc=ad,dc=example,dc=com \
    -W -b cn=users,dc=ad,dc=example,dc=com "(cn=ad_user)" \
    altSecurityIdentities
    Enter LDAP Password:
    dn: CN=ad_user,CN=Users,DC=ad,DC=example,DC=com
    altSecurityIdentities: X509:<I>DC=com,DC=example,DC=ad,CN=AD-ROOT-CA<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user

43.5. Configuración de la asignación de certificados si la entrada de usuario de AD no contiene ningún certificado ni datos de asignación

Esta historia de usuario describe los pasos necesarios para habilitar la asignación de certificados en IdM si la implementación de IdM está en confianza con Active Directory (AD), el usuario está almacenado en AD y la entrada de usuario en AD no contiene ni el certificado completo ni los datos de asignación de certificados.

Requisitos previos

  • El usuario no tiene una cuenta en IdM.
  • El usuario tiene una cuenta en AD que no contiene ni el certificado completo ni el atributo altSecurityIdentities, el equivalente en AD del atributo IdM certmapdata.
  • El administrador de IdM tiene el certificado completo del usuario de AD para añadirlo a la página web del usuario de AD user ID override en IdM.

43.5.1. Adición de una regla de asignación de certificados si la entrada de usuario de AD no contiene ningún certificado ni datos de asignación

43.5.1.1. Añadir una regla de asignación de certificados en la interfaz web de IdM

  1. Inicie sesión en la interfaz web de IdM como administrador.
  2. Navegue hasta AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Haga clic en Add.

    Figura 43.9. Añadir una nueva regla de asignación de certificados en la interfaz web de IdM

    new certmaprule add
  4. Introduzca el nombre de la regla.
  5. Introduzca la regla de asignación. Para que el certificado completo que se presenta a IdM para la autenticación se compare con el certificado almacenado en la entrada de anulación del ID de usuario de la entrada de usuario de AD en IdM:

    (userCertificate;binary={cert!bin})
  6. Introduzca la regla de coincidencia. Por ejemplo, para permitir que sólo se autentifiquen los certificados emitidos por el AD-ROOT-CA del dominio AD.EXAMPLE.COM:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. Introduzca el nombre del dominio. Por ejemplo, para buscar usuarios en el dominio ad.example.com:

    Figura 43.10. Regla de asignación de certificados para un usuario sin certificado o datos de asignación almacenados en AD

    certmaprule add details ad cert
  8. Haga clic en Add.
  9. El demonio de servicios de seguridad del sistema (SSSD) relee periódicamente las reglas de asignación de certificados. Para forzar la carga inmediata de la regla recién creada, reinicie SSSD en la CLI:

    # systemctl restart sssd

43.5.1.2. Adición de una regla de asignación de certificados en la CLI de IdM

  1. Obtenga las credenciales del administrador:

    # kinit admin
  2. Introduzca la regla de asignación y la regla de correspondencia en la que se basa la regla de asignación. Para que todo el certificado que se presenta para la autenticación se compare con el certificado almacenado en la entrada de anulación del ID de usuario de la entrada de usuario de AD en IdM, permitiendo únicamente la autenticación de los certificados emitidos por la AD-ROOT-CA del dominio AD.EXAMPLE.COM:

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. El demonio de servicios de seguridad del sistema (SSSD) relee periódicamente las reglas de asignación de certificados. Para forzar que la regla recién creada se cargue inmediatamente, reinicie SSSD:

    # systemctl restart sssd

43.5.2. Adición de un certificado a la anulación del ID de un usuario de AD si la entrada del usuario en AD no contiene ningún certificado ni datos de asignación

43.5.2.1. Adición de un certificado a la anulación del ID de un usuario de AD en la interfaz web de IdM

  1. Navegue hasta IdentityID ViewsDefault Trust View.
  2. Haga clic en Add.

    Figura 43.11. Añadir un nuevo ID de usuario en la interfaz web de IdM

    new useridoverride add
  3. En el campo User to override, introduzca ad_user@ad.example.com.
  4. Copie y pegue el certificado de ad_user en el campo Certificate.

    Figura 43.12. Configuración de la anulación del ID de usuario para un usuario de AD

    useridoverride add details
  5. Haga clic en Add.
  6. Opcionalmente, verifique que el usuario y el certificado están vinculados:

    1. Utilice la utilidad sss_cache para invalidar el registro de ad_user@ad.example.com en la caché de SSSD y forzar una recarga de la información de ad_user@ad.example.com:

      # sss_cache -u ad_user@ad.example.com
    2. Ejecute el comando ipa certmap-match con el nombre del archivo que contiene el certificado del usuario AD:

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

      La salida confirma que tiene datos de asignación de certificados añadidos a ad_user@ad.example.com y que existe una regla de asignación correspondiente definida en Añadir una regla de asignación de certificados si la entrada de usuario de AD no contiene ningún certificado o datos de asignación. Esto significa que puede utilizar cualquier certificado que coincida con los datos de asignación de certificados definidos para autenticarse como ad_user@ad.example.com.

43.5.2.2. Adición de un certificado a la anulación del ID de un usuario de AD en la CLI de IdM

  1. Obtenga las credenciales del administrador:

    # kinit admin
  2. Añada el certificado de ad_user@ad.example.com a la cuenta de usuario mediante el comando ipa idoverrideuser-add-cert:

    # CERT=`cat ad_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa idoverrideuser-add-cert ad_user@ad.example.com --certificate $CERT
  3. Opcionalmente, verifique que el usuario y el certificado están vinculados:

    1. Utilice la utilidad sss_cache para invalidar el registro de ad_user@ad.example.com en la caché de SSSD y forzar una recarga de la información de ad_user@ad.example.com:

      # sss_cache -u ad_user@ad.example.com
    2. Ejecute el comando ipa certmap-match con el nombre del archivo que contiene el certificado del usuario AD:

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

      La salida confirma que tiene datos de asignación de certificados añadidos a ad_user@ad.example.com y que existe una regla de asignación correspondiente definida en Añadir una regla de asignación de certificados si la entrada de usuario de AD no contiene ningún certificado o datos de asignación. Esto significa que puede utilizar cualquier certificado que coincida con los datos de asignación de certificados definidos para autenticarse como ad_user@ad.example.com.

43.6. Combinar varias reglas de asignación de identidades en una sola

Para combinar varias reglas de asignación de identidades en una regla combinada, utilice el carácter | (o) para preceder las reglas de asignación individuales, y sepárelas utilizando, por ejemplo, () paréntesis:

Ejemplo de filtro de asignación de certificados 1

$ ipa certmaprule-add ad_cert_for_ipa_and_ad_users \ --maprule='(|(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \ --matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \ --domain=ad.example.com

En el ejemplo anterior, la definición del filtro en la opción --maprule incluye estos criterios:

  • ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500} es un filtro que vincula el asunto y el emisor de un certificado de tarjeta inteligente con el valor del atributo ipacertmapdata en una cuenta de usuario de IdM, como se describe en Añadir una regla de asignación de certificados en IdM
  • altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500} es un filtro que vincula el asunto y el emisor de un certificado de tarjeta inteligente con el valor del atributo altSecurityIdentities de una cuenta de usuario de AD, como se describe en Añadir una regla de asignación de certificados si el dominio de AD de confianza está configurado para asignar certificados deusuario
  • La adición de la opción --domain=ad.example.com significa que los usuarios asignados a un determinado certificado no sólo se buscan en el dominio local idm.example.com sino también en el dominio ad.example.com

La definición del filtro en la opción --maprule acepta el operador lógico | (o), de modo que se pueden especificar múltiples criterios. En este caso, la regla asigna todas las cuentas de usuario que cumplen al menos uno de los criterios.

Ejemplo de filtro de asignación de certificados 2

$ ipa certmaprule-add ipa_cert_for_ad_users \
  --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
  --matchrule='<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM' \
  --domain=idm.example.com --domain=ad.example.com

En el ejemplo anterior, la definición del filtro en la opción --maprule incluye estos criterios:

La definición del filtro en la opción --maprule acepta el operador lógico | (o), de modo que se pueden especificar múltiples criterios. En este caso, la regla asigna todas las cuentas de usuario que cumplen al menos uno de los criterios.

Capítulo 44. Configuración de la autenticación con un certificado almacenado en el escritorio de un cliente IdM

Al configurar la gestión de identidades (IdM), los administradores del sistema IdM pueden permitir que los usuarios se autentiquen en la interfaz de usuario web de IdM y en la interfaz de línea de comandos (CLI) utilizando un certificado que una autoridad de certificación (CA) ha emitido para los usuarios.

El navegador web puede ejecutarse en un sistema que no forme parte del dominio IdM.

Esta historia de usuario proporciona instrucciones sobre cómo configurar y probar eficazmente el inicio de sesión en la UI web y la CLI de Identity Management con un certificado almacenado en el escritorio de un cliente de IdM. Al seguir esta historia de usuario,

Nota

Sólo los usuarios de Gestión de Identidades pueden iniciar sesión en la interfaz web utilizando un certificado. Los usuarios de Active Directory pueden iniciar sesión con su nombre de usuario y contraseña.

44.1. Configuración del servidor de gestión de identidades para la autenticación de certificados en la interfaz web

Como administrador de la gestión de identidades (IdM), puede permitir a los usuarios utilizar certificados para autenticarse en su entorno de IdM.

Procedimiento

Como administrador de la Gestión de Identidades:

  1. En un servidor de gestión de identidades, obtenga privilegios de administrador y cree un script de shell para configurar el servidor.

    1. Ejecute el comando ipa-advise config-server-for-smart-card-auth, y guarde su salida en un archivo, por ejemplo server_certificate_script.sh:

      # kinit admin
      # ipa-advise config-server-for-smart-card-auth > server_certificate_script.sh
    2. Añade permisos de ejecución al archivo utilizando la utilidad chmod:

      # chmod x server_certificate_script.sh
  2. En todos los servidores del dominio de Gestión de Identidades, ejecute el script server_certificate_script.sh

    1. con la ruta del certificado de la autoridad de certificación IdM, /etc/ipa/ca.crt, como entrada si la CA IdM es la única autoridad de certificación que ha emitido los certificados de los usuarios para los que desea habilitar la autenticación de certificados:

      # ./server_certificate_script.sh /etc/ipa/ca.crt
    2. con las rutas que conducen a los certificados de CA relevantes como entrada si diferentes CAs externas firmaron los certificados de los usuarios para los que desea habilitar la autenticación de certificados:

      # ./server_certificate_script.sh /tmp/ca1.pem /tmp/ca2.pem
Nota

No olvides ejecutar el script en cada nueva réplica que añadas al sistema en el futuro si quieres tener habilitada la autenticación de certificados para los usuarios en toda la topología.

44.2. Solicitar un nuevo certificado de usuario y exportarlo al cliente

Como administrador de Gestión de Identidades (IdM), puede crear certificados para los usuarios de su entorno IdM y exportarlos a los clientes IdM en los que desee habilitar la autenticación de certificados para los usuarios.

Nota

Puede omitir esta sección si el usuario que desea autenticar utilizando un certificado ya tiene un certificado.

Procedimiento

  1. Opcionalmente, cree un nuevo directorio, por ejemplo ~/certdb/, y conviértalo en una base de datos de certificados temporal. Cuando se le pida, cree una contraseña de la base de datos de certificados NSS para cifrar las claves del certificado que se generará en un paso posterior:

    # mkdir ~/certdb/
    # certutil -N -d ~/certdb/
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
  2. Cree la solicitud de firma de certificado (CSR) y redirija la salida a un archivo. Por ejemplo, para crear una CSR con el nombre certificate_request.csr para un certificado de bits 4096 para el usuario idm_user en el ámbito IDM.EXAMPLE.COM, estableciendo el apodo de las claves privadas del certificado como idm_user para facilitar su localización, y estableciendo el asunto como CN=idm_user,O=IDM.EXAMPLE.COM:

    # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s \ "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr
  3. Cuando se le solicite, introduzca la misma contraseña que introdujo cuando utilizó certutil para crear la base de datos temporal. A continuación, siga escribiendo randlomly hasta que se le indique que se detenga:

    Enter Password or Pin for "NSS Certificate DB":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
  4. Envíe el archivo de solicitud de certificado al servidor. Especifique la entidad de seguridad de Kerberos que se asociará con el certificado recién emitido, el archivo de salida para almacenar el certificado y, opcionalmente, el perfil del certificado. Por ejemplo, para obtener un certificado del perfil IECUserRoles, un perfil con extensión de roles de usuario añadidos, para la entidad de seguridad idm_user@IDM.EXAMPLE.COM, y guardarlo en el archivo ~/idm_user.pem:

    # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --certificate-out=~/idm_user.pem
  5. Añade el certificado a la base de datos del NSS. Utilice la opción -n para establecer el mismo apodo que utilizó al crear la CSR anteriormente para que el certificado coincida con la clave privada en la base de datos del NSS. La opción -t establece el nivel de confianza. Para más detalles, consulte la página man de certutil(1). La opción -i especifica el archivo de certificado de entrada. Por ejemplo, para añadir a la base de datos del NSS un certificado con el apodo idm_user que está almacenado en el archivo ~/idm_user.pem en la base de datos ~/certdb/:

    # certutil -A -d ~/certdb/ -n idm_user -t \ "P,," -i ~/idm_user.pem
  6. Verifique que la clave en la base de datos NSS no muestra (orphan) como su apodo. Por ejemplo, para verificar que el certificado almacenado en la base de datos ~/certdb/ no está huérfano:

    # certutil -K -d ~/certdb/
    < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user
  7. Utilice el comando pk12util para exportar el certificado de la base de datos NSS al formato PKCS12. Por ejemplo, para exportar el certificado con el apodo idm_user de la base de datos NSS /root/certdb al archivo ~/idm_user.p12:

    # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  8. Transfiera el certificado al host en el que desea que se habilite la autenticación de certificados para idm_user:

    # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/
  9. En el host al que se ha transferido el certificado, haga que el directorio en el que se almacena el archivo .pkcs12 sea inaccesible para el grupo "otros" por razones de seguridad:

    # chmod o-rwx /home/idm_user/
  10. Por razones de seguridad, elimine la base de datos NSS temporal y el archivo .pkcs12 del servidor:

    # rm ~/certdb/
    # rm ~/idm_user.p12

44.3. Asegurarse de que el certificado y el usuario están vinculados

Nota

Puede omitir esta sección si el certificado del usuario ha sido emitido por la CA de IdM.

Para que la autenticación con certificado funcione, debe asegurarse de que el certificado está vinculado al usuario que lo utilizará para autenticarse en la Gestión de Identidades (IdM).

44.4. Configuración de un navegador para activar la autenticación de certificados

Para poder autenticarse con un certificado cuando se utiliza la WebUI para iniciar sesión en la Gestión de Identidades (IdM), es necesario importar el usuario y los certificados de la autoridad de certificación (CA) correspondiente en el navegador Mozilla Firefox o Google Chrome. El propio host en el que se ejecuta el navegador no tiene que formar parte del dominio de IdM.

IdM admite los siguientes navegadores para conectarse a la WebUI:

  • Mozilla Firefox 38 y posteriores
  • Google Chrome 46 y posteriores

El siguiente procedimiento muestra cómo configurar el navegador Mozilla Firefox 57.0.1.

Requisitos previos

Procedimiento

  1. Abra Firefox y, a continuación, vaya a PreferencesPrivacy & Security.

    Figura 44.1. Sección de privacidad y seguridad en Preferencias

    privacy and security
  2. Haga clic en Ver Certificados.

    Figura 44.2. Ver Certificados en Privacidad y Seguridad

    view certificates
  3. En la pestaña Your Certificates, haga clic en Importar. Localice y abra el certificado del usuario en el formato PKCS12 y, a continuación, haga clic en Aceptar y en OK.
  4. Asegúrese de que la Autoridad de Certificación de Gestión de Identidades es reconocida por Firefox como una autoridad de confianza:

    1. Guarde el certificado de la CA de IdM localmente:

      • Navega hasta la interfaz web de IdM escribiendo el nombre de tu servidor de IdM en la barra de direcciones de Firefox. Haga clic en Advanced en la página de advertencia de conexión insegura.

        Figura 44.3. Conexión insegura

        connection not secure idm
      • Add Exception. Haga clic en View.

        Figura 44.4. Ver los detalles de un certificado

        view ca certificate idm
      • En la pestaña Details, resalte los campos Certificate Authority.

        Figura 44.5. Exportación del certificado CA

        exporting ca cert idm
      • Haga clic en Exportar. Guarde el certificado de la CA, por ejemplo, como el archivo CertificateAuthority.crt, y luego haga clic en Cerrar, y Cancelar.
    2. Importe el certificado de la CA de IdM a Firefox como un certificado de autoridad de certificación de confianza:

      • Abre Firefox, ve a Preferencias y haz clic en Privacidad & Seguridad.

        Figura 44.6. Sección de privacidad y seguridad en Preferencias

        privacy and security
      • Haga clic en Ver Certificados.

        Figura 44.7. Ver Certificados en Privacidad y Seguridad

        view certificates
      • En la pestaña Authorities, haga clic en Importar. Localice y abra el certificado CA que guardó en el paso anterior en el archivo CertificateAuthority.crt. Confíe en el certificado para identificar los sitios web y, a continuación, haga clic en Aceptar y en OK.
  5. Continúe con Autenticación en la interfaz web de gestión de identidades con un certificado como usuario de gestión de identidades.

44.5. Autenticación en la interfaz web de gestión de identidades con un certificado como usuario de gestión de identidades

Este procedimiento describe la autenticación como usuario en la interfaz web de Gestión de identidades (IdM) utilizando un certificado almacenado en el escritorio de un cliente de Gestión de identidades.

Procedimiento

  1. En el navegador, navegue hasta la interfaz web de Gestión de Identidades en, por ejemplo, https://server.idm.example.com/ipa/ui.
  2. Haga clic en Login Using Certificate.

    .Inicio de sesión mediante certificado en la interfaz web de gestión de identidades

    smart card login
  3. El certificado del usuario ya debería estar seleccionado. Desmarque la opción Recordar esta decisión y haga clic en Aceptar.

Ahora está autenticado como el usuario que corresponde al certificado.

Recursos adicionales

  • Para obtener información sobre la autenticación en la interfaz web de IdM mediante un certificado almacenado en una tarjeta inteligente, consulte

44.6. Configuración de un cliente IdM para permitir la autenticación en la CLI mediante un certificado

Para que la autenticación por certificado funcione para un usuario de IdM en la interfaz de línea de comandos (CLI) de su cliente de IdM, importe el certificado del usuario de IdM y la clave privada al cliente de IdM. Para obtener detalles sobre la creación y la transferencia del certificado de usuario, consulte Sección 44.2, “Solicitar un nuevo certificado de usuario y exportarlo al cliente”.

Procedimiento

  • Inicie sesión en el cliente IdM y tenga listo el archivo .p12 que contiene el certificado del usuario y la clave privada. Para obtener y almacenar en caché el ticket de concesión de tickets (TGT) de Kerberos, ejecute el comando kinit con la entidad de seguridad del usuario, utilizando la opción -X con el atributo X509_username:/path/to/file.p12 para especificar dónde encontrar la información de identidad X509 del usuario. Por ejemplo, para obtener el TGT para idm_user utilizando la información de identidad del usuario almacenada en el archivo ~/idm_user.p12:

    $ kinit -X X509_idm_user='PKCS12:~/idm_user.p12' idm_user
    Nota

    El comando también admite el formato de archivo .pem kinit -X X509_username='FILE:/path/to/cert.pem,/path/to/key' user_principal

Capítulo 45. Uso del maestro de renovación de la CA de IdM

45.1. Explicación del maestro de renovación de CA de IdM

En un despliegue de gestión de identidades (IdM) que utiliza una autoridad de certificación (CA) integrada, el servidor maestro de renovación de CA mantiene y renueva los certificados del sistema IdM. Garantiza que los despliegues de IdM no se interrumpan.

Los certificados del sistema IdM incluyen:

  • IdM CA certificado
  • OCSP certificado de firma
  • IdM CA subsystem certificados
  • IdM CA audit signing certificado
  • IdM renewal agent (RA) certificado
  • KRA certificados de transporte y almacenamiento

Lo que caracteriza a los certificados del sistema es que sus claves son compartidas por todas las réplicas de la CA. En cambio, los certificados de servicio IdM (por ejemplo, los certificados LDAP, HTTP y PKINIT ), tienen pares de claves y nombres de sujetos diferentes en distintos servidores de CA IdM.

En la topología de IdM, por defecto, el primer servidor maestro de CA de IdM es el maestro de renovación de CA.

Nota

En la documentación de los usuarios, la CA de IdM se denomina Dogtag.

El papel del servidor maestro de renovación de CA

Los certificados IdM CA, IdM CA subsystem, y IdM RA son cruciales para el despliegue de IdM. Cada certificado se almacena en una base de datos NSS en el directorio /etc/pki/pki-tomcat/ y también como una entrada de la base de datos LDAP. El certificado almacenado en LDAP debe coincidir con el certificado almacenado en la base de datos NSS. Si no coinciden, se producen fallos de autenticación entre el marco de trabajo de IdM y la CA de IdM, y entre la CA de IdM y LDAP.

Todas las réplicas de IdM CA tienen solicitudes de seguimiento para cada certificado de sistema. Si una implementación de IdM con CA integrada no contiene un maestro de renovación de CA, cada servidor de CA de IdM solicita la renovación de los certificados del sistema de forma independiente. Esto da lugar a que diferentes réplicas de CA tengan varios certificados de sistema y se produzcan fallos de autenticación.

La designación de una réplica de CA como maestro de renovación permite que los certificados del sistema se renueven exactamente una vez, cuando sea necesario, y así se evitan los fallos de autenticación.

El papel de certmonger en las réplicas de CA

El servicio certmonger que se ejecuta en todas las réplicas de CA de IdM utiliza el ayudante de renovación dogtag-ipa-ca-renew-agent para realizar un seguimiento de los certificados del sistema IdM. El programa de ayuda a la renovación lee la configuración del maestro de renovación de la CA. En cada réplica de la CA que no es el maestro de renovación de la CA, el programa de ayuda a la renovación recupera los últimos certificados del sistema de las entradas LDAP de ca_renewal. Debido a la falta de determinación de cuándo se producen exactamente los intentos de renovación de certmonger, el ayudante de renovación dogtag-ipa-ca-renew-agent a veces intenta actualizar un certificado de sistema antes de que el maestro de renovación de CA haya renovado realmente el certificado. Si esto ocurre, el certificado antiguo, que pronto expirará, se devuelve a certmonger en la réplica de la CA. El certmonger, al darse cuenta de que es el mismo certificado que ya está almacenado en su base de datos, sigue intentando renovar el certificado con cierto retraso entre los intentos individuales hasta que pueda recuperar el certificado actualizado del maestro de renovación de la CA.

El correcto funcionamiento del maestro de renovación de IdM CA

Un despliegue de IdM con una CA incrustada es un despliegue de IdM que se instaló con una CA de IdM, o cuyo servidor maestro de CA de IdM se instaló posteriormente. Una implementación de IdM con una CA integrada debe tener en todo momento exactamente una réplica de CA configurada como maestro de renovación. El servidor maestro de renovación debe estar en línea y en pleno funcionamiento, y debe replicarse correctamente con los demás servidores.

Si se elimina el servidor maestro de renovación de CA actual mediante los comandos ipa server-del, ipa-replica-manage del, ipa-csreplica-manage del o ipa-server-install --uninstall, se asigna automáticamente una réplica de CA como servidor maestro de renovación de CA. Esta política garantiza que la configuración del maestro de renovación siga siendo válida.

Esta póliza no cubre las siguientes situaciones:

  • Offline renewal master

    • Si el maestro de renovación está fuera de línea durante un período prolongado, puede perder una ventana de renovación. En esta situación, todos los servidores maestros de no renovación siguen reinstalando los certificados del sistema actual hasta que los certificados caducan. Cuando esto ocurre, el despliegue de IdM se ve interrumpido porque incluso un certificado caducado puede provocar fallos en la renovación de otros certificados. Para evitar esta situación: si su maestro de renovación actual está fuera de línea y no está disponible durante un período de tiempo prolongado, considere la posibilidad de asignar un nuevo maestro de renovación de CA manualmente.
  • Replication problems

    • Si existen problemas de replicación entre el maestro de renovación y otras réplicas de CA, la renovación podría tener éxito, pero las otras réplicas de CA podrían no ser capaces de recuperar los certificados actualizados antes de que caduquen. Para evitar esta situación, asegúrese de que los acuerdos de replicación funcionan correctamente. Para obtener más detalles, consulte las directrices generales o específicas de solución de problemas de replicación en RHEL 7 Linux Domain Identity, Authentication, and Policy Guide.

45.2. Cambio y restablecimiento del maestro de renovación de la CA de IdM

Cuando se da de baja una autoridad de certificación (CA) maestra de renovación, Identity Management (IdM) selecciona automáticamente una nueva CA maestra de renovación de la lista de servidores de CA de IdM. El administrador del sistema no puede influir en la selección.

Para poder seleccionar el nuevo servidor maestro de renovación de IdM CA, el administrador del sistema debe realizar la sustitución manualmente. Seleccione el maestro antes de iniciar el proceso de desmantelamiento del maestro de renovación actual.

Si la configuración actual del maestro de renovación de CA no es válida, reinicie el maestro de renovación de CA de IdM.

Complete este procedimiento para cambiar o restablecer el maestro de renovación de CA.

Requisitos previos

  • Tienes las credenciales de administrador de IdM.

Procedimiento

  1. Obtenga las credenciales del administrador de IdM:

    ~]$ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  2. Opcionalmente, para averiguar qué servidores IdM de la implantación tienen la función de CA necesaria para poder convertirse en el nuevo maestro de renovación de CA:

    ~]$ ipa server-role-find --role 'CA server'
    ----------------------
    2 server roles matched
    ----------------------
      Server name: server.idm.example.com
      Role name: CA server
      Role status: enabled
    
      Server name: replica.idm.example.com
      Role name: CA server
      Role status: enabled
    ----------------------------
    Number of entries returned 2
    ----------------------------

    Hay dos servidores CA en el despliegue.

  3. Opcionalmente, para saber qué servidor de CA es el actual maestro de renovación de CA, introduzca:

    ~]$ ipa config-show | grep 'CA renewal master'
      IPA CA renewal master: server.idm.example.com

    El actual maestro de la renovación es server.idm.example.com.

  4. Para cambiar la configuración del maestro de renovación, utilice la utilidad ipa config-mod con la opción --ca-renewal-master-server:

    ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com | grep 'CA renewal master'
      IPA CA renewal master: replica.idm.example.com
    Importante

    También puede cambiar a un nuevo maestro de renovación de CA utilizando:

    • el comando ipa-cacert-manage --renew. Este comando renueva el certificado de la CA and y convierte al servidor de la CA en el que se ejecuta el comando en el nuevo maestro de renovación de la CA.
    • el comando ipa-cert-fix. Este comando recupera el despliegue cuando los certificados caducados están causando fallos. También hace que el servidor de CA en el que se ejecuta el comando sea el nuevo maestro de renovación de CA.

      Para obtener más información, consulte Renovación de certificados de sistema caducados cuando el IdM está desconectado.

45.3. Cambio de una CA externa a una autofirmada en IdM

Complete este procedimiento para cambiar de un certificado firmado externamente a un certificado autofirmado de la autoridad de certificación (CA) de Gestión de Identidades (IdM). Con una CA autofirmada, la renovación del certificado de la CA se gestiona automáticamente: un administrador del sistema no necesita enviar una solicitud de firma de certificado (CSR) a una autoridad externa.

El cambio de una CA firmada externamente a una autofirmada sustituye sólo el certificado de la CA. Los certificados firmados por la CA anterior siguen siendo válidos y siguen en uso. Por ejemplo, la cadena de certificados para el certificado LDAP permanece sin cambios incluso después de haber cambiado a una CA autofirmada:

external_CA certificado > IdM CA certificado > LDAP certificado

Requisitos previos

  • Tiene acceso de root al maestro de renovación de la CA de IdM.
  • Tienes las credenciales de administrador de IdM.

Procedimiento

  1. En el maestro de renovación de CA de IdM, renueve el certificado de CA como autofirmado:

    ~]# ipa-cacert-manage renew --self-signed
    Renewing CA certificate, please wait
    CA certificate successfully renewed
    The ipa-cacert-manage command was successful
  2. En todos los servidores y clientes de IdM, actualice las bases de datos de certificados locales de IdM con los certificados del servidor:

    [client ~]$ kinit admin
    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  3. Opcionalmente, para comprobar si la actualización se ha realizado con éxito y el nuevo certificado de CA se ha añadido al archivo /etc/ipa/ca.crt:

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    La salida muestra que la actualización se ha realizado con éxito, ya que el nuevo certificado de CA aparece junto a los certificados de CA más antiguos.

45.4. Renovación del maestro de renovación de la CA de IdM con un certificado firmado externamente

Esta sección describe cómo renovar el certificado de autoridad de certificación (CA) de Identity Management (IdM) utilizando una CA externa para firmar la solicitud de firma de certificado (CSR). En esta configuración, su servidor de CA de IdM es una subCA de la CA externa. La CA externa puede ser, aunque no necesariamente, un servidor de certificados de Active Directory (AD CS).

Si la autoridad de certificación externa es AD CS, puede especificar la plantilla que desea para el certificado de CA IdM en la CSR. Una plantilla de certificado define las políticas y reglas que una CA utiliza cuando se recibe una solicitud de certificado. Las plantillas de certificado en AD se corresponden con los perfiles de certificado en IdM.

Puede definir una plantilla específica de AD CS por su identificador de objeto (OID). Los OID son valores numéricos únicos emitidos por varias autoridades emisoras para identificar de forma exclusiva elementos de datos, sintaxis y otras partes de las aplicaciones distribuidas.

También puede definir una plantilla específica de AD CS por su nombre. Por ejemplo, el nombre del perfil predeterminado utilizado en una CSR enviada por una CA IdM a un CS AD es subCA.

Para definir un perfil especificando su OID o nombre en el CSR, utilice la opción external-ca-profile. Para más detalles, consulte la página man ipa-cacert-manage.

Además de utilizar una plantilla de certificado ya preparada, también puede crear una plantilla de certificado personalizada en el CS de AD y utilizarla en la CSR.

Requisitos previos

  • Tiene acceso de root al maestro de renovación de la CA de IdM.
  • Tienes las credenciales de administrador de IdM.

Procedimiento

Realice este procedimiento para renovar el certificado de la CA de IdM con firma externa, independientemente de si el certificado actual de la CA está autofirmado o firmado externamente.

  1. Cree un CSR para enviarlo a la CA externa:

    • Si la CA externa es un CS de AD, utilice la opción --external-ca-type=ms-cs. Si desea una plantilla diferente a la predeterminada subCA, especifíquela utilizando la opción --external-ca-profile:

      ~]# ipa-cacert-manage renew --external-ca --external-ca-type=ms-cs [--external-ca-profile=PROFILE]
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful
    • Si la CA externa no es un CS de AD:

      ~]# ipa-cacert-manage renew --external-ca
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful

      La salida muestra que se ha creado un CSR y que está almacenado en el archivo /var/lib/ipa/ca.csr.

  2. Envíe el CSR ubicado en /var/lib/ipa/ca.csr a la CA externa. El proceso difiere en función del servicio que se vaya a utilizar como CA externa.
  3. Recupera el certificado emitido y la cadena de certificados de la CA emisora en un blob codificado en base 64, que es:

    • un archivo PEM si la CA externa no es un CS de AD.
    • un certificado Base_64 si la CA externa es un AD CS.

      El proceso difiere para cada servicio de certificados. Normalmente, un enlace de descarga en una página web o en el correo electrónico de notificación permite al administrador descargar todos los certificados necesarios.

      Si la CA externa es un AD CS y ha enviado la CSR con una plantilla conocida a través de la ventana de gestión de autoridades de certificación de Microsoft Windows, el AD CS emite el certificado inmediatamente y aparece el diálogo Guardar certificado en la interfaz web del AD CS, preguntando dónde guardar el certificado emitido.

  4. Ejecute de nuevo el comando ipa-cacert-manage renew, añadiendo todos los archivos de certificados de CA necesarios para suministrar una cadena de certificados completa. Especifique tantos archivos como necesite, utilizando la opción --external-cert-file varias veces:

    ~]# ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate_1 --external-cert-file=/path/to/external_ca_certificate_2
  5. En todos los servidores y clientes de IdM, actualice las bases de datos de certificados locales de IdM con los certificados del servidor:

    [client ~]$ kinit admin
    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  6. Opcionalmente, para comprobar si la actualización se ha realizado con éxito y el nuevo certificado de CA se ha añadido al archivo /etc/ipa/ca.crt:

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    La salida muestra que la actualización se ha realizado con éxito, ya que el nuevo certificado de CA aparece junto a los certificados de CA más antiguos.

Capítulo 46. Renovación de certificados de sistema caducados cuando el IdM está desconectado

Cuando un certificado de sistema ha caducado, Identity Management (IdM) no se inicia. IdM soporta la renovación de los certificados del sistema cuando IdM está fuera de línea utilizando la herramienta ipa-cert-fix.

Requisitos previos

  • IdM sólo se instala en Red Hat Enterprise Linux 8.1 o posterior

46.1. Renovación de certificados de sistema caducados en una CA Renewal Master

Esta sección describe cómo aplicar la herramienta ipa-cert-fix en certificados IdM caducados.

Importante

Si ejecuta la herramienta ipa-cert-fix en un host de CA (autoridad de certificación) que no es el maestro de renovación de CA, y la utilidad renueva los certificados compartidos, ese host se convierte automáticamente en el nuevo maestro de renovación de CA en el dominio. Siempre debe haber un único CA Renewal Master en el dominio para evitar incoherencias.

Requisitos previos

  • Inicie sesión en el servidor con derechos de administración

Procedimiento

  1. Inicie la herramienta ipa-cert-fix para analizar el sistema y listar los certificados caducados que requieren renovación:

    # ipa-cert-fix
    ...
    The following certificates will be renewed:
    
    Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  13
      Expires: 2019-05-12 05:55:47
    ...
    Enter "yes" to proceed:
  2. Introduzca yes para iniciar el proceso de renovación:

    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  268369925
      Expires: 2021-08-14 02:19:33
    ...
    
    Becoming renewal master.
    The ipa-cert-fix command was successful

    Puede pasar hasta un minuto antes de que ipa-cert-fix renueve todos los certificados caducados.

  3. Opcionalmente, verifique que todos los servicios están ahora en funcionamiento:

    # ipactl status
    Directory Service: RUNNING
    krb5kdc Service: RUNNING
    kadmin Service: RUNNING
    httpd Service: RUNNING
    ipa-custodia Service: RUNNING
    pki-tomcatd Service: RUNNING
    ipa-otpd Service: RUNNING
    ipa: INFO: The ipactl command was successful

En este punto, los certificados han sido renovados y los servicios están funcionando. El siguiente paso es comprobar otros servidores en el dominio IdM.

46.2. Verificación de otros servidores IdM en el dominio IdM después de la renovación

Después de la renovación de los certificados del CA Renewal Master con la herramienta ipa-cert-fix, debe:

  • Reinicie todos los demás servidores de gestión de identidades (IdM) del dominio.
  • Compruebe si certmonger renovó los certificados.
  • Si hay otras réplicas de Autoridades de Certificación (CA) con certificados de sistema caducados, renueve también esos certificados con la herramienta ipa-cert-fix.

Requisitos previos

  • Inicie sesión en el servidor con derechos de administración.

Procedimiento

  1. Reinicie IdM con el parámetro --force:

    # ipactl restart --force

    Con el parámetro --force, la utilidad ipactl ignora los fallos de inicio de servicios individuales. Por ejemplo, si el servidor es también una CA con certificados caducados, el servicio pki-tomcat no se inicia. Esto es esperado e ignorado por el uso del parámetro --force.

  2. Tras el reinicio, compruebe que el servicio certmonger ha renovado los certificados (el estado del certificado dice MONITORING):

    # getcert list | egrep '^Request|status:|subject:'
    Request ID '20190522120745':
            status: MONITORING
            subject: CN=IPA RA,O=EXAMPLE.COM 201905222205
    Request ID '20190522120834':
            status: MONITORING
            subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205
    ...

    Puede pasar algún tiempo antes de que certmonger renueve los certificados compartidos en la réplica.

  3. Si el servidor es también una CA, el comando anterior informa CA_UNREACHABLE para el certificado que utiliza el servicio pki-tomcat:

    Request ID '20190522120835':
            status: CA_UNREACHABLE
            subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
    ...
  4. Para renovar este certificado, utilice la utilidad ipa-cert-fix:

    # ipa-cert-fix
    Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM
      Serial:  3
      Expires: 2019-05-11 12:07:11
    
    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
      Serial:  15
      Expires: 2019-08-14 04:25:05
    
    The ipa-cert-fix command was successful

Ahora, todos los certificados IdM han sido renovados y funcionan correctamente.

Capítulo 47. Generación de CRL en el servidor IdM CA

Si su implementación de IdM utiliza una autoridad de certificación (CA) integrada, es posible que tenga que trasladar la generación de la lista de revocación de certificados (CRL) de un servidor de gestión de identidades (IdM) a otro. Puede ser necesario, por ejemplo, cuando quiera migrar el servidor a otro sistema.

Sólo un servidor debe generar CRL. La función de generación de CRL suele coincidir con el maestro de renovación de CA de IdM, pero esto no es obligatorio. Antes de retirar el maestro de generación de CRL, el administrador debe seleccionar y configurar un nuevo maestro de generación de CRL.

Este capítulo describe:

  • Detener la generación de CRL en el maestro de IdM.
  • Comenzando a generar CRL en la réplica de IdM.

47.1. Detener la generación de CRL en un servidor IdM

Para dejar de generar la lista de revocación de certificados (CRL) en el servidor editor de CRL de IdM, utilice el comando ipa-crlgen-manage. Antes de desactivar la generación, verifique que el servidor realmente genera CRL. A continuación, puede deshabilitarla.

Requisitos previos

  • El servidor de gestión de identidades (IdM) está instalado en el sistema RHEL 8.1 o más reciente.
  • Debes estar conectado como root.

Procedimiento

  1. Compruebe si su servidor está generando la CRL:

    [root@server ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:00:00
    Last CRL Number: 6
    The ipa-crlgen-manage command was successful
  2. Dejar de generar la CRL en el servidor:

    [root@server ~]# ipa-crlgen-manage disable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
    The ipa-crlgen-manage command was successful
  3. Compruebe si el servidor ha dejado de generar CRL:

    [root@server ~]# ipa-crlgen-manage status

El servidor ha dejado de generar la CRL. El siguiente paso es habilitar la generación de CRL en el nuevo servidor RHEL 8.

47.2. Iniciar la generación de CRL en un servidor de réplica de IdM

Puede comenzar a generar la lista de revocación de certificados (CRL) en un servidor de CA de IdM con el comando ipa-crlgen-manage.

Requisitos previos

  • El servidor de gestión de identidades (IdM) está instalado en el sistema RHEL 8.1 o más reciente.
  • El sistema RHEL debe ser un servidor de autoridad de certificación IdM.
  • Debes estar conectado como root.

Procedimiento

  1. Comience a generar la CRL:

    [root@replica1 ~]# ipa-crlgen-manage enable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    Forcing CRL update
    CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
    The ipa-crlgen-manage command was successful
  2. Compruebe si se ha generado la CRL:

    [root@replica1 ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:10:00
    Last CRL Number: 7
    The ipa-crlgen-manage command was successful

Capítulo 48. Obtención de un certificado IdM para un servicio mediante certmonger

48.1. Resumen de Certmonger

Qué hace certmonger

Cuando la Gestión de Identidades (IdM) se instala con una Autoridad de Certificados (CA) IdM integrada, utiliza el servicio certmonger para rastrear y renovar los certificados de sistema y de servicio. Cuando el certificado está llegando a su fecha de caducidad, certmonger gestiona el proceso de renovación mediante:

  • regenerar una solicitud de firma de certificado (CSR) utilizando las opciones proporcionadas en la solicitud original.
  • enviando la CSR a la CA de IdM mediante el comando de la API de IdM cert-request.
  • recibir el certificado de la CA IdM.
  • ejecutando un comando de pre-salvado si se especifica en la solicitud original.
  • instalar el nuevo certificado en la ubicación especificada en la solicitud de renovación: en una base de datos NSS o en un archivo.
  • ejecutar un comando post-save si se especifica en la solicitud original. Por ejemplo, el comando post-save puede indicar a certmonger que reinicie un servicio relevante, para que el servicio recoja el nuevo certificado.

Tipos de certificados certmonger pistas

Los certificados pueden dividirse en certificados de sistema y de servicio.

A diferencia de los certificados de servicio (por ejemplo, para HTTP, LDAP y PKINIT), que tienen diferentes pares de claves y nombres de asunto en diferentes servidores, los certificados de sistema IdM y sus claves son compartidos por todas las réplicas de CA. Los certificados del sistema IdM incluyen:

  • IdM CA certificado
  • OCSP certificado de firma
  • IdM CA subsystem certificados
  • IdM CA audit signing certificado
  • IdM renewal agent (RA) certificado
  • KRA certificados de transporte y almacenamiento

El servicio certmonger realiza un seguimiento de los certificados del sistema IdM y de los servicios que se solicitaron durante la instalación del entorno IdM con una CA integrada. Certmonger también realiza un seguimiento de los certificados que ha solicitado manualmente el administrador del sistema para otros servicios que se ejecutan en el host IdM. Certmonger no realiza un seguimiento de los certificados de CA externas ni de los certificados de usuario.

Componentes de Certmonger

El servicio certmonger consta de dos componentes principales:

  • El certmonger daemon, que es el motor que rastrea la lista de certificados y lanza comandos de renovación
  • La utilidad getcert para el command-line interface (CLI), que permite al administrador del sistema enviar activamente comandos al demonio certmonger.

Más concretamente, el administrador del sistema puede utilizar la utilidad getcert para:

48.2. Obtención de un certificado IdM para un servicio mediante certmonger

Para garantizar que la comunicación entre los navegadores y el servicio web que se ejecuta en su cliente de gestión de identidades (IdM) sea segura y esté cifrada, utilice un certificado TLS. Obtenga el certificado TLS para su servicio web de la Autoridad de Certificación (CA) de IdM.

Esta sección describe cómo utilizar certmonger para obtener un certificado IdM para un servicio (HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM) que se ejecuta en un cliente IdM.

El uso de certmonger para solicitar el certificado de forma automática significa que certmonger gestiona y renueva el certificado cuando se debe renovar.

Para ver una representación visual de lo que ocurre cuando certmonger solicita un certificado de servicio, consulte Sección 48.3, “Flujo de comunicación para el certmonger que solicita un certificado de servicio”.

Requisitos previos

  • El servidor web se inscribe como cliente de IdM.
  • Tienes acceso de root al cliente IdM en el que estás ejecutando el procedimiento.
  • El servicio para el que se solicita un certificado no tiene por qué existir previamente en IdM.

Procedimiento

  1. En el cliente my_company.idm.example.com IdM en el que se ejecuta el servicio HTTP, solicite un certificado para el servicio correspondiente a la entidad de seguridad HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM y especifique que

    • El certificado debe almacenarse en el archivo local /etc/pki/tls/certs/httpd.pem
    • La clave privada debe almacenarse en el archivo local /etc/pki/tls/private/httpd.key
    • Que se añada una extensionRequest para un SubjectAltName a la solicitud de firma con el nombre DNS de my_company.idm.example.com:

      # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -C "systemctl restart httpd"
      New signing request "20190604065735" added.

      En el comando anterior:

      • El comando ipa-getcert request especifica que el certificado debe obtenerse de la CA de IdM. El comando ipa-getcert request es un atajo para getcert request -c IPA.
      • La opción -g especifica el tamaño de la clave que se generará si no existe ya una.
      • La opción -D especifica el valor DNS de SubjectAltName que se añadirá a la solicitud.
      • La opción -C indica a certmonger que reinicie el servicio httpd después de obtener el certificado.
      • Para especificar que el certificado se emita con un perfil determinado, utilice la opción -T.
      • Para solicitar un certificado utilizando el emisor nombrado de la CA especificada, utilice la opción -X ISSUER.
      Nota

      RHEL 8 utiliza un módulo SSL en Apache diferente al utilizado en RHEL 7. El módulo SSL se basa en OpenSSL y no en NSS. Por esta razón, en RHEL 8 no se puede utilizar una base de datos NSS para almacenar el certificado HTTPS y la clave privada.

  2. Opcionalmente, para comprobar el estado de su solicitud:

    # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
    Number of certificates and requests being tracked: 3.
    Request ID '20190604065735':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
        CA: IPA
    [...]

    La salida muestra que la solicitud está en el estado MONITORING, lo que significa que se ha obtenido un certificado. Las ubicaciones del par de claves y del certificado son las solicitadas.

48.3. Flujo de comunicación para el certmonger que solicita un certificado de servicio

Los diagramas de esta sección muestran las etapas de lo que ocurre cuando certmonger solicita un certificado de servicio al servidor de la autoridad de certificación (CA) de Gestión de Identidades (IdM). La secuencia consta de estos diagramas:

Figura 48.1, “Comunicación no encriptada” muestra la situación inicial: sin un certificado HTTPS, la comunicación entre el servidor web y el navegador no está cifrada.

Figura 48.1. Comunicación no encriptada

84 RHEL IdM 0420 1


Figura 48.2, “Certmonger solicita un certificado de servicio” muestra al administrador del sistema utilizando certmonger para solicitar manualmente un certificado HTTPS para el servidor web Apache. Tenga en cuenta que al solicitar un certificado de servidor web, certmonger no se comunica directamente con la CA. Lo hace a través de IdM.

Figura 48.2. Certmonger solicita un certificado de servicio

84 RHEL IdM 0420 2


Figura 48.3, “CA IdM que emite el certificado de servicio” muestra una CA IdM emitiendo un certificado HTTPS para el servidor web.

Figura 48.3. CA IdM que emite el certificado de servicio

84 RHEL IdM 0420 3


Figura 48.4, “Certmonger aplicando el certificado de servicio” muestra a certmonger colocando el certificado HTTPS en los lugares apropiados del cliente IdM y, si se le indica, reiniciando el servicio httpd. Posteriormente, el servidor Apache utiliza el certificado HTTPS para cifrar el tráfico entre él y el navegador.

Figura 48.4. Certmonger aplicando el certificado de servicio

84 RHEL IdM 0420 4


Figura 48.5, “Certmonger solicita un nuevo certificado cuando el antiguo está a punto de caducar” muestra certmonger solicitando automáticamente la renovación del certificado de servicio a la CA IdM antes de la expiración del certificado. La CA IdM emite un nuevo certificado.

Figura 48.5. Certmonger solicita un nuevo certificado cuando el antiguo está a punto de caducar

84 RHEL IdM 0420 5


48.4. Ver los detalles de una solicitud de certificado rastreada por certmonger

El servicio certmonger controla las solicitudes de certificados. Cuando una solicitud de certificado se firma con éxito, se obtiene un certificado. Certmonger gestiona las solicitudes de certificado, incluidos los certificados resultantes. Esta sección describe cómo ver los detalles de una solicitud de certificado concreta gestionada por certmonger.

Procedimiento

  • Si sabe cómo especificar la solicitud de certificado, enumere los detalles de sólo esa solicitud de certificado en particular. Puede, por ejemplo, especificar:

    • El ID de la solicitud
    • La ubicación del certificado
    • El apodo del certificado

      Por ejemplo, para ver los detalles del certificado cuyo ID de solicitud es 20190408143846, utilizando la opción -v para ver todos los detalles de los errores en caso de que su solicitud de un certificado no haya tenido éxito:

      # getcert list -i 20190408143846 -v
      Number of certificates and requests being tracked: 16.
      Request ID '20190408143846':
      	status: MONITORING
      	stuck: no
      	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt'
      	certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB'
      	CA: IPA
      	issuer: CN=Certificate Authority,O=IDM.EXAMPLE.COM
      	subject: CN=r8server.idm.example.com,O=IDM.EXAMPLE.COM
      	expires: 2021-04-08 16:38:47 CEST
      	dns: r8server.idm.example.com
      	principal name: ldap/server.idm.example.com@IDM.EXAMPLE.COM
      	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
      	eku: id-kp-serverAuth,id-kp-clientAuth
      	pre-save command:
      	post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IDM-EXAMPLE-COM
      	track: yes
      	auto-renew: yes

    La salida muestra varios datos sobre el certificado, por ejemplo:

    • la ubicación del certificado; en el ejemplo anterior, es la base de datos NSS en el directorio /etc/dirsrv/slapd-IDM-EXAMPLE-COM
    • el apodo del certificado; en el ejemplo anterior, es Server-Cert
    • el archivo que almacena el pin; en el ejemplo anterior, es /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt
    • la Autoridad de Certificación (CA) que se utilizará para renovar el certificado; en el ejemplo anterior, es la CA IPA
    • la fecha de caducidad; en el ejemplo anterior, es 2021-04-08 16:38:47 CEST
    • el estado del certificado; en el ejemplo anterior, el estado MONITORING significa que el certificado es válido y está siendo rastreado
    • el comando post-save; en el ejemplo anterior, es el reinicio del servicio LDAP
  • Si no sabe cómo especificar la solicitud de certificado, enumere los detalles de todos los certificados que certmonger está supervisando o intentando obtener:

    # getcert list

Información adicional

  • Para ver las diferentes opciones de cómo especificar la solicitud de certificado que se muestra, consulte la página man getcert list.

48.5. Iniciar y detener el seguimiento de certificados

Esta sección describe cómo puede utilizar los comandos getcert stop-tracking y getcert start-tracking para supervisar los certificados. Los dos comandos son proporcionados por el servicio certmonger. Activar el seguimiento de certificados es especialmente útil si ha importado un certificado emitido por la autoridad de certificación (CA) de Gestión de identidades (IdM) en la máquina desde un cliente IdM diferente. Activar el seguimiento de certificados también puede ser el último paso del siguiente escenario de aprovisionamiento:

  1. En el servidor IdM, se crea un certificado para un sistema que aún no existe.
  2. Crea el nuevo sistema.
  3. Se inscribe el nuevo sistema como cliente de IdM.
  4. Importa el certificado y la clave del servidor IdM al cliente IdM.
  5. Se inicia el seguimiento del certificado a través de certmonger para asegurarse de que se renueva cuando expira.

Procedimiento

  • Para desactivar la supervisión de un certificado con el ID de solicitud de 20190408143846:

    # getcert stop-tracking -i 20190408143846

    Para más opciones, consulte la página de manual getcert stop-tracking.

  • Para permitir la supervisión de un certificado almacenado en el archivo /tmp/some_cert.crt, cuya clave privada está almacenada en el archivo /tmp/some_key.key:

    # getcert start-tracking -c IPA -f /tmp/some_cert.crt -k /tmp/some_key.key

    Certmonger no puede identificar automáticamente el tipo de CA que emitió el certificado. Por este motivo, añada la opción -c con el valor IPA al comando getcert start-tracking si el certificado fue emitido por la CA IdM. Si no se añade la opción -c, certmonger entra en el estado NEED_CA.

    Para más opciones, consulte la página de manual getcert start-tracking.

Nota

Los dos comandos no manipulan el certificado. Por ejemplo, getcert stop-tracking no borra el certificado ni lo elimina de la base de datos del NSS o del sistema de archivos, sino que simplemente lo elimina de la lista de certificados supervisados. Del mismo modo, getcert start-tracking sólo añade un certificado a la lista de certificados supervisados.

48.6. Renovar un certificado manualmente

Cuando un certificado está cerca de su fecha de caducidad, el demonio certmonger emite automáticamente un comando de renovación utilizando el ayudante de la autoridad de certificación (CA), obtiene un certificado renovado y sustituye el certificado anterior por el nuevo.

También es posible renovar manualmente un certificado por adelantado utilizando el comando getcert resubmit. De este modo, se puede actualizar la información que contiene el certificado, por ejemplo, añadiendo un nombre alternativo del sujeto (SAN).

Esta sección describe cómo renovar un certificado manualmente.

Procedimiento

  • Para renovar un certificado con el ID de solicitud de 20190408143846:

    # getcert resubmit -i 20190408143846

    Para obtener el ID de solicitud de un certificado específico, utilice el comando getcert list. Para más detalles, consulte la página de manual getcert list.

48.7. Hacer que certmonger reanude el seguimiento de los certificados IdM en una réplica de CA

Este procedimiento muestra cómo hacer que certmonger reanude el seguimiento de los certificados del sistema de gestión de identidades (IdM) que son cruciales para una implementación de IdM con una autoridad de certificación integrada después de que el seguimiento de los certificados se haya interrumpido. La interrupción puede deberse a que el host IdM se haya desinscrito de IdM durante la renovación de los certificados del sistema o a que la topología de replicación no funcione correctamente. El procedimiento también muestra cómo hacer que certmonger reanude el seguimiento de los certificados de servicio IdM, es decir, los certificados HTTP, LDAP y PKINIT.

Requisitos previos

  • El host en el que se desea reanudar el seguimiento de los certificados del sistema es un servidor IdM que también es una autoridad de certificación (CA) IdM, pero no el maestro de renovación de la CA IdM.

Procedimiento

  1. Obtenga el PIN de los certificados CA del subsistema:

    # grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
  2. Añade el seguimiento a los certificados CA del subsistema, sustituyendo [internal PIN] en los comandos de abajo por el PIN obtenido en el paso anterior:

    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"'
  3. Añade el seguimiento de los certificados IdM restantes, los certificados HTTP, LDAP, IPA renewal agent y PKINIT:

    # getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/idm.example.com-443-RSA -c IPA -C /usr/libexec/ipa/certmonger/restart_httpd
    
    # getcert start-tracking -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM -n "Server-Cert" -c IPA -p /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt -C '/usr/libexec/ipa/certmonger/restart_dirsrv "IDM-EXAMPLE-COM"'
    
    # getcert start-tracking -f /var/lib/ipa/ra-agent.pem -k /var/lib/ipa/ra-agent.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_ra_cert
    
    # getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -k /var/kerberos/krb5kdc/kdc.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_kdc_cert
  4. Reiniciar certmonger:

    # systemctl restart certmonger
  5. Espere un minuto después del inicio de certmonger y compruebe el estado de los nuevos certificados:

    # getcert list

Recursos adicionales

  • Si todos los certificados del sistema IdM han caducado, siga el procedimiento descrito en esta solución de soporte centrado en el conocimiento ( KCS) para renovar manualmente los certificados del sistema IdM en el maestro de CA IdM que también es el maestro de renovación de CA y el maestro de generación de CRL. A continuación, siga el procedimiento descrito en esta solución KCS para renovar manualmente los certificados del sistema IdM en todos los demás servidores de CA de la topología.

Capítulo 49. Solicitud de certificados mediante RHEL System Roles

Con la función de sistema de certificados, puede utilizar Red Hat Ansible Engine para emitir y gestionar certificados.

Este capítulo abarca los siguientes temas:

49.1. La función del sistema de certificados

Utilizando el rol de sistema de certificados, puede gestionar la emisión y renovación de certificados TLS y SSL utilizando Red Hat Ansible Engine.

El rol utiliza certmonger como proveedor de certificados, y actualmente soporta la emisión y renovación de certificados autofirmados y el uso de la autoridad de certificados (CA) integrada en IdM.

Puede utilizar las siguientes variables en su libro de jugadas de Ansible con la función de sistema de certificados:

  • certificate_wait para especificar si la tarea debe esperar a que se emita el certificado.
  • certificate_requests para representar cada certificado a emitir y sus parámetros.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en la variable certificate_requests e información adicional sobre la función del sistema certificate, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para más detalles sobre los Roles de Sistema de RHEL y cómo aplicarlos, vea Introducción a los Roles de Sistema de RHEL.

49.2. Solicitud de un nuevo certificado autofirmado mediante la función de sistema de certificados

Con la función de sistema de certificados, puede utilizar Red Hat Ansible Engine para emitir certificados autofirmados.

Este proceso utiliza el proveedor certmonger y solicita el certificado a través del comando getcert.

Nota

Por defecto, certmonger intenta renovar automáticamente el certificado antes de que caduque. Puede desactivar esto estableciendo el parámetro auto_renew en el libro de jugadas de Ansible como no.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Ansible instalado en los sistemas en los que se desea desplegar la solución certificate.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.

    Para más detalles sobre los Roles de Sistema de RHEL y cómo aplicarlos, vea Introducción a los Roles de Sistema de RHEL.

Procedimiento

  1. Optional: Crear un archivo de inventario, por ejemplo inventory.file:

    $ touch inventario.archivo
  2. Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:

    [webserver]
    server.idm.example.com
  3. Cree un archivo de playbook, por ejemplo request-certificate.yml:

    • Configure hosts para incluir los hosts en los que desea solicitar el certificado, como por ejemplo webserver.
    • Establezca la variable certificate_requests para incluir lo siguiente:

      • Establezca el parámetro name con el nombre deseado para el certificado, como por ejemplo mycert.
      • Establezca el parámetro dns con el dominio que se incluirá en el certificado, como por ejemplo *.example.com.
      • Ajuste el parámetro ca a self-sign.
    • Establezca la función rhel-system-roles.certificate en roles.

      Este es el archivo del libro de jugadas para este ejemplo:

      ---
      - hosts: webserver
      
        vars:
          certificate_requests:
            - name: mycert
              dns: *.example.com
              ca: self-sign
      
        roles:
          - rhel-system-roles.certificate
  4. Guarda el archivo.
  5. Ejecuta el libro de jugadas:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en la variable certificate_requests e información adicional sobre la función del sistema certificate, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

49.3. Solicitud de un nuevo certificado a la CA de IdM mediante la función de sistema de certificados

Con la función de sistema de certificados, puede utilizar Red Hat Ansible Engine para emitir certificados mientras utiliza un servidor IdM con una autoridad de certificados (CA) integrada. Por lo tanto, puede gestionar de manera eficiente y consistente la cadena de confianza de certificados para múltiples sistemas cuando se utiliza IdM como CA.

Este proceso utiliza el proveedor certmonger y solicita el certificado a través del comando getcert.

Nota

Por defecto, certmonger intenta renovar automáticamente el certificado antes de que caduque. Puede desactivar esto estableciendo el parámetro auto_renew en el libro de jugadas de Ansible como no.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Ansible instalado en los sistemas en los que se desea desplegar la solución certificate.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.

    Para más detalles sobre los Roles de Sistema de RHEL y cómo aplicarlos, vea Introducción a los Roles de Sistema de RHEL.

Procedimiento

  1. Optional: Crear un archivo de inventario, por ejemplo inventory.file:

    $ touch inventario.archivo
  2. Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:

    [webserver]
    server.idm.example.com
  3. Cree un archivo de playbook, por ejemplo request-certificate.yml:

    • Configure hosts para incluir los hosts en los que desea solicitar el certificado, como por ejemplo webserver.
    • Establezca la variable certificate_requests para incluir lo siguiente:

      • Establezca el parámetro name con el nombre deseado para el certificado, como por ejemplo mycert.
      • Establezca el parámetro dns con el dominio que se incluirá en el certificado, como por ejemplo www.example.com.
      • Establezca el parámetro principal para especificar la entidad principal de Kerberos, como HTTP/www.example.com@EXAMPLE.COM.
      • Ajuste el parámetro ca a ipa.
    • Establezca la función rhel-system-roles.certificate en roles.

      Este es el archivo del libro de jugadas para este ejemplo:

      ---
      - hosts: webserver
        vars:
          certificate_requests:
            - name: mycert
              dns: www.example.com
              principal: HTTP/www.example.com@EXAMPLE.COM
              ca: ipa
      
        roles:
          - rhel-system-roles.certificate
  4. Guarda el archivo.
  5. Ejecuta el libro de jugadas:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en la variable certificate_requests e información adicional sobre la función del sistema certificate, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

49.4. Especificación de los comandos que se ejecutan antes o después de la emisión del certificado mediante la función de sistema de certificados

Con la función de sistema de certificados, puede utilizar Red Hat Ansible Engine para ejecutar un comando antes y después de la emisión o renovación de un certificado.

En el siguiente ejemplo, el administrador se asegura de detener el servicio httpd antes de que se emita o renueve un certificado autofirmado para www.example.com, y de reiniciarlo después.

Nota

Por defecto, certmonger intenta renovar automáticamente el certificado antes de que caduque. Puede desactivar esto estableciendo el parámetro auto_renew en el libro de jugadas de Ansible como no.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Ansible instalado en los sistemas en los que se desea desplegar la solución certificate.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.

    Para más detalles sobre los Roles de Sistema de RHEL y cómo aplicarlos, vea Introducción a los Roles de Sistema de RHEL.

Procedimiento

  1. Optional: Crear un archivo de inventario, por ejemplo inventory.file:

    $ touch inventario.archivo
  2. Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:

    [webserver]
    server.idm.example.com
  3. Cree un archivo de playbook, por ejemplo request-certificate.yml:

    • Configure hosts para incluir los hosts en los que desea solicitar el certificado, como por ejemplo webserver.
    • Establezca la variable certificate_requests para incluir lo siguiente:

      • Establezca el parámetro name con el nombre deseado para el certificado, como por ejemplo mycert.
      • Establezca el parámetro dns con el dominio que se incluirá en el certificado, como por ejemplo www.example.com.
      • Establezca el parámetro ca en la CA que desea utilizar para emitir el certificado, como por ejemplo self-sign.
      • Establezca el parámetro run_before con el comando que desea ejecutar antes de que se emita o renueve este certificado, como systemctl stop httpd.service.
      • Establezca el parámetro run_after con el comando que desea ejecutar después de que se emita o renueve este certificado, como systemctl start httpd.service.
    • Establezca la función rhel-system-roles.certificate en roles.

      Este es el archivo del libro de jugadas para este ejemplo:

      ---
      - hosts: webserver
        vars:
          certificate_requests:
            - name: mycert
              dns: www.example.com
              ca: self-sign
              run_before: systemctl stop httpd.service
              run_after: systemctl start httpd.service
      
        roles:
          - linux-system-roles.certificate
  4. Guarda el archivo.
  5. Ejecuta el libro de jugadas:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en la variable certificate_requests e información adicional sobre la función del sistema certificate, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

Capítulo 50. Restringir una aplicación para que confíe sólo en un subconjunto de certificados

Si su instalación de gestión de identidades (IdM) está configurada con la autoridad de certificación (CA) integrada del sistema de certificados (CS), podrá crear sub-CA ligeras. Todas las sub-CAs que cree están subordinadas a la CA principal del sistema de certificados, la CA ipa.

Un lightweight sub-CA en este contexto significa a sub-CA issuing certificates for a specific purpose. Por ejemplo, una CA secundaria ligera permite configurar un servicio, como una pasarela de red privada virtual (VPN) y un navegador web, para que sólo acepte certificados emitidos por sub-CA A. Al configurar otros servicios para que sólo acepten certificados emitidos por sub-CA B, se impide que acepten certificados emitidos por sub-CA A, la CA principal, es decir, la CA ipa, y cualquier sub-CA intermedia entre ambas.

Si se revoca el certificado intermedio de una sub-CA, todos los certificados emitidos por esta sub-CA se consideran automáticamente inválidos por los clientes correctamente configurados. Todos los demás certificados emitidos directamente por la CA raíz, ipa, u otra sub-CA, siguen siendo válidos.

Esta sección utiliza el ejemplo del servidor web Apache para ilustrar cómo restringir una aplicación para que confíe sólo en un subconjunto de certificados. Complete esta sección para restringir el servidor web que se ejecuta en su cliente de IdM para que utilice un certificado emitido por la sub-CA de IdM de webserver-ca, y para exigir a los usuarios que se autentiquen en el servidor web utilizando certificados de usuario emitidos por la sub-CA de IdM de webclient-ca.

Los pasos que debes dar son:

50.1. Creación de una sub-CA ligera

Para más detalles sobre la creación de una sub-CA, véase:

50.1.1. Creación de una sub-CA desde IdM WebUI

Este procedimiento describe cómo utilizar IdM WebUI para crear nuevas sub-CAs denominadas webserver-ca y webclient-ca.

Requisitos previos

  • Asegúrese de haber obtenido las credenciales del administrador.

Procedimiento

  1. En el menú Authentication, haga clic en Certificates.
  2. Seleccione Certificate Authorities y haga clic en Add.
  3. Introduzca el nombre de la sub-CA webserver-ca. Introduzca el DN del sujeto, por ejemplo CN=WEBSERVER,O=IDM.EXAMPLE.COM, en el campo DN del sujeto. Tenga en cuenta que el DN del sujeto debe ser único en la infraestructura de la CA de IdM.
  4. Introduzca el nombre de la sub-CA webclient-ca. Introduzca el DN del sujeto CN=WEBCLIENT,O=IDM.EXAMPLE.COM en el campo DN del sujeto.
  5. En la interfaz de línea de comandos, ejecute el comando ipa-certupdate para crear una solicitud de seguimiento de certmonger para los certificados de las sub-CAs webserver-ca y webclient-ca:

    [root@ipaserver ~]# ipa-certupdate
    Importante

    Si se olvida de ejecutar el comando ipa-certupdate después de crear una sub-CA, si el certificado de la sub-CA caduca, los certificados de entidad final emitidos por la sub-CA se consideran inválidos aunque el certificado de entidad final no haya caducado.

  6. Opcionalmente, para verificar que el certificado de firma de la nueva sub-CA se ha añadido a la base de datos de IdM, introduzca:

    [root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L
    
    Certificate Nickname                      Trust Attributes
                                              SSL,S/MIME,JAR/XPI
    
    caSigningCert cert-pki-ca                 CTu,Cu,Cu
    Server-Cert cert-pki-ca                   u,u,u
    auditSigningCert cert-pki-ca              u,u,Pu
    caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u
    ocspSigningCert cert-pki-ca               u,u,u
    subsystemCert cert-pki-ca                 u,u,u
    Nota

    El nuevo certificado sub-CA se transfiere automáticamente a todas las réplicas que tengan instalada una instancia del sistema de certificados.

50.1.2. Creación de una sub-CA desde la CLI de IdM

Este procedimiento describe cómo utilizar la CLI de IdM para crear nuevas sub-CAs denominadas webserver-ca y webclient-ca.

Requisitos previos

  • Asegúrese de haber obtenido las credenciales del administrador.
  • Asegúrese de que ha iniciado sesión en un servidor IdM que es un servidor CA.

Procedimiento

  1. Introduzca el comando ipa ca-add, y especifique el nombre de la sub-CA webserver-ca y su Nombre Distinguido del Sujeto (DN):

    [root@ipaserver ~]# ipa ca-add webserver-ca --subject="CN=WEBSERVER,O=IDM.EXAMPLE.COM"
    -------------------
    Created CA "webserver-ca"
    -------------------
      Name: webserver-ca
      Authority ID: ba83f324-5e50-4114-b109-acca05d6f1dc
      Subject DN: CN=WEBSERVER,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
    Nombre
    Nombre de la AC.
    Identificación de la autoridad
    Creada automáticamente, la identificación individual de la AC.
    Asunto DN
    Nombre distinguido del sujeto (DN). El DN del sujeto debe ser único en la infraestructura de la CA de IdM.
    DN del emisor
    CA principal que emitió el certificado de la sub-CA. Todas las sub-CAs se crean como hijas de la CA raíz de IdM.
  2. Cree la sub-CA webclient-ca para emitir certificados a los clientes web:

    [root@ipaserver ~]# ipa ca-add webclient-ca --subject="CN=WEBCLIENT,O=IDM.EXAMPLE.COM"
    -------------------
    Created CA "webclient-ca"
    -------------------
      Name: webclient-ca
      Authority ID: 8a479f3a-0454-4a4d-8ade-fd3b5a54ab2e
      Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
  3. En la interfaz de línea de comandos, ejecute el comando ipa-certupdate para crear una solicitud de seguimiento de certmonger para los certificados de las sub-CAs webserver-ca y webclient-ca:

    [root@ipaserver ~]# ipa-certupdate
    Importante

    Si se olvida de ejecutar el comando ipa-certupdate después de crear una sub-CA, si el certificado de la sub-CA caduca, los certificados de entidad final emitidos por la sub-CA se consideran inválidos aunque el certificado de entidad final no haya caducado.

  4. Opcionalmente, para verificar que el certificado de firma de la nueva sub-CA se ha añadido a la base de datos de IdM, introduzca:

    [root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L
    
    Certificate Nickname                      Trust Attributes
                                              SSL,S/MIME,JAR/XPI
    
    caSigningCert cert-pki-ca                 CTu,Cu,Cu
    Server-Cert cert-pki-ca                   u,u,u
    auditSigningCert cert-pki-ca              u,u,Pu
    caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u
    ocspSigningCert cert-pki-ca               u,u,u
    subsystemCert cert-pki-ca                 u,u,u
    Nota

    El nuevo certificado sub-CA se transfiere automáticamente a todas las réplicas que tengan instalada una instancia del sistema de certificados.

50.2. Descarga del certificado sub-CA desde IdM WebUI

Requisitos previos

  • Asegúrese de haber obtenido las credenciales del administrador de IdM.

Procedimiento

  1. En el menú Authentication, haga clic en Certificates > Certificates.

    Figura 50.1. certificado sub-CA en la lista de certificados

    download sub CA certificate
  2. Haga clic en el número de serie del certificado sub-CA para abrir la página de información del certificado.
  3. En la página de información del certificado, haga clic en Actions > Download.
  4. En la CLI, mueva el certificado sub-CA al directorio /etc/pki/tls/private/:

    # mv path/to/the/downloaded/certificate /etc/pki/tls/private/sub-ca.crt

50.3. Creación de ACLs de CA para la autenticación del servidor web y del cliente

Las reglas de la lista de control de acceso de la autoridad de certificación (CA ACL) definen qué perfiles pueden utilizarse para emitir certificados a qué usuarios, servicios o hosts. Al asociar perfiles, entidades de crédito y grupos, las ACL de CA permiten a las entidades de crédito o a los grupos solicitar certificados utilizando determinados perfiles.

Por ejemplo, utilizando las ACL, el administrador puede restringir el uso de un perfil destinado a los empleados que trabajan desde una oficina situada en Londres sólo a los usuarios que son miembros del grupo relacionado con la oficina de Londres.

50.3.1. Visualización de las ACL de CA en la CLI de IdM

Complete esta sección para ver la lista de listas de control de acceso de autoridades de certificación (CA ACL) disponibles en su implementación de IdM y los detalles de una CA ACL específica.

Procedimiento

  1. Para ver todas las ACL de su entorno IdM, introduzca el comando ipa caacl-find:

    $ ipa caacl-find
    -----------------
    1 CA ACL matched
    -----------------
      ACL name: hosts_services_caIPAserviceCert
      Enabled: TRUE
  2. Para ver los detalles de una CA ACL, introduzca el comando ipa caacl-show y especifique el nombre de la CA ACL. Por ejemplo, para ver los detalles de la ACL de CA hosts_services_caIPAserviceCert, introduzca:

    $ ipa caacl-show hosts_services_caIPAserviceCert
      ACL name: hosts_services_caIPAserviceCert
      Enabled: TRUE
      Host category: all
      Service category: all
      CAs: ipa
      Profiles: caIPAserviceCert
      Users: admin

50.3.2. Creación de una CA ACL para servidores web que se autentiquen ante clientes web utilizando certificados emitidos por webserver-ca

Esta sección describe cómo crear una ACL de CA que requiera que el administrador del sistema utilice la sub-CA webserver-ca y el perfil caIPAserviceCert cuando solicite un certificado para el servicio HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM. Si el usuario solicita un certificado de una sub-CA diferente o de un perfil diferente, la solicitud falla. La única excepción es cuando hay otra ACL de CA coincidente que está habilitada. Para ver las ACL de CA disponibles, consulte Visualización de las ACL de CA en la CLI de IdM.

Requisitos previos

  • Asegúrese de que el servicio HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM forma parte de IdM.
  • Asegúrate de haber obtenido las credenciales de administrador de IdM.

Procedimiento

  1. Cree una ACL de CA con el comando ipa caacl y especifique su nombre:

    $ ipa caacl-add TLS_web_server_authentication
    --------------------------------------------
    Added CA ACL "TLS_web_server_authentication"
    --------------------------------------------
      ACL name: TLS_web_server_authentication
      Enabled: TRUE
  2. Modifique la CA ACL utilizando el comando ipa caacl-mod para especificar la descripción de la CA ACL:

    $ ipa caacl-mod TLS_web_server_authentication --desc="CAACL for web servers authenticating to web clients using certificates issued by webserver-ca"
    -----------------------------------------------
    Modified CA ACL "TLS_web_server_authentication"
    -----------------------------------------------
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
  3. Añada la sub-CA webserver-ca a la ACL de la CA:

    $ ipa caacl-add-ca TLS_web_server_authentication --ca=webserver-ca
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
    -------------------------
    Number of members added 1
    -------------------------
  4. Utilice la dirección ipa caacl-add-service para especificar el servicio cuyo titular podrá solicitar un certificado:

    $ ipa caacl-add-service TLS_web_server_authentication --service=HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
      Services: HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
    -------------------------
    Number of members added 1
    -------------------------
  5. Utilice el comando ipa caacl-add-profile para especificar el perfil de certificado para el certificado solicitado:

    $ ipa caacl-add-profile TLS_web_server_authentication --certprofiles=caIPAserviceCert
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
      Profiles: caIPAserviceCert
      Services: HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
    -------------------------
    Number of members added 1
    -------------------------

    Puede utilizar la ACL recién creada inmediatamente. Se habilita por defecto tras su creación.

Nota

El objetivo de las ACL de CA es especificar qué combinaciones de CA y perfiles están permitidas para las solicitudes procedentes de determinados mandantes o grupos. Las ACL de CA no afectan a la validación de certificados ni a la confianza. No afectan a cómo se utilizarán los certificados emitidos.

50.3.3. Creación de una CA ACL para los navegadores web de los usuarios que se autentiquen en los servidores web utilizando certificados emitidos por webclient-ca

Esta sección describe cómo crear una ACL de CA que requiera que el administrador del sistema utilice la sub-CA webclient-ca y el perfil IECUserRoles cuando solicite un certificado. Si el usuario solicita un certificado de una sub-CA diferente o de un perfil diferente, la solicitud falla. La única excepción es cuando hay otra ACL de CA coincidente que está habilitada. Para ver las ACL de CA disponibles, consulte Visualización de las ACL de CA en la CLI de IdM.

Requisitos previos

  • Asegúrate de haber obtenido las credenciales de administrador de IdM.

Procedimiento

  1. Cree una ACL de CA con el comando ipa caacl y especifique su nombre:

    $ ipa caacl-add TLS_web_client_authentication
    --------------------------------------------
    Added CA ACL "TLS_web_client_authentication"
    --------------------------------------------
      ACL name: TLS_web_client_authentication
      Enabled: TRUE
  2. Modifique la CA ACL utilizando el comando ipa caacl-mod para especificar la descripción de la CA ACL:

    $ ipa caacl-mod TLS_web_client_authentication --desc="CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca"
    -----------------------------------------------
    Modified CA ACL "TLS_web_client_authentication"
    -----------------------------------------------
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
  3. Añada la sub-CA webclient-ca a la ACL de la CA:

    $ ipa caacl-add-ca TLS_web_client_authentication --ca=webclient-ca
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      CAs: webclient-ca
    -------------------------
    Number of members added 1
    -------------------------
  4. Utilice el comando ipa caacl-add-profile para especificar el perfil de certificado para el certificado solicitado:

    $ ipa caacl-add-profile TLS_web_client_authentication --certprofiles=IECUserRoles
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      CAs: webclient-ca
      Profiles: IECUserRoles
    -------------------------
    Number of members added 1
    -------------------------
  5. Modifique la ACL de CA mediante el comando ipa caacl-mod para especificar que la ACL de CA se aplica a todos los usuarios de IdM:

    $ ipa caacl-mod TLS_web_client_authentication --usercat=all
    -----------------------------------------------
    Modified CA ACL "TLS_web_client_authentication"
    -----------------------------------------------
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      User category: all
      CAs: webclient-ca
      Profiles: IECUserRoles

    Puede utilizar la ACL recién creada inmediatamente. Se habilita por defecto tras su creación.

Nota

El objetivo de las ACL de CA es especificar qué combinaciones de CA y perfiles están permitidas para las solicitudes procedentes de determinados mandantes o grupos. Las ACL de CA no afectan a la validación de certificados ni a la confianza. No afectan a cómo se utilizarán los certificados emitidos.

50.4. Obtención de un certificado IdM para un servicio mediante certmonger

Para garantizar que la comunicación entre los navegadores y el servicio web que se ejecuta en su cliente IdM sea segura y esté cifrada, utilice un certificado TLS. Si desea restringir los navegadores web para que confíen en los certificados emitidos por la sub-CA webserver-ca pero no en ninguna otra sub-CA de IdM, obtenga el certificado TLS para su servicio web de la sub-CA webserver-ca.

Esta sección describe cómo utilizar certmonger para obtener un certificado IdM para un servicio (HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM) que se ejecuta en un cliente IdM.

El uso de certmonger para solicitar el certificado de forma automática significa que certmonger gestiona y renueva el certificado cuando se debe renovar.

Para ver una representación visual de lo que ocurre cuando certmonger solicita un certificado de servicio, consulte Sección 50.5, “Flujo de comunicación para el certmonger que solicita un certificado de servicio”.

Requisitos previos

  • El servidor web se inscribe como cliente de IdM.
  • Tienes acceso de root al cliente IdM en el que estás ejecutando el procedimiento.
  • El servicio para el que se solicita un certificado no tiene por qué existir previamente en IdM.

Procedimiento

  1. En el cliente my_company.idm.example.com IdM en el que se ejecuta el servicio HTTP, solicite un certificado para el servicio correspondiente a la entidad de seguridad HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM y especifique que

    • El certificado debe almacenarse en el archivo local /etc/pki/tls/certs/httpd.pem
    • La clave privada debe almacenarse en el archivo local /etc/pki/tls/private/httpd.key
    • La sub-CA webserver-ca debe ser la autoridad de certificación emisora
    • Que se añada una extensionRequest para un SubjectAltName a la solicitud de firma con el nombre DNS de my_company.idm.example.com:

      # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -X webserver-ca -C "systemctl restart httpd"
      New signing request "20190604065735" added.

      En el comando anterior:

      • El comando ipa-getcert request especifica que el certificado debe obtenerse de la CA de IdM. El comando ipa-getcert request es un atajo para getcert request -c IPA.
      • La opción -g especifica el tamaño de la clave que se generará si no existe ya una.
      • La opción -D especifica el valor DNS de SubjectAltName que se añadirá a la solicitud.
      • La opción -X especifica que el emisor del certificado debe ser webserver-ca, no ipa.
      • La opción -C indica a certmonger que reinicie el servicio httpd después de obtener el certificado.
      • Para especificar que el certificado se emita con un perfil determinado, utilice la opción -T.
      Nota

      RHEL 8 utiliza un módulo SSL en Apache diferente al utilizado en RHEL 7. El módulo SSL se basa en OpenSSL y no en NSS. Por esta razón, en RHEL 8 no se puede utilizar una base de datos NSS para almacenar el certificado HTTPS y la clave privada.

  2. Opcionalmente, para comprobar el estado de su solicitud:

    # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
    Number of certificates and requests being tracked: 3.
    Request ID '20190604065735':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
        CA: IPA
        issuer: CN=WEBSERVER,O=IDM.EXAMPLE.COM
    
    [...]

    La salida muestra que la solicitud está en el estado MONITORING, lo que significa que se ha obtenido un certificado. Las ubicaciones del par de claves y del certificado son las solicitadas.

50.5. Flujo de comunicación para el certmonger que solicita un certificado de servicio

Los diagramas de esta sección muestran las etapas de lo que ocurre cuando certmonger solicita un certificado de servicio al servidor de la autoridad de certificación (CA) de Gestión de Identidades (IdM). La secuencia consta de estos diagramas:

En los diagramas, la sub-CA webserver-ca está representada por el genérico IdM CA server.

Figura 50.2, “Comunicación no encriptada” muestra la situación inicial: sin un certificado HTTPS, la comunicación entre el servidor web y el navegador no está cifrada.

Figura 50.2. Comunicación no encriptada

84 RHEL IdM 0420 1


Figura 50.3, “Certmonger solicita un certificado de servicio” muestra al administrador del sistema utilizando certmonger para solicitar manualmente un certificado HTTPS para el servidor web Apache. Tenga en cuenta que al solicitar un certificado de servidor web, certmonger no se comunica directamente con la CA. Lo hace a través de IdM.

Figura 50.3. Certmonger solicita un certificado de servicio

84 RHEL IdM 0420 2


Figura 50.4, “CA IdM que emite el certificado de servicio” muestra una CA IdM emitiendo un certificado HTTPS para el servidor web.

Figura 50.4. CA IdM que emite el certificado de servicio

84 RHEL IdM 0420 3


Figura 50.5, “Certmonger aplicando el certificado de servicio” muestra a certmonger colocando el certificado HTTPS en los lugares apropiados del cliente IdM y, si se le indica, reiniciando el servicio httpd. Posteriormente, el servidor Apache utiliza el certificado HTTPS para cifrar el tráfico entre él y el navegador.

Figura 50.5. Certmonger aplicando el certificado de servicio

84 RHEL IdM 0420 4


Figura 50.6, “Certmonger solicita un nuevo certificado cuando el antiguo está a punto de caducar” muestra certmonger solicitando automáticamente la renovación del certificado de servicio a la CA IdM antes de la expiración del certificado. La CA IdM emite un nuevo certificado.

Figura 50.6. Certmonger solicita un nuevo certificado cuando el antiguo está a punto de caducar

84 RHEL IdM 0420 5


50.6. Configuración de un servidor HTTP Apache de una sola instancia

Esta sección describe cómo configurar un servidor HTTP Apache de una sola instancia para servir contenido HTML estático.

Siga el procedimiento de esta sección si el servidor web debe proporcionar el mismo contenido para todos los dominios asociados al servidor. Si desea proporcionar un contenido diferente para diferentes dominios, configure hosts virtuales basados en nombres. Para más detalles, consulte Configuración de hosts virtuales basados en nombres de Apache.

Procedimiento

  1. Instale el paquete httpd:

    # yum install httpd
  2. Abra el puerto TCP 80 en el firewall local:

    # firewall-cmd --permanent --add-port=80/tcp
    # firewall-cmd --reload
  3. Habilite e inicie el servicio httpd:

    # systemctl enable --now httpd
  4. Opcional: Añada los archivos HTML al directorio /var/www/html/.

    Nota

    Al añadir contenido a /var/www/html/, los archivos y directorios deben ser legibles por el usuario bajo el cual se ejecuta httpd por defecto. El propietario del contenido puede ser el usuario root y el grupo de usuarios root, u otro usuario o grupo a elección del administrador. Si el propietario del contenido es el usuario root y el grupo de usuarios root, los archivos deben poder ser leídos por otros usuarios. El contexto SELinux para todos los archivos y directorios debe ser httpd_sys_content_t, que se aplica por defecto a todo el contenido dentro del directorio /var/www.

Pasos de verificación

  • Conéctese con un navegador web a http://my_company.idm.example.com/ o http://server_IP/.

    Si el directorio /var/www/html/ está vacío o no contiene un archivo index.html o index.htm, Apache muestra el Red Hat Enterprise Linux Test Page. Si /var/www/html/ contiene archivos HTML con un nombre diferente, puede cargarlos introduciendo la URL de ese archivo, como http://server_IP/example.html o http://my_company.idm.example.com/example.html.

Recursos adicionales

  • Para más detalles sobre la configuración de Apache y la adaptación del servicio a su entorno, consulte el manual de Apache. Para más detalles sobre la instalación del manual, consulte el manual de instalación del servidor HTTP Apache.
  • Para más detalles sobre el uso o el ajuste del servicio httpd systemd , consulte la página man httpd.service(8).

50.7. Cómo añadir el cifrado TLS a un servidor HTTP Apache

Esta sección describe cómo activar el cifrado TLS en el servidor HTTP Apache de my_company.idm.example.com para el dominio idm.example.com.

Requisitos previos

  • El servidor HTTP Apache de my_company.idm.example.com está instalado y funcionando.
  • Ha obtenido el certificado TLS de la sub-CA webserver-ca, y lo ha almacenado en el archivo /etc/pki/tls/certs/httpd.pem como se describe en Sección 50.4, “Obtención de un certificado IdM para un servicio mediante certmonger”. Si utiliza una ruta diferente, adapte los pasos correspondientes del procedimiento.
  • La clave privada correspondiente se almacena en el archivo /etc/pki/tls/private/httpd.key. Si utiliza una ruta diferente, adapte los pasos correspondientes del procedimiento.
  • El certificado de la CA webserver-ca se almacena en el archivo /etc/pki/tls/private/sub-ca.crt. Si utiliza una ruta diferente, adapte los pasos correspondientes del procedimiento.
  • Los clientes y el servidor web my_company.idm.example.com resuelven el nombre de host del servidor a la dirección IP del servidor web.

Procedimiento

  1. Instale el paquete mod_ssl:

    # dnf install mod_ssl
  2. Edite el archivo /etc/httpd/conf.d/ssl.conf y añada la siguiente configuración a la directiva <VirtualHost _default_:443>:

    1. Establezca el nombre del servidor:

      Nombre del servidor my_company.idm.example.com
      Importante

      El nombre del servidor debe coincidir con la entrada establecida en el campo Common Name del certificado.

    2. Opcional: Si el certificado contiene nombres de host adicionales en el campo Subject Alt Names (SAN), puede configurar mod_ssl para que proporcione cifrado TLS también para estos nombres de host. Para configurarlo, añada el parámetro ServerAliases con los nombres correspondientes:

      ServidorAlias www.my_company.idm.example.com server.my_company.idm.example.com
    3. Establezca las rutas de acceso a la clave privada, el certificado del servidor y el certificado de la CA:

      SSLCertificateKeyFile "/etc/pki/tls/private/httpd.key"
      SSLCertificateFile "/etc/pki/tls/certs/httpd.pem"
      SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"
  3. Por razones de seguridad, configure que sólo el usuario root pueda acceder al archivo de la clave privada:

    # chown root:root /etc/pki/tls/private/httpd.key
    # chmod 600 //etc/pki/tls/private/httpd.key
    Aviso

    Si los usuarios no autorizados accedieron a la clave privada, revoque el certificado, cree una nueva clave privada y solicite un nuevo certificado. En caso contrario, la conexión TLS deja de ser segura.

  4. Abra el puerto 443 en el firewall local:

    # firewall-cmd --permanent --add-port=443
    # firewall-cmd --reload
  5. Reinicie el servicio httpd:

    # systemctl restart httpd
    Nota

    Si protegió el archivo de clave privada con una contraseña, deberá introducirla cada vez que se inicie el servicio httpd.

    • Utilice un navegador y conéctese a https://my_company.idm.example.com.

Recursos adicionales

  • Para más detalles sobre la configuración de TLS, consulte la documentación de SSL/TLS Encryption en el manual de Apache. Para más detalles sobre la instalación del manual, consulte el manual de instalación del servidor HTTP Apache.

50.8. Configuración de las versiones de protocolo TLS admitidas en un servidor HTTP Apache

Por defecto, el servidor HTTP Apache en RHEL 8 utiliza la política crypto de todo el sistema que define valores seguros por defecto, que además son compatibles con los navegadores recientes. Por ejemplo, la política DEFAULT define que sólo las versiones del protocolo TLSv1.2 y TLSv1.3 están habilitadas en apache.

Esta sección describe cómo configurar manualmente las versiones de protocolo TLS que admite su servidor HTTP Apache de my_company.idm.example.com. Siga el procedimiento si su entorno requiere habilitar sólo versiones específicas del protocolo TLS, por ejemplo:

  • Si su entorno requiere que los clientes también puedan utilizar el protocolo débil TLS1 (TLSv1.0) o TLS1.1.
  • Si quiere configurar que Apache sólo soporte el protocolo TLSv1.2 o TLSv1.3.

Requisitos previos

Procedimiento

  1. Edite el archivo /etc/httpd/conf/httpd.conf y añada la siguiente configuración a la directiva <VirtualHost> para la que desea establecer la versión del protocolo TLS. Por ejemplo, para habilitar sólo el protocolo TLSv1.3:

    SSLProtocolo -Todo TLSv1.3
  2. Reinicie el servicio httpd:

    # systemctl restart httpd

Pasos de verificación

  1. Utilice el siguiente comando para verificar que el servidor soporta TLSv1.3:

    # openssl s_client -connect example.com:443 -tls1_3
  2. Utilice el siguiente comando para verificar que el servidor no soporta TLSv1.2:

    # openssl s_client -connect example.com:443 -tls1_2

    Si el servidor no soporta el protocolo, el comando devuelve un error:

    140111600609088:error:1409442E:Rutinas SSL:ssl3_read_bytes:versión del protocolo de alerta tlsv1:ssl/record/rec_layer_s3.c:1543:Número de alerta SSL 70
  3. Opcional: Repita el comando para otras versiones del protocolo TLS.

Recursos adicionales

50.9. Cómo configurar los cifrados admitidos en un servidor HTTP Apache

Por defecto, el servidor HTTP Apache en RHEL 8 utiliza la política de cifrado de todo el sistema que define valores seguros por defecto, que también son compatibles con los navegadores recientes. Para ver la lista de cifrados que permite la política de cifrado de todo el sistema, consulte el archivo /etc/crypto-policies/back-ends/openssl.config.

Esta sección describe cómo configurar manualmente los cifrados que admite el servidor HTTP Apache de my_company.idm.example.com. Siga el procedimiento si su entorno requiere cifrados específicos.

Requisitos previos

Procedimiento

  1. Edite el archivo /etc/httpd/conf/httpd.conf y añada el parámetro SSLCipherSuite a la directiva <VirtualHost> para la que desea establecer los cifrados TLS:

    SSLCipherSuite \ "EECDH AESGCM:EDH AESGCM:AES256 EECDH:AES256 EDH:!SHA1:!SHA256"

    Este ejemplo activa sólo los cifrados EECDH AESGCM, EDH AESGCM, AES256 EECDH, y AES256 EDH y desactiva todos los cifrados que utilizan el código de autenticación de mensajes (MAC) SHA1 y SHA256.

  2. Reinicie el servicio httpd:

    # systemctl restart httpd

Pasos de verificación

  1. Para mostrar la lista de cifrados que soporta el servidor HTTP Apache:

    1. Instale el paquete nmap:

      # yum install nmap
    2. Utiliza la utilidad nmap para mostrar los cifrados soportados:

      # nmap --script ssl-enum-ciphers -p 443 example.com
      ...
      PORT    STATE SERVICE
      443/tcp open  https
      | ssl-enum-ciphers:
      |   TLSv1.2:
      |     ciphers:
      |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
      |       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
      |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
      ...

Recursos adicionales

50.10. Configuración de la autenticación del certificado de cliente TLS

La autenticación de certificado de cliente permite a los administradores permitir que sólo los usuarios que se autentiquen utilizando un certificado puedan acceder a los recursos del servidor web my_company.idm.example.com. Esta sección describe cómo configurar la autenticación de certificados de cliente para el directorio /var/www/html/Example/.

Importante

Si el servidor my_company.idm.example.com Apache utiliza el protocolo TLS 1.3, algunos clientes necesitan una configuración adicional. Por ejemplo, en Firefox, establezca el parámetro security.tls.enable_post_handshake_auth en el menú about:config a true. Para más detalles, consulte Transport Layer Security versión 1.3 en Red Hat Enterprise Linux 8.

Requisitos previos

Procedimiento

  1. Edite el archivo /etc/httpd/conf/httpd.conf y añada la siguiente configuración a la directiva <VirtualHost> para la que desea configurar la autenticación del cliente:

    <Directory "/var/www/html/Example/">
      SSLVerifyClient require
    </Directory>

    La configuración SSLVerifyClient require define que el servidor debe validar con éxito el certificado del cliente antes de que éste pueda acceder al contenido del directorio /var/www/html/Example/.

  2. Reinicie el servicio httpd:

    # systemctl restart httpd

Pasos de verificación

  1. Utilice la utilidad curl para acceder a la URL https://my_company.idm.example.com/Example/ sin autenticación de cliente:

    $ curl https://my_company.idm.example.com/Example/
    curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0

    El error indica que el servidor web my_company.idm.example.com requiere un certificado de autentificación del cliente.

  2. Pase la clave privada y el certificado del cliente, así como el certificado de la CA a curl para acceder a la misma URL con autenticación de cliente:

    $ curl --cacert ca.crt --key client.key --cert client.crt https://my_company.idm.example.com/Example/

    Si la solicitud tiene éxito, curl muestra el archivo index.html almacenado en el directorio /var/www/html/Example/.

Recursos adicionales

  • Para más detalles sobre la autentificación del cliente, consulte la documentación de mod_ssl Configuration How-To en el manual de Apache. Para más detalles sobre la instalación del manual, consulte el manual de instalación del servidor HTTP Apache.

50.11. Solicitar un nuevo certificado de usuario y exportarlo al cliente

Como administrador de Identity Management (IdM), puede configurar un servidor web que se ejecuta en un cliente IdM para solicitar a los usuarios que utilizan navegadores web para acceder al servidor que se autentiquen con certificados emitidos por una sub-CA IdM específica. Complete esta sección para solicitar un certificado de usuario a una sub-CA de IdM específica y para exportar el certificado y la clave privada correspondiente al host desde el que el usuario quiere acceder al servidor web utilizando un navegador web. A continuación, importe el certificado y la clave privada en el navegador.

Procedimiento

  1. Opcionalmente, cree un nuevo directorio, por ejemplo ~/certdb/, y conviértalo en una base de datos de certificados temporal. Cuando se le pida, cree una contraseña de la base de datos de certificados NSS para cifrar las claves del certificado que se generará en un paso posterior:

    # mkdir ~/certdb/
    # certutil -N -d ~/certdb/
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
  2. Cree la solicitud de firma de certificado (CSR) y redirija la salida a un archivo. Por ejemplo, para crear una CSR con el nombre certificate_request.csr para un certificado de bits 4096 para el usuario idm_user en el ámbito IDM.EXAMPLE.COM, estableciendo el apodo de las claves privadas del certificado como idm_user para facilitar su localización, y estableciendo el asunto como CN=idm_user,O=IDM.EXAMPLE.COM:

    # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s \ "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr
  3. Cuando se le solicite, introduzca la misma contraseña que introdujo cuando utilizó certutil para crear la base de datos temporal. A continuación, siga escribiendo randlomly hasta que se le indique que se detenga:

    Enter Password or Pin for "NSS Certificate DB":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
  4. Envíe el archivo de solicitud de certificado al servidor. Especifique la entidad de seguridad de Kerberos que se asociará con el certificado recién emitido, el archivo de salida para almacenar el certificado y, opcionalmente, el perfil del certificado. Especifique la sub-CA de IdM que desea emitir el certificado. Por ejemplo, para obtener un certificado del perfil IECUserRoles, un perfil con extensión de roles de usuario añadidos, para la entidad de crédito idm_user@IDM.EXAMPLE.COM desde webclient-ca, y guardar el certificado en el archivo ~/idm_user.pem:

    # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --ca=webclient-ca --certificate-out=~/idm_user.pem
  5. Añade el certificado a la base de datos del NSS. Utilice la opción -n para establecer el mismo apodo que utilizó al crear la CSR anteriormente para que el certificado coincida con la clave privada en la base de datos del NSS. La opción -t establece el nivel de confianza. Para más detalles, consulte la página man de certutil(1). La opción -i especifica el archivo de certificado de entrada. Por ejemplo, para añadir a la base de datos del NSS un certificado con el apodo idm_user que está almacenado en el archivo ~/idm_user.pem en la base de datos ~/certdb/:

    # certutil -A -d ~/certdb/ -n idm_user -t \ "P,," -i ~/idm_user.pem
  6. Verifique que la clave en la base de datos NSS no muestra (orphan) como su apodo. Por ejemplo, para verificar que el certificado almacenado en la base de datos ~/certdb/ no está huérfano:

    # certutil -K -d ~/certdb/
    < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user
  7. Utilice el comando pk12util para exportar el certificado de la base de datos NSS al formato PKCS12. Por ejemplo, para exportar el certificado con el apodo idm_user de la base de datos NSS /root/certdb al archivo ~/idm_user.p12:

    # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  8. Transfiera el certificado al host en el que desea que se habilite la autenticación de certificados para idm_user:

    # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/
  9. En el host al que se ha transferido el certificado, haga que el directorio en el que se almacena el archivo .pkcs12 sea inaccesible para el grupo "otros" por razones de seguridad:

    # chmod o-rwx /home/idm_user/
  10. Por razones de seguridad, elimine la base de datos NSS temporal y el archivo .pkcs12 del servidor:

    # rm ~/certdb/
    # rm ~/idm_user.p12

50.12. Configuración de un navegador para activar la autenticación de certificados

Para poder autenticarse con un certificado cuando se utiliza la WebUI para iniciar sesión en la Gestión de Identidades (IdM), es necesario importar el usuario y los certificados de la autoridad de certificación (CA) correspondiente en el navegador Mozilla Firefox o Google Chrome. El propio host en el que se ejecuta el navegador no tiene que formar parte del dominio de IdM.

IdM admite los siguientes navegadores para conectarse a la WebUI:

  • Mozilla Firefox 38 y posteriores
  • Google Chrome 46 y posteriores

El siguiente procedimiento muestra cómo configurar el navegador Mozilla Firefox 57.0.1.

Requisitos previos

Procedimiento

  1. Abra Firefox y, a continuación, vaya a PreferencesPrivacy & Security.

    Figura 50.7. Sección de privacidad y seguridad en Preferencias

    privacy and security
  2. Haga clic en Ver Certificados.

    Figura 50.8. Ver Certificados en Privacidad y Seguridad

    view certificates
  3. En la pestaña Your Certificates, haga clic en Importar. Localice y abra el certificado del usuario en el formato PKCS12 y, a continuación, haga clic en Aceptar y en OK.
  4. Para asegurarte de que tu sub-CA de IdM es reconocida por Firefox como una autoridad de confianza, importa el certificado de sub-CA de IdM que guardaste en Sección 50.2, “Descarga del certificado sub-CA desde IdM WebUI” como un certificado de autoridad de confianza:

    1. Abre Firefox, ve a Preferencias y haz clic en Privacidad & Seguridad.

      Figura 50.9. Sección de privacidad y seguridad en Preferencias

      privacy and security
    2. Haga clic en Ver Certificados.

      Figura 50.10. Ver Certificados en Privacidad y Seguridad

      view certificates
    3. En la pestaña Authorities, haga clic en Importar. Localice y abra el certificado sub-CA. Confíe en el certificado para identificar los sitios web y, a continuación, haga clic en Aceptar y en OK.

Capítulo 52. Bóvedas en IdM

En este capítulo se describen los almacenes de la Gestión de identidades (IdM). Presenta los siguientes temas:

52.1. Bóvedas y sus beneficios

Un almacén es una característica útil para aquellos usuarios de la Gestión de Identidades (IdM) que quieren mantener todos sus datos sensibles almacenados de forma segura pero conveniente en un solo lugar. En esta sección se explican los distintos tipos de bóvedas y sus usos, y qué bóveda debe elegir en función de sus necesidades.

Una bóveda es una ubicación segura en (IdM) para almacenar, recuperar, compartir y recuperar un secreto. Un secreto son datos sensibles a la seguridad, normalmente credenciales de autenticación, a los que sólo puede acceder un grupo limitado de personas o entidades. Por ejemplo, los secretos incluyen:

  • contraseñas
  • PINs
  • claves privadas SSH

Un almacén es comparable a un gestor de contraseñas. Al igual que un gestor de contraseñas, un almacén suele requerir que el usuario genere y recuerde una contraseña maestra para desbloquear y acceder a cualquier información almacenada en el almacén. Sin embargo, un usuario también puede decidir tener un almacén estándar. Un almacén estándar no requiere que el usuario introduzca ninguna contraseña para acceder a los secretos almacenados en el almacén.

Nota

El propósito de los almacenes en IdM es guardar las credenciales de autenticación que le permiten autenticarse en servicios externos no relacionados con IdM.

Otras características importantes de las bóvedas IdM son:

  • A los almacenes sólo pueden acceder el propietario del almacén y los usuarios de IdM que el propietario del almacén seleccione como miembros del mismo. Además, el administrador de IdM tiene acceso al almacén.
  • Si un usuario no tiene suficientes privilegios para crear un almacén, un administrador de IdM puede crear el almacén y establecer al usuario como su propietario.
  • Los usuarios y servicios pueden acceder a los secretos almacenados en una bóveda desde cualquier máquina inscrita en el dominio de IdM.
  • Una bóveda sólo puede contener un secreto, por ejemplo, un archivo. Sin embargo, el propio archivo puede contener múltiples secretos, como contraseñas, keytabs o certificados.
Nota

Vault sólo está disponible desde la línea de comandos de IdM (CLI), no desde la interfaz web de IdM.

52.2. Propietarios, miembros y administradores de bóvedas

La gestión de identidades (IdM) distingue los siguientes tipos de usuarios de bóveda:

Propietario de la bóveda

Un propietario de almacén es un usuario o servicio con privilegios básicos de gestión sobre el almacén. Por ejemplo, un propietario de almacén puede modificar las propiedades del almacén o añadir nuevos miembros del mismo.

Cada almacén debe tener al menos un propietario. Un depósito también puede tener varios propietarios.

Miembro de la bóveda
Un miembro del almacén es un usuario o servicio que puede acceder a un almacén creado por otro usuario o servicio.
Administrador de la bóveda

Los administradores de bóvedas tienen acceso ilimitado a todas las bóvedas y pueden realizar todas las operaciones en ellas.

Nota

Las bóvedas simétricas y asimétricas están protegidas con una contraseña o clave y aplican reglas especiales de control de acceso (ver Tipos de bóvedas). El administrador debe cumplir estas reglas para:

  • Secretos de acceso en bóvedas simétricas y asimétricas.
  • Cambiar o restablecer la contraseña o la clave del almacén.

Un administrador de almacenes es cualquier usuario con el privilegio Vault Administrators. En el contexto del control de acceso basado en roles (RBAC) en IdM, un privilegio es un grupo de permisos que se pueden aplicar a un rol.

Usuario de la bóveda

El usuario del almacén representa al usuario en cuyo contenedor se encuentra el almacén. La información de Vault user se muestra en la salida de comandos específicos, como ipa vault-show:

$ ipa vault-show my_vault
  Vault name: my_vault
  Type: standard
  Owner users: user
  Vault user: user

Para más detalles sobre los contenedores de bóveda y las bóvedas de usuario, véase Contenedores de bóveda.

Recursos adicionales

52.3. Bóvedas estándar, simétricas y asimétricas

En función del nivel de seguridad y control de acceso, IdM clasifica los almacenes en los siguientes tipos:

Bóvedas estándar
Los propietarios y los miembros de la bóveda pueden archivar y recuperar los secretos sin tener que utilizar una contraseña o una llave.
Bóvedas simétricas
Los secretos de la bóveda están protegidos con una clave simétrica. Los propietarios y miembros de la bóveda pueden archivar y recuperar los secretos, pero deben proporcionar la contraseña de la bóveda.
Bóvedas asimétricas
Los secretos de la bóveda están protegidos con una clave asimétrica. Los usuarios archivan el secreto utilizando una clave pública y lo recuperan utilizando una clave privada. Los miembros de la bóveda sólo pueden archivar secretos, mientras que los propietarios de la bóveda pueden hacer ambas cosas, archivar y recuperar secretos.

52.4. Bóvedas de usuario, de servicio y compartidas

En función de la propiedad, IdM clasifica los almacenes en varios tipos. La siguiente tabla contiene información sobre cada tipo, su propietario y su uso.

Tabla 52.1. Bóvedas IdM basadas en la propiedad

TipoDescripciónPropietarioNota

User vault

Una bóveda privada para un usuario

Un solo usuario

Cualquier usuario puede ser propietario de uno o más almacenes de usuario si el administrador de IdM lo permite

Service vault

Una bóveda privada para un servicio

Un solo servicio

Cualquier servicio puede poseer uno o más almacenes de usuarios si lo permite el administrador de IdM

Shared vault

Una bóveda compartida por múltiples usuarios y servicios

El administrador de la bóveda que creó la bóveda

Los usuarios y servicios pueden ser propietarios de uno o más almacenes de usuario si el administrador de IdM lo permite. Los administradores de los almacenes que no hayan creado el almacén también tienen acceso completo al mismo.

52.5. Contenedores de bóveda

Un contenedor de almacén es una colección de almacenes. En la siguiente tabla se enumeran los contenedores de almacén predeterminados que proporciona Identity Management (IdM).

Tabla 52.2. Contenedores de bóveda por defecto en IdM

TipoDescripciónPropósito

Contenedor de usuario

Un contenedor privado para un usuario

Almacena los depósitos de un usuario en particular

Contenedor de servicio

Un contenedor privado para un servicio

Almacena bóvedas de servicio para un determinado servicio

Contenedor compartido

Un contenedor para múltiples usuarios y servicios

Almacena bóvedas que pueden ser compartidas por varios usuarios o servicios

IdM crea contenedores de usuario y servicio para cada usuario o servicio automáticamente cuando se crea el primer almacén privado para el usuario o servicio. Después de que el usuario o servicio se elimine, IdM elimina el contenedor y su contenido.

52.6. Comandos básicos de la bóveda IdM

En esta sección se describen los comandos básicos que se pueden utilizar para gestionar los almacenes de gestión de identidades (IdM). La siguiente tabla contiene una lista de comandos de ipa vault-* con la explicación de su propósito.

Nota

Antes de ejecutar cualquier comando de ipa vault-*, instale el componente del sistema de certificados de la Autoridad de recuperación de claves (KRA) en uno o varios de los servidores de su dominio de IdM. Para obtener más información, consulte Instalación de la autoridad de recuperación de claves en IdM.

Tabla 52.3. Comandos básicos de la bóveda de IdM con explicaciones

ComandoPropósito

ipa help vault

Muestra información conceptual sobre los almacenes IdM y ejemplos de comandos de almacén.

ipa vault-add --help, ipa vault-find --help

Al añadir la opción --help a un comando específico de ipa vault-*, se muestran las opciones y la ayuda detallada disponibles para ese comando.

ipa vault-show user_vault --user idm_user

Cuando se accede a un almacén como miembro del mismo, se debe especificar el propietario del almacén. Si no se especifica el propietario del almacén, IdM le informará de que no ha encontrado el almacén:

[admin@server ~]$ ipa vault-show user_vault
ipa: ERROR: user_vault: vault not found

ipa vault-show shared_vault --shared

Al acceder a un almacén compartido, debes especificar que el almacén al que quieres acceder es un almacén compartido. De lo contrario, IdM le informará de que no ha encontrado el almacén:

[admin@server ~]$ ipa vault-show shared_vault
ipa: ERROR: shared_vault: vault not found

52.7. Instalación de la Autoridad de Recuperación de Claves en IdM

En esta sección se describe cómo se pueden habilitar los almacenes en Identity Management (IdM) mediante la instalación del componente Key Recovery Authority (KRA) Certificate System (CS).

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.
  • Estás conectado como root en un cliente IdM.

Procedimiento

  • Instale el KRA:

    # ipa-kra-install
Nota

Para que el servicio de bóveda esté altamente disponible, instale el KRA en dos servidores IdM o más.

Capítulo 53. Uso de los almacenes de usuarios de IdM: almacenamiento y recuperación de secretos

Este capítulo describe cómo utilizar los almacenes de usuarios en la Gestión de Identidades. En concreto, se describe cómo un usuario puede almacenar un secreto en un almacén de IdM y cómo puede recuperarlo. El usuario puede realizar el almacenamiento y la recuperación desde dos clientes IdM diferentes.

Requisitos previos

53.1. Almacenar un secreto en un almacén de usuarios

Esta sección muestra cómo un usuario puede crear un contenedor de bóveda con una o más bóvedas privadas para almacenar de forma segura archivos con información sensible. En el ejemplo utilizado en el procedimiento siguiente, el usuario idm_user crea un almacén de tipo estándar. El tipo de almacén estándar garantiza que idm_user no tendrá que autenticarse para acceder al archivo. idm_user podrá recuperar el archivo desde cualquier cliente IdM en el que el usuario haya iniciado sesión.

En el procedimiento:

  • idm_user es el usuario que quiere crear la bóveda.
  • my_vault es la bóveda utilizada para almacenar el certificado del usuario.
  • El tipo de bóveda es standard, por lo que el acceso al certificado archivado no requiere que el usuario proporcione una contraseña de bóveda.
  • secret.txt es el archivo que contiene el certificado que el usuario quiere almacenar en la bóveda.

Requisitos previos

  • Ya conoces la contraseña de idm_user.
  • Has iniciado sesión en un host que es cliente de IdM.

Procedimiento

  1. Obtenga el ticket de concesión de tickets de Kerberos (TGT) para idm_user:

    $ kinit idm_user
  2. Utilice el comando ipa vault-add con la opción --type standard para crear una bóveda estándar:

    $ ipa vault-add my_vault --type standard
    ----------------------
    Added vault "my_vault"
    ----------------------
      Vault name: my_vault
      Type: standard
      Owner users: idm_user
      Vault user: idm_user
    Importante

    Asegúrese de que el primer almacén de un usuario sea creado por el mismo usuario. Al crear el primer almacén para un usuario también se crea el contenedor del almacén del usuario. El agente de la creación se convierte en el propietario del contenedor del almacén.

    Por ejemplo, si otro usuario, como admin, crea el primer almacén de usuario para user1, el propietario del contenedor del almacén de usuario será también admin, y user1 no podrá acceder al almacén de usuario ni crear nuevos almacenes de usuario.

  3. Utilice el comando ipa vault-archive con la opción --in para archivar el archivo secret.txt en la bóveda:

    $ ipa vault-archive my_vault --in secret.txt
    -----------------------------------
    Archived data into vault "my_vault"
    -----------------------------------

53.2. Recuperación de un secreto de un depósito de usuarios

Como gestor de identidades (IdM), puede recuperar un secreto de su bóveda privada de usuario en cualquier cliente IdM en el que esté conectado.

Esta sección muestra cómo recuperar, como usuario de IdM llamado idm_user, un secreto de la bóveda privada del usuario llamado my_vault en idm_client.idm.example.com.

Requisitos previos

  • idm_user es el propietario de my_vault.
  • idm_user ha archivado un secreto en la cámara acorazada.
  • my_vault es una cámara acorazada estándar, lo que significa que idm_user no tiene que introducir ninguna contraseña para acceder al contenido de la cámara.

Procedimiento

  1. SSH a idm_client como idm_user:

    $ ssh idm_user@idm_client.idm.example.com
  2. Inicie sesión como idm_user:

    $ kinit user
  3. Utilice el comando ipa vault-retrieve --out con la opción --out para recuperar el contenido de la bóveda y guardarlo en el archivo secret_exported.txt.

    $ ipa vault-retrieve my_vault --out secret_exported.txt
    --------------------------------------
    Retrieved data from vault "my_vault"
    --------------------------------------

Recursos adicionales

Capítulo 54. Uso de Ansible para gestionar los almacenes de usuarios de IdM: almacenamiento y recuperación de secretos

Este capítulo describe cómo gestionar los almacenes de usuarios en Identity Management mediante el módulo Ansible vault. En concreto, se describe cómo un usuario puede utilizar los libros de juego de Ansible para realizar las siguientes tres acciones consecutivas:

El usuario puede realizar el almacenamiento y la recuperación desde dos clientes IdM diferentes.

Requisitos previos

54.1. Garantizar la presencia de un almacén de usuarios estándar en IdM mediante Ansible

Esta sección muestra cómo un usuario de Gestión de Identidades (IdM) puede utilizar un libro de jugadas de Ansible para crear un contenedor de bóveda con una o más bóvedas privadas para almacenar de forma segura información sensible. En el ejemplo utilizado en el procedimiento siguiente, el usuario de idm_user crea un almacén de tipo estándar denominado my_vault. El tipo de bóveda estándar garantiza que idm_user no tendrá que autenticarse cuando acceda al archivo. idm_user podrá recuperar el archivo desde cualquier cliente IdM en el que el usuario haya iniciado sesión.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible, que es el host en el que ejecuta los pasos del procedimiento.
  • Ya conoces la contraseña de idm_user.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Cree un archivo de inventario, por ejemplo inventory.file:

    $ touch inventory.file
  3. Abra inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  4. Haga una copia del archivo de playbook de Ansible ensure-standard-vault-is-present.yml. Por ejemplo:

    $ cp ensure-standard-vault-is-present.yml ensure-standard-vault-is-present-copy.yml
  5. Abra el archivo ensure-standard-vault-is-present-copy.yml para editarlo.
  6. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establezca la variable ipaadmin_principal en idm_user.
    • Establezca la variable ipaadmin_password con la contraseña de idm_user.
    • Establezca la variable user en idm_user.
    • Establezca la variable name en my_vault.
    • Establezca la variable vault_type en standard.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          vault_type: standard
  7. Guarda el archivo.
  8. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-standard-vault-is-present-copy.yml

54.2. Archivar un secreto en una bóveda de usuario estándar en IdM usando Ansible

Esta sección muestra cómo un usuario de Gestión de Identidades (IdM) puede utilizar un libro de jugadas de Ansible para almacenar información sensible en una bóveda personal. En el ejemplo utilizado, el usuario idm_user archiva un archivo con información sensible llamado password.txt en una bóveda llamada my_vault.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible, que es el host en el que ejecuta los pasos del procedimiento.
  • Ya conoces la contraseña de idm_user.
  • idm_user es el propietario, o al menos un usuario miembro de my_vault.
  • Tienes acceso a password.txt, el secreto que quieres archivar en my_vault.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible data-archive-in-symmetric-vault.yml pero sustituya "simétrico" por "estándar". Por ejemplo:

    $ cp data-archive-in-symmetric-vault.yml data-archive-in-standard-vault-copy.yml
  4. Abra el archivo data-archive-in-standard-vault-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establezca la variable ipaadmin_principal en idm_user.
    • Establezca la variable ipaadmin_password con la contraseña de idm_user.
    • Establezca la variable user en idm_user.
    • Establezca la variable name en my_vault.
    • Establezca la variable in con la ruta completa del archivo con información sensible.
    • Establezca la variable action en member.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          in: /usr/share/doc/ansible-freeipa/playbooks/vault/password.txt
          action: member
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file data-archive-in-standard-vault-copy.yml

54.3. Recuperación de un secreto de una bóveda de usuario estándar en IdM usando Ansible

Esta sección muestra cómo un usuario de Gestión de Identidades (IdM) puede utilizar un libro de jugadas de Ansible para recuperar un secreto del almacén personal del usuario. En el ejemplo utilizado en el procedimiento siguiente, el usuario idm_user recupera un archivo con datos confidenciales de una bóveda de tipo estándar denominada my_vault en un cliente IdM denominado host01. idm_user no tiene que autenticarse al acceder al archivo. idm_user puede utilizar Ansible para recuperar el archivo desde cualquier cliente IdM en el que esté instalado Ansible.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Ya conoces la contraseña de idm_user.
  • idm_user es el propietario de my_vault.
  • idm_user ha guardado un secreto en my_vault.
  • Ansible puede escribir en el directorio del host de IdM en el que quieres recuperar el secreto.
  • idm_user puede leer desde el directorio del host de IdM en el que se desea recuperar el secreto.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Abra su archivo de inventario y mencione, en una sección claramente definida, el cliente IdM en el que desea recuperar el secreto. Por ejemplo, para ordenar a Ansible que recupere el secreto en host01.idm.example.com, introduzca:

    [ipahost]
    host01.idm.example.com
  3. Haga una copia del archivo retrive-data-symmetric-vault.yml Ansible playbook. Sustituya "simétrico" por "estándar". Por ejemplo:

    $ cp retrive-data-symmetric-vault.yml retrieve-data-standard-vault.yml-copy.yml
  4. Abra el archivo retrieve-data-standard-vault.yml-copy.yml para editarlo.
  5. Adapte el archivo ajustando la variable hosts a ipahost.
  6. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establezca la variable ipaadmin_principal en idm_user.
    • Establezca la variable ipaadmin_password con la contraseña de idm_user.
    • Establezca la variable user en idm_user.
    • Establezca la variable name en my_vault.
    • Establezca la variable out con la ruta completa del archivo al que desea exportar el secreto.
    • Establezca la variable state en retrieved.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Tests
      hosts: ipahost
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          out: /tmp/password_exported.txt
          state: retrieved
  7. Guarda el archivo.
  8. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file retrieve-data-standard-vault.yml-copy.yml

Pasos de verificación

  1. SSH a host01 como user01:

    $ ssh user01@host01.idm.example.com
  2. Vea el archivo especificado por la variable out en el archivo del libro de jugadas de Ansible:

    $ vim /tmp/contraseña_exportada.txt

Ahora puedes ver el secreto exportado.

  • Para obtener más información sobre el uso de Ansible para gestionar los almacenes de IdM y los secretos de usuario y sobre las variables del libro de jugadas, consulte el archivo Markdown README-vault.md disponible en el directorio /usr/share/doc/ansible-freeipa/ y los libros de jugadas de ejemplo disponibles en el directorio /usr/share/doc/ansible-freeipa/playbooks/vault/.

Capítulo 55. Gestión de los secretos del servicio IdM: almacenamiento y recuperación de secretos

Esta sección muestra cómo un administrador puede utilizar el módulo ansible-freeipa vault para almacenar de forma segura un secreto de servicio en una ubicación centralizada. La bóveda utilizada en el ejemplo es asimétrica, lo que significa que para utilizarla, el administrador necesita realizar los siguientes pasos:

  1. Genere una clave privada utilizando, por ejemplo, la utilidad openssl.
  2. Generar una clave pública basada en la clave privada.

El secreto del servicio se encripta con la clave pública cuando un administrador lo archiva en la bóveda. Después, una instancia de servicio alojada en una máquina específica del dominio recupera el secreto utilizando la clave privada. Sólo el servicio y el administrador pueden acceder al secreto.

Si el secreto está comprometido, el administrador puede reemplazarlo en la bóveda de servicios y luego redistribuirlo a aquellas instancias de servicio individuales que no han sido comprometidas.

Requisitos previos

Esta sección incluye este procedimiento

Terminología utilizada

En los procedimientos:

  • admin es el administrador que gestiona la contraseña del servicio.
  • private-key-to-an-externally-signed-certificate.pem es el archivo que contiene el secreto del servicio, en este caso una clave privada de un certificado firmado externamente. No confundas esta clave privada con la clave privada utilizada para recuperar el secreto de la bóveda.
  • secret_vault es la bóveda creada para el servicio.
  • HTTP/webserver.idm.example.com es el servicio cuyo secreto se está archivando.
  • service-public.pem es la clave pública del servicio utilizada para cifrar la contraseña almacenada en password_vault.
  • service-private.pem es la clave privada del servicio utilizada para descifrar la contraseña almacenada en secret_vault.

55.1. Almacenamiento de un secreto de servicio IdM en una cámara acorazada asimétrica

Esta sección describe cómo crear una bóveda asimétrica y utilizarla para archivar un secreto de servicio.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Inicie sesión como administrador:

    $ kinit admin
  2. Obtener la clave pública de la instancia de servicio. Por ejemplo, utilizando la utilidad openssl:

    1. Generar la clave privada service-private.pem.

      $ openssl genrsa -out service-private.pem 2048
      Generating RSA private key, 2048 bit long modulus
      .+++
      ...........................................+++
      e is 65537 (0x10001)
    2. Generar la clave pública service-public.pem a partir de la clave privada.

      $ openssl rsa -in service-private.pem -out service-public.pem -pubout
      writing RSA key
  3. Cree una bóveda asimétrica como la bóveda de la instancia de servicio, y proporcione la clave pública:

    $ ipa vault-add secret_vault --service HTTP/webserver.idm.example.com --type asymmetric --public-key-file service-public.pem
    ----------------------------
    Added vault "secret_vault"
    ----------------------------
    Vault name: secret_vault
    Type: asymmetric
    Public key: LS0tLS1C...S0tLS0tCg==
    Owner users: admin
    Vault service: HTTP/webserver.idm.example.com@IDM.EXAMPLE.COM

    La contraseña archivada en la cámara acorazada estará protegida con la llave.

  4. Archivar el secreto de servicio en la bóveda de servicio:

    $ ipa vault-archive secret_vault --service HTTP/webserver.idm.example.com --in private-key-to-an-externally-signed-certificate.pem
    -----------------------------------
    Archived data into vault "secret_vault"
    -----------------------------------

    Esto encripta el secreto con la clave pública de la instancia de servicio.

Repita estos pasos para cada instancia de servicio que requiera el secreto. Cree una nueva bóveda asimétrica para cada instancia de servicio.

55.2. Recuperación de un secreto de servicio para una instancia de servicio IdM

Esta sección describe cómo una instancia de servicio puede recuperar el secreto de la bóveda de servicio utilizando una clave privada de servicio almacenada localmente.

Requisitos previos

Procedimiento

  1. Inicie sesión como administrador:

    $ kinit admin
  2. Obtener un ticket Kerberos para el servicio:

    # kinit HTTP/webserver.idm.example.com -k -t /etc/httpd/conf/ipa.keytab
  3. Recuperar la contraseña de la bóveda de servicio:

    $ ipa vault-retrieve secret_vault --service HTTP/webserver.idm.example.com --private-key-file service-private.pem --out secret.txt
    ------------------------------------
    Retrieved data from vault "secret_vault"
    ------------------------------------

55.3. Cambiar el secreto de la bóveda de un servicio IdM cuando está comprometido

Esta sección describe cómo aislar una instancia de servicio comprometida cambiando el secreto de la bóveda de servicio.

Requisitos previos

  • Ya conoces la contraseña de IdM administrator.
  • Ha creado una bóveda asimétrica para almacenar el secreto de servicio.
  • Ha generado el nuevo secreto y tiene acceso a él, por ejemplo, en el archivo new-private-key-to-an-externally-signed-certificate.pem.

Procedimiento

  1. Archiva el nuevo secreto en la bóveda de la instancia de servicio:

    $ ipa vault-archive secret_vault --service HTTP/webserver.idm.example.com --in new-private-key-to-an-externally-signed-certificate.pem
    -----------------------------------
    Archived data into vault "secret_vault"
    -----------------------------------

    Esto sobrescribe el secreto actual almacenado en la bóveda.

  2. Recupere el nuevo secreto sólo en instancias de servicio no comprometidas. Para obtener más detalles, consulte Recuperación de un secreto de servicio para una instancia de servicio IdM.

Recursos adicionales

Capítulo 56. Uso de Ansible para gestionar las bóvedas de servicio de IdM: almacenamiento y recuperación de secretos

Esta sección muestra cómo un administrador puede utilizar el módulo ansible-freeipa vault para almacenar de forma segura un secreto de servicio en una ubicación centralizada. La bóveda utilizada en el ejemplo es asimétrica, lo que significa que para utilizarla, el administrador necesita realizar los siguientes pasos:

  1. Genere una clave privada utilizando, por ejemplo, la utilidad openssl.
  2. Generar una clave pública basada en la clave privada.

El secreto del servicio se encripta con la clave pública cuando un administrador lo archiva en la bóveda. Después, una instancia de servicio alojada en una máquina específica del dominio recupera el secreto utilizando la clave privada. Sólo el servicio y el administrador pueden acceder al secreto.

Si el secreto está comprometido, el administrador puede reemplazarlo en la bóveda de servicios y luego redistribuirlo a aquellas instancias de servicio individuales que no han sido comprometidas.

Requisitos previos

Esta sección incluye estos procedimientos:

En los procedimientos:

  • admin es el administrador que gestiona la contraseña del servicio.
  • private-key-to-an-externally-signed-certificate.pem es el archivo que contiene el secreto del servicio, en este caso una clave privada de un certificado firmado externamente. No confundas esta clave privada con la clave privada utilizada para recuperar el secreto de la bóveda.
  • secret_vault es la bóveda creada para almacenar el secreto del servicio.
  • HTTP/webserver1.idm.example.com es el servicio propietario de la bóveda.
  • HTTP/webserver2.idm.example.com y HTTP/webserver3.idm.example.com son los servicios de los miembros de la bóveda.
  • service-public.pem es la clave pública del servicio utilizada para cifrar la contraseña almacenada en password_vault.
  • service-private.pem es la clave privada del servicio utilizada para descifrar la contraseña almacenada en secret_vault.

56.1. Garantizar la presencia de una bóveda de servicio asimétrica en IdM utilizando Ansible

Esta sección muestra cómo un administrador de Gestión de Identidades (IdM) puede utilizar un libro de jugadas de Ansible para crear un contenedor de bóveda de servicio con una o más bóvedas privadas para almacenar de forma segura la información sensible. En el ejemplo utilizado en el procedimiento siguiente, el administrador crea una bóveda asimétrica denominada secret_vault. Esto asegura que los miembros de la bóveda tienen que autenticarse usando una clave privada para poder recuperar el secreto en la bóveda. Los miembros de la bóveda podrán recuperar el archivo desde cualquier cliente IdM.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Ya conoces la contraseña de IdM administrator.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Obtener la clave pública de la instancia de servicio. Por ejemplo, utilizando la utilidad openssl:

    1. Generar la clave privada service-private.pem.

      $ openssl genrsa -out service-private.pem 2048
      Generating RSA private key, 2048 bit long modulus
      .+++
      ...........................................+++
      e is 65537 (0x10001)
    2. Generar la clave pública service-public.pem a partir de la clave privada.

      $ openssl rsa -in service-private.pem -out service-public.pem -pubout
      writing RSA key
  3. Opcional: Crear un archivo de inventario si no existe, por ejemplo inventory.file:

    $ touch inventory.file
  4. Abra su archivo de inventario y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  5. Haga una copia del archivo de playbook de Ansible ensure-asymmetric-vault-is-present.yml. Por ejemplo:

    $ cp ensure-asymmetric-vault-is-present.yml ensure-asymmetric-service-vault-is-present-copy.yml
  6. Abra el archivo ensure-asymmetric-vault-is-present-copy.yml para editarlo.
  7. Añade una tarea que copie la clave pública service-public.pem desde el controlador de Ansible al servidor server.idm.example.com.
  8. Modifique el resto del archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establezca la variable ipaadmin_password con la contraseña del administrador de IdM.
    • Defina el nombre de la bóveda utilizando la variable name, por ejemplo secret_vault.
    • Establezca la variable vault_type en asymmetric.
    • Establezca la variable service con el director del servicio propietario de la bóveda, por ejemplo HTTP/webserver1.idm.example.com.
    • Establezca en public_key_file la ubicación de su clave pública.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
      tasks:
      - name: Copy public key to ipaserver.
        copy:
          src: /path/to/service-public.pem
          dest: /usr/share/doc/ansible-freeipa/playbooks/vault/service-public.pem
          mode: 0600
      - name: Add data to vault, from a LOCAL file.
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          vault_type: asymmetric
          service: HTTP/webserver1.idm.example.com
          public_key_file: /usr/share/doc/ansible-freeipa/playbooks/vault/service-public.pem
  9. Guarda el archivo.
  10. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-asymmetric-service-vault-is-present-copy.yml

56.2. Añadir servicios de miembros a una bóveda asimétrica usando Ansible

Esta sección muestra cómo un administrador de Gestión de Identidades (IdM) puede utilizar un libro de jugadas de Ansible para añadir servicios miembros a un almacén de servicios de manera que todos ellos puedan recuperar el secreto almacenado en el almacén. En el ejemplo utilizado en el procedimiento siguiente, el administrador de IdM añade los directores de servicio HTTP/webserver2.idm.example.com y HTTP/webserver3.idm.example.com al almacén secret_vault que es propiedad de HTTP/webserver1.idm.example.com.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Ya conoces la contraseña de IdM administrator.
  • Ha creado una bóveda asimétrica para almacenar el secreto de servicio.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Opcional: Crear un archivo de inventario si no existe, por ejemplo inventory.file:

    $ touch inventory.file
  3. Abra su archivo de inventario y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  4. Haga una copia del archivo de playbook de Ansible data-archive-in-asymmetric-vault.yml. Por ejemplo:

    $ cp data-archive-in-asymmetric-vault.yml add-services-to-an-asymmetric-vault.yml
  5. Abra el archivo data-archive-in-asymmetric-vault-copy.yml para editarlo.
  6. Modifique el archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establezca la variable ipaadmin_password con la contraseña del administrador de IdM.
    • Establezca la variable name con el nombre de la bóveda, por ejemplo secret_vault.
    • Establezca la variable service con el propietario del servicio de la bóveda, por ejemplo HTTP/webserver1.idm.example.com.
    • Defina los servicios que desea que tengan acceso al secreto de la bóveda utilizando la variable services.
    • Establezca la variable action en member.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          services:
          - HTTP/webserver2.idm.example.com
          - HTTP/webserver3.idm.example.com
          action: member
  7. Guarda el archivo.
  8. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file add-services-to-an-asymmetric-vault.yml

56.3. Almacenamiento de un secreto de servicio IdM en una bóveda asimétrica mediante Ansible

Esta sección muestra cómo un administrador de Gestión de Identidades (IdM) puede utilizar un libro de jugadas de Ansible para almacenar un secreto en una bóveda de servicio para que pueda ser recuperado posteriormente por el servicio. En el ejemplo utilizado en el procedimiento siguiente, el administrador almacena un archivo PEM con el secreto en una bóveda asimétrica llamada secret_vault. Esto asegura que el servicio tendrá que autenticarse usando una clave privada para poder recuperar el secreto de la bóveda. Los miembros de la bóveda podrán recuperar el archivo desde cualquier cliente IdM.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Ya conoces la contraseña de IdM administrator.
  • Ha creado una bóveda asimétrica para almacenar el secreto de servicio.
  • El secreto se almacena localmente en el controlador Ansible, por ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/vault/private-key-to-an-externally-signed-certificate.pem.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Opcional: Crear un archivo de inventario si no existe, por ejemplo inventory.file:

    $ touch inventory.file
  3. Abra su archivo de inventario y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  4. Haga una copia del archivo de playbook de Ansible data-archive-in-asymmetric-vault.yml. Por ejemplo:

    $ cp data-archive-in-asymmetric-vault.yml data-archive-in-asymmetric-vault-copy.yml
  5. Abra el archivo data-archive-in-asymmetric-vault-copy.yml para editarlo.
  6. Modifique el archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establezca la variable ipaadmin_password con la contraseña del administrador de IdM.
    • Establezca la variable name con el nombre de la bóveda, por ejemplo secret_vault.
    • Establezca la variable service con el propietario del servicio de la bóveda, por ejemplo HTTP/webserver1.idm.example.com.
    • Establezca la variable in en "{{ lookup('file', 'private-key-to-an-externally-signed-certificate.pem') | b64encode }}". Esto garantiza que Ansible recupere el archivo con la clave privada del directorio de trabajo en el controlador de Ansible y no del servidor de IdM.
    • Establezca la variable action en member.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          in: "{{ lookup('file', 'private-key-to-an-externally-signed-certificate.pem') | b64encode }}"
          action: member
  7. Guarda el archivo.
  8. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file data-archive-in-asymmetric-vault-copy.yml

56.4. Recuperación de un secreto de servicio para un servicio IdM mediante Ansible

Esta sección muestra cómo un usuario de Gestión de Identidades (IdM) puede utilizar un libro de jugadas de Ansible para recuperar un secreto de una bóveda de servicio en nombre del servicio. En el ejemplo utilizado en el procedimiento siguiente, la ejecución del libro de jugadas recupera un archivo PEM con el secreto de una bóveda asimétrica denominada secret_vault, y lo almacena en la ubicación especificada en todos los hosts enumerados en el archivo de inventario de Ansible como ipaservers.

Los servicios se autentican en IdM utilizando keytabs, y se autentican en la bóveda utilizando una clave privada. Puedes recuperar el archivo en nombre del servicio desde cualquier cliente IdM en el que esté instalado ansible-freeipa.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.
  • Ha creado una bóveda asimétrica para almacenar el secreto de servicio.
  • Has archivado el secreto en la cámara acorazada.
  • Ha almacenado la clave privada utilizada para recuperar el secreto de la bóveda de servicio en la ubicación especificada por la variable private_key_file en el controlador de Ansible.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Opcional: Crear un archivo de inventario si no existe, por ejemplo inventory.file:

    $ touch inventory.file
  3. Abra su archivo de inventario y defina los siguientes hosts:

    • Defina su servidor IdM en la sección [ipaserver].
    • Defina los hosts en los que desea recuperar el secreto en la sección [webservers]. Por ejemplo, para ordenar a Ansible que recupere el secreto en webserver1.idm.example.com, webserver2.idm.example.com, y webserver3.idm.example.com, introduzca:
    [ipaserver]
    server.idm.example.com
    
    [webservers]
    webserver1.idm.example.com
    webserver2.idm.example.com
    webserver3.idm.example.com
  4. Haga una copia del archivo de playbook de Ansible retrieve-data-asymmetric-vault.yml. Por ejemplo:

    $ cp retrieve-data-asymmetric-vault.yml retrieve-data-asymmetric-vault-copy.yml
  5. Abra el archivo retrieve-data-asymmetric-vault-copy.yml para editarlo.
  6. Modifique el archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable name con el nombre de la bóveda, por ejemplo secret_vault.
    • Establezca la variable service con el propietario del servicio de la bóveda, por ejemplo HTTP/webserver1.idm.example.com.
    • Establezca la variable private_key_file en la ubicación de la clave privada utilizada para recuperar el secreto de la bóveda de servicio.
    • Establezca la variable out en la ubicación del servidor IdM donde desea recuperar el secreto de private-key-to-an-externally-signed-certificate.pem, por ejemplo, el directorio de trabajo actual.
    • Establezca la variable action en member.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
    
      tasks:
      - name: Retrieve data from the service vault
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          vault_type: asymmetric
          private_key: "{{ lookup('file', 'service-private.pem') | b64encode }}"
          out: private-key-to-an-externally-signed-certificate.pem
          state: retrieved
  7. Añade una sección al libro de jugadas que recupere el archivo de datos del servidor de IdM al controlador de Ansible:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
      tasks:
    [...]
      - name: Retrieve data file
        fetch:
          src: private-key-to-an-externally-signed-certificate.pem
          dest: ./
          flat: yes
          mode: 0600
  8. Añada una sección al libro de jugadas que transfiera el archivo private-key-to-an-externally-signed-certificate.pem recuperado del controlador de Ansible a los servidores web enumerados en la sección webservers del archivo de inventario:

    ---
    - name: Send data file to webservers
      become: no
      gather_facts: no
      hosts: webservers
      tasks:
      - name: Send data to webservers
        copy:
          src: private-key-to-an-externally-signed-certificate.pem
          dest: /etc/pki/tls/private/httpd.key
          mode: 0444
  9. Guarda el archivo.
  10. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file retrieve-data-asymmetric-vault-copy.yml

56.5. Cambiar el secreto de la bóveda de un servicio IdM cuando está comprometido usando Ansible

Esta sección muestra cómo un administrador de Gestión de Identidades (IdM) puede reutilizar un libro de jugadas de Ansible para cambiar el secreto almacenado en una bóveda de servicio cuando una instancia de servicio ha sido comprometida. El escenario en el siguiente ejemplo asume que en webserver3.idm.example.com, el secreto recuperado ha sido comprometido, pero no la clave de la bóveda asimétrica que almacena el secreto. En el ejemplo, el administrador reutiliza los playbooks de Ansible utilizados cuando se almacena un secreto en una bóveda asimétrica y se recupera un secreto de la bóveda asimétrica en los hosts de IdM. Al comienzo del procedimiento, el administrador de IdM almacena un nuevo archivo PEM con un nuevo secreto en la bóveda asimétrica, adapta el archivo de inventario para no recuperar el nuevo secreto en el servidor web comprometido, webserver3.idm.example.com, y luego vuelve a ejecutar los dos procedimientos.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Ya conoces la contraseña de IdM administrator.
  • Ha creado una bóveda asimétrica para almacenar el secreto de servicio.
  • Ha generado una nueva clave httpd para los servicios web que se ejecutan en los hosts de IdM para sustituir la antigua clave comprometida.
  • La nueva clave httpd se almacena localmente en el controlador Ansible, por ejemplo en el archivo /usr/share/doc/ansible-freeipa/playbooks/vault/private-key-to-an-externally-signed-certificate.pem.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Abra su archivo de inventario y compruebe que el servidor IdM que desea configurar está definido correctamente en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:
  3. Abra su archivo de inventario y asegúrese de que los siguientes hosts están definidos correctamente:

    • El servidor IdM en la sección [ipaserver].
    • Los hosts en los que desea recuperar el secreto en la sección [webservers]. Por ejemplo, para ordenar a Ansible que recupere el secreto en webserver1.idm.example.com y webserver2.idm.example.com, introduzca:

      [ipaserver]
      server.idm.example.com
      
      [webservers]
      webserver1.idm.example.com
      webserver2.idm.example.com
    Importante

    Asegúrese de que la lista no contiene el servidor web comprometido, en el ejemplo actual webserver3.idm.example.com.

  4. Abra el archivo data-archive-in-asymmetric-vault-copy.yml para editarlo.
  5. Modifique el archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establezca la variable ipaadmin_password con la contraseña del administrador de IdM.
    • Establezca la variable name con el nombre de la bóveda, por ejemplo secret_vault.
    • Establezca la variable service con el propietario del servicio de la bóveda, por ejemplo HTTP/webserver.idm.example.com.
    • Establezca la variable in en "{{ lookup('file', 'new-private-key-to-an-externally-signed-certificate.pem') | b64encode }}". Esto garantiza que Ansible recupere el archivo con la clave privada del directorio de trabajo en el controlador de Ansible y no del servidor de IdM.
    • Establezca la variable action en member.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver.idm.example.com
          in: "{{ lookup('file', 'new-private-key-to-an-externally-signed-certificate.pem') | b64encode }}"
          action: member
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file data-archive-in-asymmetric-vault-copy.yml
  8. Abra el archivo retrieve-data-asymmetric-vault-copy.yml para editarlo.
  9. Modifique el archivo estableciendo las siguientes variables en la sección de tareas ipavault:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable name con el nombre de la bóveda, por ejemplo secret_vault.
    • Establezca la variable service con el propietario del servicio de la bóveda, por ejemplo HTTP/webserver1.idm.example.com.
    • Establezca la variable private_key_file en la ubicación de la clave privada utilizada para recuperar el secreto de la bóveda de servicio.
    • Establezca la variable out en la ubicación del servidor IdM donde desea recuperar el secreto de new-private-key-to-an-externally-signed-certificate.pem, por ejemplo, el directorio de trabajo actual.
    • Establezca la variable action en member.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
    
      tasks:
      - name: Retrieve data from the service vault
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          vault_type: asymmetric
          private_key: "{{ lookup('file', 'service-private.pem') | b64encode }}"
          out: new-private-key-to-an-externally-signed-certificate.pem
          state: retrieved
  10. Añade una sección al libro de jugadas que recupere el archivo de datos del servidor de IdM al controlador de Ansible:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: yes
      gather_facts: false
      tasks:
    [...]
      - name: Retrieve data file
        fetch:
          src: new-private-key-to-an-externally-signed-certificate.pem
          dest: ./
          flat: yes
          mode: 0600
  11. Añada una sección al libro de jugadas que transfiera el archivo new-private-key-to-an-externally-signed-certificate.pem recuperado del controlador de Ansible a los servidores web enumerados en la sección webservers del archivo de inventario:

    ---
    - name: Send data file to webservers
      become: yes
      gather_facts: no
      hosts: webservers
      tasks:
      - name: Send data to webservers
        copy:
          src: new-private-key-to-an-externally-signed-certificate.pem
          dest: /etc/pki/tls/private/httpd.key
          mode: 0444
  12. Guarda el archivo.
  13. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file retrieve-data-asymmetric-vault-copy.yml

Recursos adicionales

  • Para obtener más información sobre el uso de Ansible para gestionar los almacenes de IdM y los secretos de servicio y sobre las variables del libro de jugadas, consulte el archivo Markdown README-vault.md disponible en el directorio /usr/share/doc/ansible-freeipa/ y los libros de jugadas de ejemplo disponibles en el directorio /usr/share/doc/ansible-freeipa/playbooks/vault/.

Capítulo 57. Garantizar la presencia y ausencia de servicios en IdM mediante Ansible

Con el módulo de Ansible service, el administrador de Identity Management (IdM) puede asegurar la presencia o ausencia de servicios específicos que no son nativos de IdM. Por ejemplo, puede utilizar el módulo service para:

57.1. Garantizar la presencia de un servicio HTTP en IdM mediante un playbook de Ansible

En esta sección se describe cómo garantizar la presencia de un servidor HTTP en IdM mediante un playbook de Ansible.

Requisitos previos

  • El sistema que aloja el servicio HTTP es un cliente IdM.
  • Tienes la contraseña de administrador de IdM.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file:

    $ touch inventory.file
  2. Abra la página inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present.yml. Por ejemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml
  4. Abra el archivo /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml Ansible playbook para editarlo:

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
  5. Adapte el archivo:

    • Cambia la contraseña del administrador de IdM definida por la variable ipaadmin_password.
    • Cambie el nombre de su cliente IdM en el que se ejecuta el servicio HTTP, tal y como se define en la variable name de la tarea ipaservice.
  6. Guarde y salga del archivo.
  7. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml

Pasos de verificación

  1. Inicie sesión en la interfaz web de IdM como administrador de IdM.
  2. Navegue hasta IdentityServices.

Si HTTP/client.idm.example.com@IDM.EXAMPLE.COM aparece en la lista de Services, el playbook de Ansible se ha añadido correctamente a IdM.

Recursos adicionales

57.2. Garantizar la presencia de un servicio HTTP en IdM en un cliente no IdM utilizando un libro de jugadas de Ansible

Esta sección describe cómo asegurar la presencia de un servidor HTTP en IdM en un host que no es cliente de IdM utilizando un playbook de Ansible. Al añadir el servidor HTTP a IdM también estás añadiendo el host a IdM.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file:

    $ touch inventory.file
  2. Abra la página inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check.yml. Por ejemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check-copy.yml
  4. Abra el archivo copiado, /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check-copy.yml, para editarlo. Localice las variables ipaadmin_password y name en la tarea ipaservice:

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/www2.example.com
          skip_host_check: yes
  5. Adapte el archivo:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable name con el nombre del host en el que se ejecuta el servicio HTTP.
  6. Guarde y salga del archivo.
  7. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check-copy.yml

Pasos de verificación

  1. Inicie sesión en la interfaz web de IdM como administrador de IdM.
  2. Navegue hasta IdentityServices.

Ahora puede ver HTTP/client.idm.example.com@IDM.EXAMPLE.COM en la lista Services.

Recursos adicionales

57.3. Garantizar la presencia de un servicio HTTP en un cliente IdM sin DNS mediante un libro de jugadas de Ansible

Esta sección describe cómo garantizar la presencia de un servidor HTTP que se ejecuta en un cliente IdM que no tiene ninguna entrada DNS utilizando un libro de jugadas de Ansible. El escenario implicado es que el host IdM no tiene una entrada DNS A disponible - o ninguna entrada DNS AAAA si se utiliza IPv6 en lugar de IPv4.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file:

    $ touch inventory.file
  2. Abra la página inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force.yml. Por ejemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml
  4. Abra el archivo copiado, /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml, para editarlo. Localice las variables ipaadmin_password y name en la tarea ipaservice:

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/ihavenodns.info
          force: yes
  5. Adapte el archivo:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable name con el nombre del host en el que se ejecuta el servicio HTTP.
  6. Guarde y salga del archivo.
  7. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml

Pasos de verificación

  1. Inicie sesión en la interfaz web de IdM como administrador de IdM.
  2. Navegue hasta IdentityServices.

Ahora puede ver HTTP/client.idm.example.com@IDM.EXAMPLE.COM en la lista Services.

Recursos adicionales

57.4. Garantizar la presencia de un certificado firmado externamente en una entrada de servicio de IdM mediante un libro de jugadas de Ansible

En esta sección se describe cómo utilizar el módulo ansible-freeipa service para garantizar que un certificado emitido por una autoridad de certificación (CA) externa se adjunte a la entrada IdM del servicio HTTP. Tener el certificado de un servicio HTTP firmado por una CA externa en lugar de la CA IdM es especialmente útil si su CA IdM utiliza un certificado autofirmado.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file:

    $ touch inventory.file
  2. Abra la página inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present.yml, por ejemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml
  4. Opcional: si el certificado está en formato PEM (Privacy Enhanced Mail), convierta el certificado al formato DER (Distinguished Encoding Rules) para facilitar su manejo a través de la interfaz de línea de comandos (CLI):

    $ openssl x509 -outform der -in cert1.pem -out cert1.der
  5. Decodifique el archivo DER a la salida estándar utilizando el comando base64. Utilice la opción -w0 para deshabilitar el envoltorio:

    $ base64 cert1.der -w0
    MIIC/zCCAeegAwIBAgIUV74O+4kXeg21o4vxfRRtyJm...
  6. Copiar el certificado de la salida estándar al portapapeles.
  7. Abra el archivo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml para editarlo y ver su contenido:

    ---
    - name: Service certificate present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service certificate is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/www.example.com
          certificate: |
            - MIICBjCCAW8CFHnm32VcXaUDGfEGdDL/...
          [...]
          action: member
          state: present
  8. Adapte el archivo:

    • Sustituya el certificado, definido mediante la variable certificate, por el certificado que ha copiado de la CLI. Tenga en cuenta que si utiliza la variable certificate: con el carácter de tubería || como se indica, puede introducir el certificado DE ESTA MANERA en lugar de tener que introducirlo en una sola línea. Esto facilita la lectura del certificado.
    • Cambia la contraseña del administrador de IdM, definida por la variable ipaadmin_password.
    • Cambie el nombre de su cliente IdM en el que se ejecuta el servicio HTTP, definido por la variable name.
    • Cambia cualquier otra variable relevante.
  9. Guarde y salga del archivo.
  10. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml

Pasos de verificación

  1. Inicie sesión en la interfaz web de IdM como administrador de IdM.
  2. Navegue hasta IdentityServices.
  3. Haga clic en el nombre del servicio con el certificado recién añadido, por ejemplo HTTP/client.idm.example.com.

En la sección Service Certificate, a la derecha, puede ver el certificado recién añadido.

57.5. Utilizar un libro de jugadas de Ansible para permitir a los usuarios, grupos, hosts o grupos de hosts de IdM crear un keytab de un servicio

Un keytab es un archivo que contiene pares de entidades de crédito Kerberos y claves cifradas. Los archivos keytab se utilizan comúnmente para permitir que los scripts se autentiquen automáticamente utilizando Kerberos, sin requerir la interacción humana o el acceso a la contraseña almacenada en un archivo de texto plano. El script puede entonces utilizar las credenciales adquiridas para acceder a los archivos almacenados en un sistema remoto.

Como administrador de Identity Management (IdM), puede permitir que otros usuarios recuperen o incluso creen un keytab para un servicio que se ejecuta en IdM. Al permitir que determinados usuarios y grupos de usuarios creen keytabs, puede delegar en ellos la administración del servicio sin compartir la contraseña de administrador de IdM. Esta delegación proporciona una administración del sistema más detallada.

En esta sección se describe cómo se puede permitir a determinados usuarios de IdM, grupos de usuarios, hosts y grupos de hosts crear un llavero para el servicio HTTP que se ejecuta en un cliente IdM. En concreto, se describe cómo se puede permitir que el usuario user01 IdM cree un llavero para el servicio HTTP que se ejecuta en un cliente IdM denominado client.idm.example.com.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
  • Ha inscrito el servicio HTTP en IdM.
  • El sistema que aloja el servicio HTTP es un cliente IdM.
  • Los usuarios y grupos de usuarios de IdM a los que se quiere permitir crear el keytab existen en IdM.
  • Los hosts y grupos de hosts de IdM a los que quieres permitir crear el keytab existen en IdM.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file:

    $ touch inventory.file
  2. Abra la página inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present.yml. Por ejemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml
  4. Abra el archivo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml Ansible playbook para editarlo.
  5. Adapte el archivo cambiando lo siguiente:

    • La contraseña del administrador de IdM especificada por la variable ipaadmin_password.
    • El nombre del cliente IdM en el que se ejecuta el servicio HTTP. En el ejemplo actual, es HTTP/client.idm.example.com
    • Los nombres de los usuarios de IdM que aparecen en la sección allow_create_keytab_user:. En el ejemplo actual, es user01.
    • Los nombres de los grupos de usuarios de IdM que aparecen en la sección allow_create_keytab_group:.
    • Los nombres de los hosts de IdM que aparecen en la sección allow_create_keytab_host:.
    • Los nombres de los grupos de hosts IdM que aparecen en la sección allow_create_keytab_hostgroup:.
    • El nombre de la tarea especificada por la variable name en la sección tasks.

      Una vez adaptado para el ejemplo actual, el archivo copiado tiene el siguiente aspecto:

    ---
    - name: Service member allow_create_keytab present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com members allow_create_keytab present for user01
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          allow_create_keytab_user:
          - user01
          action: member
  6. Guarda el archivo.
  7. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml

Pasos de verificación

  1. SSH a un servidor IdM como un usuario IdM que tiene el privilegio de crear un keytab para el servicio HTTP particular:

    $ ssh user01@server.idm.example.com
    Password:
  2. Utilice el comando ipa-getkeytab para generar el nuevo keytab para el servicio HTTP:

    $ ipa-getkeytab -s server.idm.example.com -p HTTP/client.idm.example.com -k /etc/httpd/conf/krb5.keytab

    La opción -s especifica un servidor de Centro de Distribución de Claves (KDC) para generar el keytab.

    La opción -p especifica la entidad de seguridad cuyo keytab se desea crear.

    La opción -k especifica el archivo keytab al que se añadirá la nueva clave. El archivo se creará si no existe.

Si el comando no da lugar a un error, ha creado con éxito un keytab de HTTP/client.idm.example.com como user01.

57.6. Utilizar un libro de jugadas de Ansible para permitir que los usuarios, grupos, hosts o grupos de hosts de IdM recuperen un keytab de un servicio

Un keytab es un archivo que contiene pares de entidades de crédito Kerberos y claves cifradas. Los archivos keytab se utilizan comúnmente para permitir que los scripts se autentiquen automáticamente utilizando Kerberos, sin requerir la interacción humana o el acceso a una contraseña almacenada en un archivo de texto plano. El script puede entonces utilizar las credenciales adquiridas para acceder a los archivos almacenados en un sistema remoto.

Como administrador de IdM, puedes permitir a otros usuarios recuperar o incluso crear un keytab para un servicio que se ejecute en IdM.

En esta sección se describe cómo se puede permitir que determinados usuarios de IdM, grupos de usuarios, hosts y grupos de hosts recuperen un llavero del servicio HTTP que se ejecuta en un cliente IdM. En concreto, se describe cómo permitir que el usuario de IdM user01 recupere el llavero del servicio HTTP que se ejecuta en client.idm.example.com.

Requisitos previos

  • Conoce la contraseña del administrador de IdM.
  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
  • Ha inscrito el servicio HTTP en IdM.
  • Los usuarios y grupos de usuarios de IdM a los que se quiere permitir recuperar el llavero existen en IdM.
  • Los hosts y grupos de hosts de IdM a los que se quiere permitir recuperar el keytab existen en IdM.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file:

    $ toque inventory.file
  2. Abra la página inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present.yml. Por ejemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml
  4. Abra el archivo copiado, /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml, para editarlo:
  5. Adapte el archivo:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable name de la tarea ipaservice en el principal del servicio HTTP. En el ejemplo actual, es HTTP/client.idm.example.com
    • Especifique los nombres de los usuarios de IdM en la sección allow_retrieve_keytab_group:. En el ejemplo actual, es user01.
    • Especifique los nombres de los grupos de usuarios de IdM en la sección allow_retrieve_keytab_group:.
    • Especifique los nombres de los hosts IdM en la sección allow_retrieve_keytab_group:.
    • Especifique los nombres de los grupos de hosts IdM en la sección allow_retrieve_keytab_group:.
    • Especifique el nombre de la tarea utilizando la variable name en la sección tasks.

      Una vez adaptado para el ejemplo actual, el archivo copiado tiene el siguiente aspecto:

    ---
    - name: Service member allow_retrieve_keytab present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com members allow_retrieve_keytab present for user01
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          allow_retrieve_keytab_user:
          - user01
          action: member
  6. Guarda el archivo.
  7. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml

Pasos de verificación

  1. SSH a un servidor IdM como un usuario IdM con el privilegio de recuperar un keytab para el servicio HTTP:

    $ ssh user01@server.idm.example.com
    Password:
  2. Utilice el comando ipa-getkeytab con la opción -r para recuperar el keytab:

    $ ipa-getkeytab -r -s server.idm.example.com -p HTTP/client.idm.example.com -k /etc/httpd/conf/krb5.keytab

    La opción -s especifica un servidor del Centro de Distribución de Claves (KDC) del que se quiere recuperar el keytab.

    La opción -p especifica la entidad de seguridad cuyo llavero se desea recuperar.

    La opción -k especifica el archivo keytab al que se quiere añadir la clave recuperada. El archivo se creará si no existe.

Si el comando no da lugar a un error, ha recuperado con éxito un keytab de HTTP/client.idm.example.com como user01.

57.7. Garantizar la presencia de un alias principal de Kerberos de un servicio utilizando un libro de jugadas de Ansible

En algunos escenarios, es beneficioso para el administrador de IdM permitir que los usuarios, hosts o servicios de IdM se autentiquen contra las aplicaciones de Kerberos utilizando un alias de entidad de seguridad de Kerberos. Estos escenarios incluyen:

  • El nombre de usuario ha cambiado, pero el usuario debería poder entrar en el sistema utilizando tanto el nombre de usuario anterior como el nuevo.
  • El usuario debe iniciar la sesión con la dirección de correo electrónico, incluso si el dominio de IdM Kerberos es diferente del dominio de correo electrónico.

Esta sección describe cómo crear el alias principal de HTTP/mycompany.idm.example.com para el servicio HTTP que se ejecuta en client.idm.example.com.

Requisitos previos

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file:

    $ touch inventory.file
  2. Abra la página inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present.yml. Por ejemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml
  4. Abra el archivo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml Ansible playbook para editarlo.
  5. Adapte el archivo cambiando lo siguiente:

    • La contraseña del administrador de IdM especificada por la variable ipaadmin_password.
    • El nombre del servicio especificado por la variable name. Es el nombre principal canónico del servicio. En el ejemplo actual, es HTTP/client.idm.example.com.
    • El alias de director de Kerberos especificado por la variable principal. Este es el alias que quiere añadir al servicio definido por la variable name. En el ejemplo actual, es host/mycompany.idm.example.com.
    • El nombre de la tarea especificada por la variable name en la sección tasks.

      Una vez adaptado para el ejemplo actual, el archivo copiado tiene el siguiente aspecto:

    ---
    - name: Service member principal present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com member principals host/mycompany.idm.exmaple.com present
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          principal:
            - host/mycompany.idm.example.com
          action: member
  6. Guarda el archivo.
  7. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml

Si la ejecución del libro de jugadas da como resultado 0 tareas inalcanzables y 0 fallidas, ha creado con éxito la entidad de seguridad Kerberos host/mycompany.idm.example.com para el servicio HTTP/client.idm.example.com.

Recursos adicionales

57.8. Garantizar la ausencia de un servicio HTTP en IdM mediante un libro de jugadas de Ansible

Esta sección describe cómo desinscribir un servicio de IdM. Más concretamente, se describe cómo utilizar un playbook de Ansible para asegurar la ausencia de un servidor HTTP llamado HTTP/client.idm.example.com en IdM.

Requisitos previos

  • Tienes la contraseña de administrador de IdM.

Procedimiento

  1. Cree un archivo de inventario, por ejemplo inventory.file:

    $ touch inventory.file
  2. Abra la página inventory.file y defina el servidor IdM que desea configurar en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent.yml. Por ejemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml
  4. Abra el archivo /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml Ansible playbook para editarlo.
  5. Adapte el archivo cambiando lo siguiente:

    • La contraseña del administrador de IdM definida por la variable ipaadmin_password.
    • La entidad de crédito Kerberos del servicio HTTP, definida por la variable name de la tarea ipaservice.

      Una vez adaptado para el ejemplo actual, el archivo copiado tiene el siguiente aspecto:

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is absent
      - ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          state: absent
  6. Guarde y salga del archivo.
  7. Ejecute el playbook de Ansible especificando el archivo del playbook y el archivo de inventario:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml

Pasos de verificación

  1. Inicie sesión en la interfaz web de IdM como administrador de IdM.
  2. Navegue hasta IdentityServices.

Si no puede ver el servicio HTTP/client.idm.example.com@IDM.EXAMPLE.COM en la lista Services, ha asegurado con éxito su ausencia en IdM.

Recursos adicionales

  • Puedes ver ejemplos de playbooks de Ansible para asegurar la presencia y ausencia de servicios en IdM incluyendo una lista de posibles variables en el archivo README-service.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/.
  • Puedes ver ejemplos de playbooks de Ansible para asegurar la presencia y ausencia de servicios en IdM en el directorio /usr/share/doc/ansible-freeipa/playbooks/config.

Capítulo 58. Permitir que los usuarios de AD administren el IdM

58.1. Anulaciones de ID para los usuarios de AD

En Red Hat Enterprise Linux (RHEL) 7, la pertenencia a grupos externos permite a los usuarios y grupos de Active Directory (AD) acceder a los recursos de gestión de identidades (IdM) en un entorno POSIX con la ayuda del demonio de servicios de seguridad del sistema (SSSD).

El servidor LDAP de IdM tiene sus propios mecanismos para conceder el control de acceso. RHEL 8 introduce una actualización que permite añadir una anulación de usuario ID para un usuario de AD como miembro de un grupo IdM. Una anulación de ID es un registro que describe cómo deben ser las propiedades de un usuario o grupo específico de Active Directory dentro de una vista de ID específica, en este caso la vista de confianza predeterminada. Como consecuencia de la actualización, el servidor LDAP de IdM puede aplicar las reglas de control de acceso del grupo de IdM al usuario de AD.

Los usuarios de AD ahora pueden utilizar las funciones de autoservicio de la interfaz de IdM, por ejemplo, para cargar sus claves SSH o cambiar sus datos personales. Un administrador de AD es capaz de administrar completamente IdM sin tener dos cuentas y contraseñas diferentes.

Nota

Actualmente, es posible que algunas funciones de IdM sigan sin estar disponibles para los usuarios de AD. Por ejemplo, la configuración de contraseñas para los usuarios de IdM como usuario de AD del grupo IdM admins podría fallar.

58.2. Uso de anulaciones de ID para que los usuarios de AD puedan administrar IdM

Requisitos previos

  • El flujo idm:DL1 está habilitado en su servidor de Gestión de Identidades (IdM) y ha cambiado a los RPMs entregados a través de este flujo:

    # yum module enable idm:DL1
    # yum distro-sync
  • El perfil idm:DL1/adtrust está instalado en su servidor IdM.

    # yum module install idm:DL1/adtrust

    El perfil contiene todos los paquetes necesarios para instalar un servidor IdM que tendrá un acuerdo de confianza con Active Directory (AD), incluido el paquete ipa-idoverride-memberof.

  • Se ha configurado un entorno de IdM que funciona. Para más detalles, consulte Instalación de la gestión de identidades.
  • Se ha establecido una confianza de trabajo entre su entorno de IdM y AD.

Procedimiento

Este procedimiento describe la creación y el uso de una anulación de ID para un usuario de AD con el fin de otorgarle derechos idénticos a los de un usuario de IdM. Durante este procedimiento, trabaje en un servidor IdM que esté configurado como controlador de confianza o agente de confianza. Para obtener más información sobre los controladores de confianza y los agentes de confianza, consulte Trust controllers and trust agents en Planificación de la gestión de identidades.

  1. Como administrador de IdM, cree una sustitución de ID para un usuario de AD en la vista de confianza predeterminada. Por ejemplo, para crear una sustitución de ID para el usuario ad_user@ad.example.com:

    # kinit admin
    # ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com
  2. Añade la sustitución de ID de la vista de confianza predeterminada como miembro de un grupo IdM. Si el grupo en cuestión es miembro de un rol de IdM, el usuario de AD representado por la sustitución de ID obtendrá todos los permisos concedidos por el rol al utilizar la API de IdM, incluida la interfaz de línea de comandos y la interfaz web de IdM. Por ejemplo, para añadir la sustitución del ID del usuario ad_user@ad.example.com al grupo admins:

    # ipa group-add-member admins --idoverrideusers=ad_user@ad.example.com

58.3. Gestión de IdM CLI como usuario AD

Este procedimiento comprueba que un usuario de Active Directory (AD) puede iniciar sesión en la interfaz de línea de comandos (CLI) de Identity Management (IdM) y ejecutar los comandos correspondientes a su función.

  1. Destruye el ticket Kerberos actual del administrador de IdM:

    # kdestroy -A
    Nota

    La destrucción del ticket de Kerberos es necesaria porque la implementación de GSSAPI en MIT Kerberos elige las credenciales del ámbito del servicio de destino por preferencia, que en este caso es el ámbito de IdM. Esto significa que si se utiliza una colección de caché de credenciales, en concreto el tipo de caché de credenciales KCM:, KEYRING: o DIR:, se utilizará una admin obtenida previamente o cualquier otra credencial de entidad de seguridad IdM para acceder a la API IdM en lugar de las credenciales del usuario de AD.

  2. Obtenga las credenciales de Kerberos del usuario de AD para el que se ha creado una anulación de ID:

    # kinit ad_user@AD.EXAMPLE.COM
    Password for ad_user@AD.EXAMPLE.COM:
  3. Compruebe que el sustituto de ID del usuario AD goza de los mismos privilegios derivados de la pertenencia al grupo IdM que cualquier usuario IdM de ese grupo. Si la sustitución de ID del usuario de AD se ha añadido al grupo admins, el usuario de AD puede, por ejemplo, crear grupos en IdM:

    # ipa group-add some-new-group
    ----------------------------
    Added group "some-new-group"
    ----------------------------
      Group name: some-new-group
      GID: 1997000011

Capítulo 59. Activación de la autenticación mediante los nombres de usuario principales de AD en IdM

59.1. Nombres de usuarios principales en un bosque de AD en el que confía el IdM

Como administrador del sistema de gestión de identidades (IdM) que está conectado a Active Directory (AD) mediante un acuerdo de confianza, puede permitir que los usuarios de AD utilicen User Principal Names (UPN) alternativos cuando accedan a los recursos del dominio de IdM. Un UPN es un user_login alternativo con el que se autentican los usuarios de AD, y tiene el formato de user_name@KERBEROS-REALM. Un administrador del sistema AD puede establecer valores alternativos tanto para user_name como para KERBEROS-REALM, ya que en un bosque AD es posible configurar tanto alias Kerberos adicionales como sufijos UPN.

Por ejemplo, si una empresa utiliza el dominio Kerberos AD.EXAMPLE.COM, el UPN por defecto para un usuario es user@ad.example.com. Sin embargo, como administrador del sistema puede permitir que sus usuarios puedan iniciar sesión utilizando sus direcciones de correo electrónico, por ejemplo user@example.com.

Siempre que se defina un nuevo UPN en el lado de AD, ejecute, como administrador de IdM, el comando ipa trust-fetch-domains en un servidor de IdM, para asegurarse de que los UPN de AD están actualizados en IdM.

Nota

Los sufijos UPN de un dominio se almacenan en el atributo multivalor ipaNTAdditionalSuffixes en el subárbol cn=trusted_domain_name,cn=ad,cn=trusts,dc=idm,dc=example,dc=com.

Los UPN alternativos, o de empresa, son especialmente convenientes si su empresa ha experimentado recientemente una fusión y quiere proporcionar a sus usuarios un espacio de nombres de inicio de sesión unificado.

59.2. Garantizar que los UPN de AD están actualizados en IdM

Cuando añada o elimine un sufijo de nombre de usuario principal (UPN) en un bosque de Active Directory (AD) de confianza, actualice la información del bosque de confianza en el maestro de IdM.

Requisitos previos

  • Asegúrese de haber obtenido las credenciales de administrador de IdM.

Procedimiento

  1. Introduzca el comando ipa trust-fetch-domains. Tenga en cuenta que se espera una salida aparentemente vacía:

    [root@ipaserver ~]# ipa trust-fetch-domains
    Realm-Name: ad.example.com
    -------------------------------
    No new trust domains were found
    -------------------------------
    ----------------------------
    Number of entries returned 0
    ----------------------------
  2. Introduzca el comando ipa trust-show para verificar que se ha obtenido el nuevo UPN. Especifique el nombre del dominio de AD cuando se le solicite:

    [root@ipaserver ~]# ipa trust-show
    Realm-Name: ad.example.com
      Realm-Name: ad.example.com
      Domain NetBIOS name: AD
      Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
      Trust direction: Two-way trust
      Trust type: Active Directory domain
      UPN suffixes: example.com

La salida muestra que el sufijo UPN de example.com es ahora parte de la entrada del reino ad.example.com.

Capítulo 60. Uso de nombres de host DNS canonizados en IdM

La canonización del DNS está desactivada por defecto en los clientes de gestión de identidades (IdM) para evitar posibles riesgos de seguridad. Por ejemplo, si un atacante controla el servidor DNS y un host en el dominio, el atacante puede hacer que el nombre corto del host demo se resuelva en malicious.example.com. En este caso, el usuario se conecta a un servidor diferente al esperado.

Esta sección describe cómo utilizar los nombres de host canonizados en los clientes IdM.

60.1. Añadir un alias a una entidad de seguridad

Por defecto, los clientes de Gestión de Identidades (IdM) inscritos mediante el comando ipa-client-install no permiten utilizar nombres de host cortos en los principales del servicio. Por ejemplo, los usuarios pueden utilizar sólo host/demo.example.com@EXAMPLE.COM en lugar de host/demo@EXAMPLE.COM al acceder a un servicio.

Esta sección explica cómo añadir un alias a una entidad de seguridad de Kerberos. Tenga en cuenta que también puede activar la canonización de los nombres de host en el archivo /etc/krb5.conf. Para más detalles, consulte Sección 60.2, “Habilitación de la canonización de los nombres de host en los directores de servicio en los clientes”.

Requisitos previos

  • El cliente IdM está instalado.
  • El nombre del host es único en la red.

Procedimiento

  1. Autenticarse en el IdM como usuario de admin:

    $ kinit admin
  2. Añade el alias a la entidad de seguridad del host. Por ejemplo, para añadir el alias demo a la entidad de seguridad del host demo.examle.com:

    $ ipa host-add-principal demo.example.com --principal=demo

60.2. Habilitación de la canonización de los nombres de host en los directores de servicio en los clientes

Esta sección describe cómo habilitar la canonización de los nombres de host en los principales servicios en los clientes.

Tenga en cuenta que si utiliza alias de director de host, como se describe en Sección 60.1, “Añadir un alias a una entidad de seguridad”, no necesita activar la canonización.

Requisitos previos

  • El cliente de gestión de identidades (IdM) está instalado.
  • Ha iniciado la sesión en el cliente IdM como usuario de root.
  • El nombre del host es único en la red.

Procedimiento

  1. Ajuste el parámetro dns_canonicalize_hostname en la sección [libdefaults] del archivo /etc/krb5.conf a false:

    [libdefaults]
    ...
    dns_canonicalize_hostname = true

60.3. Opciones para utilizar nombres de host con la canonización de nombres de host DNS activada

Si establece dns_canonicalize_hostname = true en el archivo /etc/krb5.conf como se explica en Sección 60.2, “Habilitación de la canonización de los nombres de host en los directores de servicio en los clientes”, tiene las siguientes opciones cuando utiliza un nombre de host en un servicio principal:

  • En los entornos de gestión de identidades (IdM), se puede utilizar el nombre de host completo en una entidad de servicio principal, como host/demo.example.com@EXAMPLE.COM.
  • En entornos sin IdM, pero si el host RHEL es miembro de un dominio de Active Directory (AD), no es necesario hacer más consideraciones, porque los controladores de dominio (DC) de AD crean automáticamente los principales de servicio para los nombres NetBIOS de las máquinas inscritas en AD.

Capítulo 61. Gestión de la configuración global de DNS en IdM mediante los playbooks de Ansible

Usando el módulo Red Hat Ansible Engine dnsconfig, puede configurar globalmente el DNS de la Gestión de Identidades (IdM). Los ajustes definidos en la configuración global de DNS se aplican a todos los servidores DNS de IdM. Sin embargo, la configuración global tiene menor prioridad que la configuración para una zona IdM DNS específica.

El módulo dnsconfig admite las siguientes variables:

  • Los reenviadores globales, específicamente sus direcciones IP y el puerto utilizado para la comunicación.
  • La política de reenvío global: solo, primero o ninguno. Para más detalles sobre estos tipos de políticas de reenvío de DNS, véase Políticas de reenvío de DNS en IdM.
  • La sincronización de las zonas de búsqueda directa e inversa.

Requisitos previos


Este capítulo incluye las siguientes secciones:

61.1. Cómo garantiza IdM que los reenviadores globales de /etc/resolv.conf no sean eliminados por NetworkManager

La instalación de Identity Management (IdM) con DNS integrado configura el archivo /etc/resolv.conf para que apunte a la dirección 127.0.0.1 localhost:

# Generated by NetworkManager
search idm.example.com
nameserver 127.0.0.1

En determinados entornos, como las redes que utilizan Dynamic Host Configuration Protocol (DHCP), el servicio NetworkManager puede revertir los cambios en el archivo /etc/resolv.conf. Para que la configuración del DNS sea persistente, el proceso de instalación del DNS de IdM también configura el servicio NetworkManager de la siguiente manera:

  1. El script de instalación de DNS crea un archivo de configuración /etc/NetworkManager/conf.d/zzz-ipa.conf NetworkManager para controlar el orden de búsqueda y la lista de servidores DNS:

    # auto-generated by IPA installer
    [main]
    dns=default
    
    [global-dns]
    searches=$DOMAIN
    
    [global-dns-domain-*]
    servers=127.0.0.1
  2. Se recarga el servicio NetworkManager, que siempre crea el archivo /etc/resolv.conf con la configuración del último archivo del directorio /etc/NetworkManager/conf.d/. Este es en este caso el archivo zzz-ipa.conf.
Importante

No modifique el archivo /etc/resolv.conf manualmente.

61.2. Garantizar la presencia de un reenviador global de DNS en IdM mediante Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la presencia de un reenviador global de DNS en IdM. En el siguiente procedimiento de ejemplo, el administrador de IdM garantiza la presencia de un reenviador global de DNS a un servidor DNS con una dirección de Protocolo de Internet (IP) v4 de 7.7.9.9 y una dirección IP v6 de 2001:db8::1:0 en el puerto 53.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible forwarders-absent.yml. Por ejemplo:

    $ cp forwarders-absent.yml ensure-presence-of-a-global-forwarder.yml
  4. Abra el archivo ensure-presence-of-a-global-forwarder.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to ensure the presence of a global forwarder in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53.
    3. En la sección forwarders de la parte ipadnsconfig:

      1. Cambie el primer valor de ip_address por la dirección IPv4 del reenviador global: 7.7.9.9.
      2. Cambie el segundo valor de ip_address por la dirección IPv6 del reenviador global: 2001:db8::1:0.
      3. Compruebe que el valor de port está ajustado a 53.
    4. Cambie el state a present.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to ensure the presence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 7.7.9.9
            - ip_address: 2001:db8::1:0
              port: 53
          state: present
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-presence-of-a-global-forwarder.yml

61.3. Garantizar la ausencia de un reenviador global de DNS en IdM utilizando Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la ausencia de un reenviador global de DNS en IdM. En el siguiente procedimiento de ejemplo, el administrador de IdM garantiza la ausencia de un reenviador global de DNS a un servidor DNS con una dirección de Protocolo de Internet (IP) v4 de 8.8.6.6 y una dirección IP v6 de 2001:4860:4860::8800 en el puerto 53.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible forwarders-absent.yml. Por ejemplo:

    $ cp forwarders-absent.yml ensure-absence-of-a-global-forwarder.yml
  4. Abra el archivo ensure-absence-of-a-global-forwarder.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to ensure the absence of a global forwarder in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53.
    3. En la sección forwarders de la parte ipadnsconfig:

      1. Cambie el primer valor de ip_address por la dirección IPv4 del reenviador global: 8.8.6.6.
      2. Cambie el segundo valor de ip_address por la dirección IPv6 del reenviador global: 2001:4860:4860::8800.
      3. Compruebe que el valor de port está ajustado a 53.
    4. Compruebe que la dirección state está ajustada a absent.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to ensure the absence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 8.8.6.6
            - ip_address: 2001:4860:4860::8800
              port: 53
          state: absent
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-absence-of-a-global-forwarder.yml

61.4. Políticas de reenvío de DNS en IdM

IdM admite las políticas de reenvío estándar de BIND first y only, así como la política de reenvío específica de IdM none.

Adelante primero (default)
El servicio IdM BIND reenvía las consultas DNS al reenviador configurado. Si una consulta falla debido a un error del servidor o a un tiempo de espera, BIND vuelve a la resolución recursiva utilizando servidores en Internet. La política forward first es la política por defecto, y es adecuada para optimizar el tráfico DNS.
Sólo hacia adelante
El servicio IdM BIND reenvía las consultas DNS al reenviador configurado. Si una consulta falla debido a un error del servidor o a un tiempo de espera, BIND devuelve un error al cliente. La política forward only se recomienda para entornos con configuración de DNS dividida.
Ninguno (forwarding disabled)
Las consultas DNS no se reenvían con la política de reenvío none. Desactivar el reenvío sólo es útil como una anulación específica de zona para la configuración de reenvío global. Esta opción es el equivalente en IdM de especificar una lista vacía de reenvíos en la configuración de BIND.
Nota

No se puede utilizar el reenvío para combinar datos en IdM con datos de otros servidores DNS. Sólo puede reenviar consultas para subzonas específicas de la zona maestra en IdM DNS.

Por defecto, el servicio BIND no reenvía las consultas a otro servidor si el nombre DNS consultado pertenece a una zona para la que el servidor IdM es autoritativo. En este caso, si el nombre DNS consultado no se encuentra en la base de datos de IdM, se devuelve la respuesta NXDOMAIN. No se utiliza el reenvío.

Ejemplo 61.1. Ejemplo de escenario

El servidor IdM es autoritativo para la zona DNS test.example.. BIND está configurado para reenviar las consultas al servidor DNS con la dirección IP 192.0.2.254.

Cuando un cliente envía una consulta para el nombre DNS nonexistent.test.example., BIND detecta que el servidor IdM es autoritativo para la zona test.example. y no reenvía la consulta al servidor 192.0.2.254.. Como resultado, el cliente DNS recibe el mensaje de error NXDomain, informando al usuario de que el dominio consultado no existe.

61.5. Utilizar un libro de jugadas de Ansible para garantizar que la política de "forward first" se establezca en la configuración global de IdM DNS

En esta sección se describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar que la política de reenvío global en el DNS de IdM esté configurada en forward first.

Si utiliza la política de reenvío de DNS forward first, las consultas DNS se reenvían al reenviador configurado. Si una consulta falla debido a un error del servidor o a un tiempo de espera, BIND vuelve a la resolución recursiva utilizando servidores en Internet. La política "forward first" es la política por defecto. Es adecuada para la optimización del tráfico.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible, el host en el que ejecuta el procedimiento. Para obtener más información, consulte Instalación del paquete ansible-freeipa.
  • Conoce la contraseña del administrador de IdM.
  • Su entorno IdM contiene un servidor DNS integrado.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible set-configuration.yml. Por ejemplo:

    $ cp set-configuration.yml set-forward-policy-to-first.yml
  4. Abra el archivo set-forward-policy-to-first.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnsconfig:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable forward_policy en first.

      Elimine todas las demás líneas del playbook original que sean irrelevantes. Este es el archivo de playbook de Ansible modificado para el ejemplo actual:

    ---
    - name: Playbook to set global forwarding policy to first
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Set global forwarding policy to first.
        ipadnsconfig:
          ipaadmin_password: Secret123
          forward_policy: first
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file set-forward-policy-to-first.yml

Recursos adicionales

  • Para obtener más información sobre los tipos de políticas de reenvío disponibles en IdM DNS, consulte Políticas de reenvío de DNS en IdM.
  • Para ver más ejemplos de libros de juego de Ansible que utilizan el módulo ansible-freeipa ipadnsconfig , consulte el archivo Markdown README-dnsconfig.md disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsconfig.
  • Para ver más ejemplos de playbooks de Ansible que utilizan el módulo ipadnsconfig, consulte el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig.

61.6. Uso de un libro de jugadas de Ansible para garantizar que los reenviadores globales estén desactivados en el DNS de IdM

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para asegurarse de que los reenviadores globales están deshabilitados en el DNS de IdM. La deshabilitación se realiza estableciendo la variable forward_policy a none.

La desactivación de los reenvíos globales hace que no se reenvíen las consultas DNS. Desactivar el reenvío sólo es útil como una anulación específica de la zona para la configuración del reenvío global. Esta opción es el equivalente en IdM a especificar una lista vacía de reenvíos en la configuración de BIND.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible, el host en el que ejecuta el procedimiento. Para obtener más información, consulte Instalación del paquete ansible-freeipa.
  • Conoce la contraseña del administrador de IdM.
  • Su entorno IdM contiene un servidor DNS integrado.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible disable-global-forwarders.yml. Por ejemplo:

    $ cp disable-global-forwarders.yml disable-global-forwarders-copy.yml
  4. Abra el archivo disable-global-forwarders-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnsconfig:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable forward_policy en none.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to disable global DNS forwarders
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Disable global forwarders.
        ipadnsconfig:
          ipaadmin_password: Secret123
          forward_policy: none
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file disable-global-forwarders-copy.yml

Recursos adicionales

  • Para obtener más información sobre los tipos de políticas de reenvío disponibles en IdM DNS, consulte Políticas de reenvío de DNS en IdM.
  • Para ver más ejemplos de libros de juego de Ansible que utilizan el módulo ansible-freeipa ipadnsconfig , consulte el archivo Markdown README-dnsconfig.md disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsconfig.
  • Para ver más ejemplos de playbooks de Ansible que utilizan el módulo ipadnsconfig, consulte el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig.

61.7. Utilización de un libro de jugadas de Ansible para garantizar que la sincronización de las zonas de búsqueda directa e inversa esté desactivada en el DNS de IdM

En esta sección se describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar que las zonas de búsqueda directa e inversa no estén sincronizadas en el DNS de IdM.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible, el host en el que ejecuta el procedimiento. Para obtener más información, consulte Instalación del paquete ansible-freeipa.
  • Conoce la contraseña del administrador de IdM.
  • Su entorno IdM contiene un servidor DNS integrado.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible disallow-reverse-sync.yml. Por ejemplo:

    $ cp disallow-reverse-sync.yml disallow-reverse-sync-copy.yml
  4. Abra el archivo disallow-reverse-sync-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnsconfig:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable allow_sync_ptr en no.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to disallow reverse record synchronization
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Disallow reverse record synchronization.
        ipadnsconfig:
          ipaadmin_password: Secret123
          allow_sync_ptr: no
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file disallow-reverse-sync-copy.yml

Recursos adicionales

  • Para ver más ejemplos de libros de juego de Ansible que utilizan el módulo ansible-freeipa ipadnsconfig , consulte el archivo Markdown README-dnsconfig.md disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsconfig.
  • Para ver más ejemplos de playbooks de Ansible que utilizan el módulo ipadnsconfig, consulte el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig.

Capítulo 62. Gestión de zonas DNS en IdM

Como administrador de Identity Management (IdM), puede gestionar el funcionamiento de las zonas DNS de IdM. El capítulo describe los siguientes temas y procedimientos:

Requisitos previos

62.1. Tipos de zonas DNS compatibles

La gestión de identidades (IdM) admite dos tipos de zonas DNS: primary y forward. Esta sección describe estos dos tipos de zonas e incluye un escenario de ejemplo para el reenvío de DNS.

Nota

Esta guía utiliza la terminología de BIND para los tipos de zona, que es diferente de la terminología utilizada para el DNS de Microsoft Windows. Las zonas primarias en BIND tienen el mismo propósito que forward lookup zones y reverse lookup zones en el DNS de Microsoft Windows. Las zonas de reenvío en el BIND tienen el mismo propósito que conditional forwarders en el DNS de Microsoft Windows.

Zonas DNS primarias

Las zonas DNS primarias contienen datos DNS autoritativos y pueden aceptar actualizaciones DNS dinámicas. Este comportamiento es equivalente a la configuración de type master en la configuración estándar de BIND. Puede gestionar las zonas primarias mediante los comandos ipa dnszone-*.

De acuerdo con las reglas estándar del DNS, toda zona primaria debe contener los registros start of authority (SOA) y nameserver (NS). IdM genera estos registros automáticamente cuando se crea la zona DNS, pero debe copiar los registros NS manualmente en la zona primaria para crear una delegación adecuada.

De acuerdo con el comportamiento estándar de BIND, las consultas de nombres para los que el servidor no es autoritativo se reenvían a otros servidores DNS. Estos servidores DNS, llamados forwarders, pueden ser o no autoritarios para la consulta.

Ejemplo 62.1. Ejemplo de escenario para el reenvío de DNS

El servidor IdM contiene la zona maestra test.example.. Esta zona contiene un registro de delegación NS para el nombre sub.test.example.. Además, la zona test.example. está configurada con la dirección IP del reenviador 192.0.2.254 para la subzona sub.text.example.

Un cliente que consulta el nombre nonexistent.test.example. recibe la respuesta NXDomain, y no se produce ningún reenvío porque el servidor IdM es autoritativo para este nombre.

Por otro lado, la consulta del nombre host1.sub.test.example. se reenvía al reenviador configurado 192.0.2.254 porque el servidor IdM no es autoritativo para este nombre.

Reenviar zonas DNS

Desde el punto de vista de IdM, las zonas DNS de reenvío no contienen ningún dato autoritativo. De hecho, una zona de reenvío suele contener sólo dos datos:

  • Un nombre de dominio
  • La dirección IP de un servidor DNS asociado al dominio

Todas las consultas de nombres pertenecientes al dominio definido se reenvían a la dirección IP especificada. Este comportamiento es equivalente a la configuración de type forward en la configuración estándar de BIND. Puede gestionar las zonas de reenvío mediante los comandos ipa dnsforwardzone-*.

Las zonas DNS de reenvío son especialmente útiles en el contexto de los fideicomisos IdM-Active Directory (AD). Si el servidor DNS de IdM es autoritativo para la zona idm.example.com y el servidor DNS de AD es autoritativo para la zona ad.example.com, entonces ad.example.com es una zona de reenvío DNS para la zona primaria idm.example.com. Esto significa que cuando un cliente IdM realiza una consulta sobre la dirección IP de somehost.ad.example.com, la consulta se reenvía a un controlador de dominio AD especificado en la zona de reenvío DNS de IdM ad.example.com.

62.2. Añadir una zona DNS primaria en la interfaz web de IdM

Esta sección describe cómo añadir una zona DNS primaria mediante la interfaz web de gestión de identidades (IdM).

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  1. En la interfaz web de IdM, haga clic en Network ServicesDNSDNS Zones.

    Figura 62.1. Gestión de las zonas primarias del DNS de IdM

    dns master zone management
  2. Haga clic en Añadir en la parte superior de la lista de todas las zonas.
  3. Indique el nombre de la zona.

    Figura 62.2. Introducir una nueva zona primaria de IdM

    dns master zone enter
  4. Haga clic en Añadir.

62.3. Añadir una zona DNS primaria en IdM CLI

Esta sección describe cómo añadir una zona DNS primaria en la interfaz de línea de comandos (CLI) de Identity Management (IdM).

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  • El comando ipa dnszone-add añade una nueva zona al dominio DNS. Para añadir una nueva zona es necesario especificar el nombre del nuevo subdominio. Puede pasar el nombre del subdominio directamente con el comando:

    $ ipa dnszone-add newzone.idm.example.com

    Si no se pasa el nombre a ipa dnszone-add, el script lo pide automáticamente.

Recursos adicionales

  • El comando ipa dnszone-add también acepta varias opciones de línea de comandos. Para obtener una lista completa de estas opciones, ejecute el comando ipa dnszone-add --help.

62.4. Eliminación de una zona DNS primaria en la interfaz web de IdM

En esta sección se describe cómo eliminar una zona DNS primaria de Identity Management (IdM) mediante la interfaz web de IdM.

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  1. En la interfaz web de IdM, haga clic en Network ServicesDNSDNS Zones.
  2. Seleccione la casilla junto al nombre de la zona y haga clic en Eliminar.

    Figura 62.3. Eliminación de una zona DNS maestra

    dns zone delete
  3. En la ventana de diálogo Remove DNS zones, confirme que desea eliminar la zona seleccionada.

62.5. Eliminación de una zona DNS primaria en la CLI de IdM

En esta sección se describe cómo eliminar una zona DNS primaria de Identity Management (IdM) mediante la interfaz de línea de comandos (CLI) de IdM.

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  • Para eliminar una zona DNS primaria, introduzca el comando ipa dnszone-del, seguido del nombre de la zona que desea eliminar. Por ejemplo:

    $ ipa dnszone-del idm.example.com

62.6. Prioridades de configuración del DNS

Puede configurar muchas opciones de configuración de DNS en tres niveles diferentes. Cada nivel tiene una prioridad diferente.

Configuración específica de la zona
El nivel de configuración específico para una zona concreta definida en IdM tiene la máxima prioridad. Puede gestionar la configuración específica de una zona mediante los comandos ipa dnszone-* y ipa dnsforwardzone-*.
Configuración global del DNS
Si no se define una configuración específica de zona, IdM utiliza la configuración global de DNS almacenada en LDAP. Puede gestionar la configuración global de DNS mediante los comandos ipa dnsconfig-*. Los ajustes definidos en la configuración global de DNS se aplican a todos los servidores DNS de IdM.
Configuración en /etc/named.conf

La configuración definida en el archivo /etc/named.conf de cada servidor DNS de IdM tiene la menor prioridad. Es específica para cada servidor y debe editarse manualmente.

El archivo /etc/named.conf normalmente sólo se utiliza para especificar el reenvío de DNS a una caché DNS local. Las demás opciones se gestionan mediante los comandos de configuración de DNS global y de zona mencionados anteriormente.

Puede configurar las opciones de DNS en varios niveles al mismo tiempo. En estos casos, la configuración con mayor prioridad tiene prioridad sobre la configuración definida en niveles inferiores.

62.7. Atributos de configuración de las zonas DNS primarias de IdM

Identity Management (IdM) crea una nueva zona con cierta configuración por defecto, como los períodos de actualización, la configuración de transferencia o la configuración de la caché. En los atributos de zona DNS de IdM, puede encontrar los atributos de la configuración de zona por defecto que puede modificar utilizando una de las siguientes opciones:

Además de establecer la información real de la zona, la configuración define cómo el servidor DNS maneja las entradas del registro start of authority (SOA) y cómo actualiza sus registros desde el servidor de nombres DNS.

Tabla 62.1. Atributos de la zona IdM DNS

AtributoOpción de línea de comandosDescripción

Servidor de nombres autorizado

--name-server

Establece el nombre de dominio del servidor de nombres DNS maestro, también conocido como SOA MNAME.

Por defecto, cada servidor IdM se anuncia en el campo SOA MNAME. En consecuencia, se ignora el valor almacenado en LDAP mediante --name-server.

Dirección de correo electrónico del administrador

--admin-email

Establece la dirección de correo electrónico que se utilizará para el administrador de la zona. El valor predeterminado es la cuenta raíz del host.

Serie SOA

--serial

Establece un número de serie en el registro SOA. Tenga en cuenta que IdM establece el número de versión automáticamente y no se espera que los usuarios lo modifiquen.

Actualización de la SOA

--refresh

Establece el intervalo, en segundos, que debe esperar un servidor DNS secundario antes de solicitar actualizaciones al servidor DNS primario.

Reintento de SOA

--retry

Establece el tiempo, en segundos, que se debe esperar antes de reintentar una operación de actualización fallida.

La SOA caduca

--expire

Establece el tiempo, en segundos, que un servidor DNS secundario intentará realizar una actualización antes de finalizar el intento de operación.

Mínimo del SOA

--minimum

Establece el valor del tiempo de vida (TTL) en segundos para el almacenamiento en caché negativo según el RFC 2308.

Tiempo de vida de la SOA

--ttl

Establece el TTL en segundos para los registros en el vértice de la zona. En la zona example.com, por ejemplo, se configuran todos los registros (A, NS o SOA) bajo el nombre example.com, pero no se ven afectados otros nombres de dominio, como test.example.com.

Tiempo de vida por defecto

--default-ttl

Establece el valor predeterminado del tiempo de vida (TTL) en segundos para el almacenamiento en caché negativo de todos los valores de una zona que nunca tuvo un valor TTL individual establecido anteriormente. Requiere un reinicio del servicio named-pkcs11 en todos los servidores DNS IdM después de los cambios para que surtan efecto.

Política de actualización de BIND

--update-policy

Establece los permisos permitidos a los clientes en la zona DNS.

Actualización dinámica

--dynamic-update=TRUE|FALSE

Permite la actualización dinámica de los registros DNS de los clientes.

Tenga en cuenta que si esto se establece en falso, las máquinas cliente de IdM no podrán añadir o actualizar su dirección IP.

Permitir la transferencia

--allow-transfer=string

Proporciona una lista de direcciones IP o nombres de red que pueden transferir la zona dada, separados por punto y coma (;).

Las transferencias de zona están desactivadas por defecto. El valor por defecto de --allow-transfer es none.

Permitir consulta

--allow-query

Proporciona una lista de direcciones IP o nombres de red que pueden emitir consultas DNS, separadas por punto y coma (;).

Permitir la sincronización PTR

--allow-sync-ptr=1|0

Establece si los registros A o AAAA (registros directos) de la zona se sincronizarán automáticamente con los registros PTR (inversos).

Transportistas de zona

--forwarder=IP_address

Especifica un reenviador configurado específicamente para la zona DNS. Esto es independiente de cualquier reenviador global utilizado en el dominio IdM.

Para especificar varios reenviadores, utilice la opción varias veces.

Política de futuro

--forward-policy=ninguna|sólo|primera

Especifica la política de reenvío. Para obtener información sobre las políticas admitidas, consulte Políticas de reenvío de DNS en IdM.

62.8. Edición de la configuración de una zona DNS primaria en la interfaz web de IdM

Esta sección describe cómo editar los atributos de configuración de un DNS primario de gestión de identidades (IdM) mediante la interfaz web de IdM.

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  1. En la interfaz web de IdM, haga clic en Network ServicesDNSDNS Zones.

    Figura 62.4. Gestión de las zonas primarias del DNS

    dns master zone management
  2. En la sección DNS Zones, haga clic en el nombre de la zona en la lista de todas las zonas para abrir la página de la zona DNS.

    Figura 62.5. Editar una zona primaria

    dns master zone edit
  3. Haga clic en Settings.

    Figura 62.6. La pestaña de configuración en la página de edición de la zona primaria

    dns master zone page
  4. Cambie la configuración de la zona según sea necesario.

    Para obtener información sobre los ajustes disponibles, consulte Atributos de zona DNS de IdM.

  5. Haga clic en Guardar para confirmar la nueva configuración.

    Nota

    Si va a cambiar el tiempo de vida (TTL) por defecto de una zona, reinicie el servicio named-pkcs11 en todos los servidores DNS de IdM para que los cambios surtan efecto. Todos los demás ajustes se activan automáticamente de forma inmediata.

62.9. Edición de la configuración de una zona DNS primaria en la CLI de IdM

Esta sección describe cómo editar la configuración de una zona DNS primaria mediante la interfaz de línea de comandos (CLI) de Identity Management (IdM).

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  • Para modificar una zona DNS primaria existente, utilice el comando ipa dnszone-mod. Por ejemplo, para establecer el tiempo de espera antes de reintentar una operación de actualización fallida en 1800 segundos:

    $ ipa dnszone-mod --retry 1800

    Para obtener más información sobre los ajustes disponibles y sus correspondientes opciones de la CLI, consulte Atributos de zona DNS de IdM.

    Si una configuración específica no tiene un valor en la entrada de zona DNS que está modificando, el comando ipa dnszone-mod añade el valor. Si el ajuste no tiene un valor, el comando sobrescribe el valor actual con el valor especificado.

    Nota

    Si va a cambiar el tiempo de vida (TTL) por defecto de una zona, reinicie el servicio named-pkcs11 en todos los servidores DNS de IdM para que los cambios surtan efecto. Todos los demás ajustes se activan automáticamente de forma inmediata.

Recursos adicionales

  • Para obtener información detallada sobre ipa dnszone-mod y sus opciones, ejecute el comando ipa dnszone-mod --help.

62.10. Transferencia de zonas en IdM

Esta sección describe cómo funcionan las transferencias de zona en una implementación de Gestión de Identidades (IdM) que ha integrado el DNS.

Los servidores de nombres mantienen datos autoritativos para sus zonas. Si realiza cambios en la zona de un servidor DNS que es autoritativo para la zona DNS de zone A, debe distribuir los cambios entre los demás servidores de nombres del dominio DNS de IdM que están fuera de zone A. Un zone transfer copia todos los registros de recursos de un servidor de nombres a otro.

Importante

El DNS integrado en IdM puede ser escrito por diferentes servidores simultáneamente. Los números de serie de Start of Authority (SOA) en las zonas IdM no están sincronizados entre los servidores DNS individuales de IdM. Por este motivo, configure sus servidores DNS fuera de la zona a transferir para que sólo utilicen un servidor DNS específico dentro de la zona a transferir. De este modo, se evitan los fallos de transferencia de zona causados por números de serie SOA no sincronizados.

IdM admite las transferencias de zona según los estándares RFC 5936 (AXFR) y RFC 1995 (IXFR).

Recursos adicionales

62.11. Activación de las transferencias de zona en la interfaz web de IdM

En esta sección se describe cómo habilitar las transferencias de zona en la Gestión de identidades (IdM) mediante la interfaz web de IdM.

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  1. En la interfaz web de IdM, haga clic en Network ServicesDNSDNS Zones.
  2. Haga clic en Settings.
  3. En Allow transfer, especifique los servidores de nombres a los que desea transferir los registros de zona.

    Figura 62.7. Habilitación de las transferencias de zona

    dns allow transfer
  4. Haga clic en Guardar en la parte superior de la página de la zona DNS para confirmar la nueva configuración.

62.12. Habilitación de las transferencias de zona en IdM CLI

En esta sección se describe cómo habilitar las transferencias de zona en Identity Management (IdM) mediante la interfaz de línea de comandos (CLI) de IdM.

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.
  • Tiene acceso de root a los servidores DNS secundarios.

Procedimiento

  • Para habilitar las transferencias de zona en el servicio BIND, introduzca el comando ipa dnszone-mod, y especifique la lista de servidores de nombres que están fuera de la zona a transferir a la que se transferirán los registros de zona utilizando la opción --allow-transfer. Por ejemplo:

    $ ipa dnszone-mod --allow-transfer=192.0.2.1;198.51.100.1;203.0.113.1 idm.example.com

Pasos de verificación

  1. SSH a uno de los servidores DNS a los que se ha habilitado la transferencia de zonas:

    $ ssh 192.0.2.1
  2. Transfiera la zona DNS IdM utilizando una herramienta como la utilidad dig:

    # dig @ipa-server zone_name AXFR

Si el comando no devuelve ningún error, ha habilitado con éxito la transferencia de zonas para zone_name.

62.13. Recursos adicionales

Capítulo 63. Utilización de los playbooks de Ansible para gestionar las zonas DNS de IdM

Como administrador de Identity Management (IdM), puede gestionar el funcionamiento de las zonas DNS de IdM mediante el módulo dnszone disponible en el paquete ansible-freeipa. El capítulo describe los siguientes temas y procedimientos:

Requisitos previos

63.1. Tipos de zonas DNS compatibles

La gestión de identidades (IdM) admite dos tipos de zonas DNS: primary y forward. Esta sección describe estos dos tipos de zonas e incluye un escenario de ejemplo para el reenvío de DNS.

Nota

Esta guía utiliza la terminología de BIND para los tipos de zona, que es diferente de la terminología utilizada para el DNS de Microsoft Windows. Las zonas primarias en BIND tienen el mismo propósito que forward lookup zones y reverse lookup zones en el DNS de Microsoft Windows. Las zonas de reenvío en el BIND tienen el mismo propósito que conditional forwarders en el DNS de Microsoft Windows.

Zonas DNS primarias

Las zonas DNS primarias contienen datos DNS autoritativos y pueden aceptar actualizaciones DNS dinámicas. Este comportamiento es equivalente a la configuración de type master en la configuración estándar de BIND. Puede gestionar las zonas primarias mediante los comandos ipa dnszone-*.

De acuerdo con las reglas estándar del DNS, toda zona primaria debe contener los registros start of authority (SOA) y nameserver (NS). IdM genera estos registros automáticamente cuando se crea la zona DNS, pero debe copiar los registros NS manualmente en la zona primaria para crear una delegación adecuada.

De acuerdo con el comportamiento estándar de BIND, las consultas de nombres para los que el servidor no es autoritativo se reenvían a otros servidores DNS. Estos servidores DNS, llamados forwarders, pueden ser o no autoritarios para la consulta.

Ejemplo 63.1. Ejemplo de escenario para el reenvío de DNS

El servidor IdM contiene la zona maestra test.example.. Esta zona contiene un registro de delegación NS para el nombre sub.test.example.. Además, la zona test.example. está configurada con la dirección IP del reenviador 192.0.2.254 para la subzona sub.text.example.

Un cliente que consulta el nombre nonexistent.test.example. recibe la respuesta NXDomain, y no se produce ningún reenvío porque el servidor IdM es autoritativo para este nombre.

Por otro lado, la consulta del nombre host1.sub.test.example. se reenvía al reenviador configurado 192.0.2.254 porque el servidor IdM no es autoritativo para este nombre.

Reenviar zonas DNS

Desde el punto de vista de IdM, las zonas DNS de reenvío no contienen ningún dato autoritativo. De hecho, una zona de reenvío suele contener sólo dos datos:

  • Un nombre de dominio
  • La dirección IP de un servidor DNS asociado al dominio

Todas las consultas de nombres pertenecientes al dominio definido se reenvían a la dirección IP especificada. Este comportamiento es equivalente a la configuración de type forward en la configuración estándar de BIND. Puede gestionar las zonas de reenvío mediante los comandos ipa dnsforwardzone-*.

Las zonas DNS de reenvío son especialmente útiles en el contexto de los fideicomisos IdM-Active Directory (AD). Si el servidor DNS de IdM es autoritativo para la zona idm.example.com y el servidor DNS de AD es autoritativo para la zona ad.example.com, entonces ad.example.com es una zona de reenvío DNS para la zona primaria idm.example.com. Esto significa que cuando un cliente IdM realiza una consulta sobre la dirección IP de somehost.ad.example.com, la consulta se reenvía a un controlador de dominio AD especificado en la zona de reenvío DNS de IdM ad.example.com.

63.2. Atributos de configuración de las zonas DNS primarias de IdM

Identity Management (IdM) crea una nueva zona con cierta configuración por defecto, como los períodos de actualización, la configuración de transferencia o la configuración de la caché. En los atributos de zona DNS de IdM, puede encontrar los atributos de la configuración de zona por defecto que puede modificar utilizando una de las siguientes opciones:

Además de establecer la información real de la zona, la configuración define cómo el servidor DNS maneja las entradas del registro start of authority (SOA) y cómo actualiza sus registros desde el servidor de nombres DNS.

Tabla 63.1. Atributos de la zona IdM DNS

Atributoansible-freeipa variableDescripción

Servidor de nombres autorizado

name_server

Establece el nombre de dominio del servidor de nombres DNS maestro, también conocido como SOA MNAME.

Por defecto, cada servidor IdM se anuncia en el campo SOA MNAME. En consecuencia, se ignora el valor almacenado en LDAP mediante --name-server.

Dirección de correo electrónico del administrador

admin_email

Establece la dirección de correo electrónico que se utilizará para el administrador de la zona. El valor predeterminado es la cuenta raíz del host.

Serie SOA

serial

Establece un número de serie en el registro SOA. Tenga en cuenta que IdM establece el número de versión automáticamente y no se espera que los usuarios lo modifiquen.

Actualización de la SOA

refresh

Establece el intervalo, en segundos, que debe esperar un servidor DNS secundario antes de solicitar actualizaciones al servidor DNS primario.

Reintento de SOA

retry

Establece el tiempo, en segundos, que se debe esperar antes de reintentar una operación de actualización fallida.

La SOA caduca

expire

Establece el tiempo, en segundos, que un servidor DNS secundario intentará realizar una actualización antes de finalizar el intento de operación.

Mínimo del SOA

minimum

Establece el valor del tiempo de vida (TTL) en segundos para el almacenamiento en caché negativo según el RFC 2308.

Tiempo de vida de la SOA

ttl

Establece el TTL en segundos para los registros en el vértice de la zona. En la zona example.com, por ejemplo, se configuran todos los registros (A, NS o SOA) bajo el nombre example.com, pero no se ven afectados otros nombres de dominio, como test.example.com.

Tiempo de vida por defecto

default_ttl

Establece el valor predeterminado del tiempo de vida (TTL) en segundos para el almacenamiento en caché negativo de todos los valores de una zona que nunca tuvo un valor TTL individual establecido anteriormente. Requiere un reinicio del servicio named-pkcs11 en todos los servidores DNS IdM después de los cambios para que surtan efecto.

Política de actualización de BIND

update_policy

Establece los permisos permitidos a los clientes en la zona DNS.

Actualización dinámica

dynamic_update=TRUE|FALSE

Permite la actualización dinámica de los registros DNS de los clientes.

Tenga en cuenta que si esto se establece en falso, las máquinas cliente de IdM no podrán añadir o actualizar su dirección IP.

Permitir la transferencia

allow_transfer=string

Proporciona una lista de direcciones IP o nombres de red que pueden transferir la zona dada, separados por punto y coma (;).

Las transferencias de zona están desactivadas por defecto. El valor por defecto de allow_transfer es none.

Permitir consulta

allow_query

Proporciona una lista de direcciones IP o nombres de red que pueden emitir consultas DNS, separadas por punto y coma (;).

Permitir la sincronización PTR

allow_sync_ptr=1|0

Establece si los registros A o AAAA (registros directos) de la zona se sincronizarán automáticamente con los registros PTR (inversos).

Transportistas de zona

forwarder=IP_address

Especifica un reenviador configurado específicamente para la zona DNS. Esto es independiente de cualquier reenviador global utilizado en el dominio IdM.

Para especificar varios reenviadores, utilice la opción varias veces.

Política de futuro

forward_policy=ninguna|sólo|primera

Especifica la política de reenvío. Para obtener información sobre las políticas admitidas, consulte Políticas de reenvío de DNS en IdM.

Recursos adicionales

  • Puede ver más definiciones de los atributos del módulo ansible-freeipa ipadnszone en el archivo Markdown README-dnszone.md disponible en el directorio /usr/share/doc/ansible-freeipa/.

63.3. Uso de Ansible para crear una zona primaria en IdM DNS

Esta sección muestra cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la existencia de una zona DNS primaria. En el ejemplo utilizado en el procedimiento siguiente, un administrador de IdM garantiza la presencia de la zona DNS zone.idm.example.com.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnszone:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible dnszone-present.yml. Por ejemplo:

    $ cp dnszone-present.yml dnszone-present-copy.yml
  4. Abra el archivo dnszone-present-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnszone:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable zone_name en zone.idm.example.com.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Ensure dnszone present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure zone is present.
        ipadnszone:
          ipaadmin_password: Secret123
          zone_name: zone.idm.example.com
          state: present
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file dnszone-present-copy.yml

Recursos adicionales

  • Para más información sobre la zona DNS, consulte Tipos de zona DNS soportados.
  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnszone en el archivo README-dnszone.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnszone.
  • Puede ver ejemplos de playbooks de Ansible para el módulo ipadnszone en el directorio /usr/share/doc/ansible-freeipa/playbooks/dnszone.

63.4. Uso de un playbook de Ansible para asegurar la presencia de una zona DNS primaria en IdM con múltiples variables

Esta sección muestra cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la existencia de una zona DNS primaria. En el ejemplo utilizado en el procedimiento siguiente, un administrador de IdM garantiza la presencia de la zona DNS zone.idm.example.com. El libro de jugadas de Ansible configura varios parámetros de la zona.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnszone:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible dnszone-all-params.yml. Por ejemplo:

    $ cp dnszone-all-params.yml dnszone-all-params-copy.yml
  4. Abra el archivo dnszone-all-params-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnszone:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable zone_name en zone.idm.example.com.
    • Establezca la variable allow_sync_ptr en true si desea permitir la sincronización de los registros hacia adelante y hacia atrás, es decir, la sincronización de los registros A y AAAA con los registros PTR.
    • Establezca la variable dynamic_update en true para permitir que los equipos cliente de IdM añadan o actualicen sus direcciones IP.
    • Establezca la variable dnssec en true para permitir la firma DNSSEC en línea de los registros de la zona.
    • Establezca la variable allow_transfer con las direcciones IP de los servidores de nombres secundarios de la zona.
    • Establezca la variable allow_query con las direcciones IP o redes que están autorizadas a emitir consultas.
    • Establezca la variable forwarders con las direcciones IP de los reenviadores globales.
    • Establezca la variable serial con el número de serie del registro SOA.
    • Defina los valores refresh, retry, expire, minimum, ttl, y default_ttl para los registros DNS de la zona.
    • Defina el registro NSEC3PARAM para la zona utilizando la variable nsec3param_rec.
    • Establezca la variable skip_overlap_check en true para forzar la creación del DNS incluso si se solapa con una zona existente.
    • Establezca skip_nameserver_check en true para forzar la creación de la zona DNS incluso si el servidor de nombres no es resoluble.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Ensure dnszone present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure zone is present.
        ipadnszone:
          ipaadmin_password: Secret123
          zone_name: zone.idm.example.com
          allow_sync_ptr: true
          dynamic_update: true
          dnssec: true
          allow_transfer:
            - 1.1.1.1
            - 2.2.2.2
          allow_query:
            - 1.1.1.1
            - 2.2.2.2
          forwarders:
            - ip_address: 8.8.8.8
            - ip_address: 8.8.4.4
              port: 52
          serial: 1234
          refresh: 3600
          retry: 900
          expire: 1209600
          minimum: 3600
          ttl: 60
          default_ttl: 90
          name_server: server.idm.example.com.
          admin_email: admin.admin@idm.example.com
          nsec3param_rec: "1 7 100 0123456789abcdef"
          skip_overlap_check: true
          skip_nameserver_check: true
          state: present
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file dnszone-all-params-copy.yml

Recursos adicionales

  • Para más información sobre la zona DNS, consulte Tipos de zona DNS soportados.
  • Para obtener más información sobre los atributos de zona DNS que puede configurar en IdM, consulte Atributos de configuración de las zonas DNS primarias de IdM.
  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnszone en el archivo README-dnszone.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnszone.
  • Puede ver ejemplos de playbooks de Ansible para el módulo ipadnszone en el directorio /usr/share/doc/ansible-freeipa/playbooks/dnszone.

63.5. Uso de un playbook de Ansible para asegurar la presencia de una zona para la búsqueda inversa de DNS cuando se da una dirección IP

Esta sección muestra cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la existencia de una zona DNS inversa. En el ejemplo utilizado en el procedimiento siguiente, un administrador de IdM asegura la presencia de una zona de búsqueda DNS inversa utilizando la dirección IP y la longitud del prefijo de un host de IdM.

Proporcionar la longitud del prefijo de la dirección IP de su servidor DNS mediante la variable name_from_ip le permite controlar el nombre de la zona. Si no indica la longitud del prefijo, el sistema consulta a los servidores DNS en busca de zonas y, basándose en el valor name_from_ip de 192.168.1.2, la consulta puede devolver cualquiera de las siguientes zonas DNS:

  • 1.168.192.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 192.in-addr.arpa.

Dado que la zona devuelta por la consulta podría no ser la esperada, name_from_ip sólo puede utilizarse con la opción state establecida en present para evitar la eliminación accidental de zonas.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnszone:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible dnszone-reverse-from-ip.yml. Por ejemplo:

    $ cp dnszone-reverse-from-ip.yml dnszone-reverse-from-ip-copy.yml
  4. Abra el archivo dnszone-reverse-from-ip-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnszone:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable name_from_ip con la IP de su servidor de nombres IdM y proporcione su longitud de prefijo.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

      ---
      - name: Ensure dnszone present
        hosts: ipaserver
        become: true
      
        tasks:
        - name: Ensure zone for reverse DNS lookup is present.
          ipadnszone:
            ipaadmin_password: Secret123
            name_from_ip: 192.168.1.2/24
            state: present
          register: result
        - name: Display inferred zone name.
          debug:
            msg: "Zone name: {{ result.dnszone.name }}"

    El libro de jugadas crea una zona para la búsqueda inversa de DNS a partir de la dirección IP 192.168.1.2 y su longitud de prefijo de 24. A continuación, el libro de jugadas muestra el nombre de la zona resultante.

  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file dnszone-reverse-from-ip-copy.yml

Recursos adicionales

  • Para más información sobre la zona DNS, consulte Tipos de zona DNS soportados.
  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnszone en el archivo README-dnszone.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnszone.
  • Puede ver ejemplos de playbooks de Ansible para el módulo ipadnszone en el directorio /usr/share/doc/ansible-freeipa/playbooks/dnszone.

Capítulo 64. Gestión del reenvío de DNS en IdM

Los siguientes procedimientos describen cómo configurar los reenviadores globales de DNS y las zonas de reenvío de DNS en la interfaz web de Identity Management (IdM), la CLI de IdM y mediante Ansible:

64.1. Las dos funciones de un servidor DNS IdM

El reenvío de DNS afecta a la forma en que un servicio DNS responde a las consultas DNS. Por defecto, el servicio Berkeley Internet Name Domain (BIND) integrado en IdM actúa como servidor DNS authoritative y recursive:

Servidor DNS autorizado
Cuando un cliente DNS consulta un nombre perteneciente a una zona DNS para la que el servidor IdM es autoritativo, BIND responde con los datos contenidos en la zona configurada. Los datos autoritativos siempre tienen prioridad sobre cualquier otro dato.
Servidor DNS recursivo
Cuando un cliente DNS consulta un nombre para el que el servidor IdM no es autoritativo, BIND intenta resolver la consulta utilizando otros servidores DNS. Si no se definen reenviadores, BIND pregunta a los servidores raíz de Internet y utiliza un algoritmo de resolución recursiva para responder a la consulta DNS.

En algunos casos, no es deseable dejar que el BIND contacte directamente con otros servidores DNS y realice la recursión basándose en los datos disponibles en Internet. Puede configurar el BIND para que utilice otro servidor DNS, un forwarder, para resolver la consulta.

Cuando se configura BIND para utilizar un reenviador, las consultas y respuestas se reenvían de un lado a otro entre el servidor IdM y el reenviador, y el servidor IdM actúa como caché de DNS para los datos no autorizados.

64.2. Políticas de reenvío de DNS en IdM

IdM admite las políticas de reenvío estándar de BIND first y only, así como la política de reenvío específica de IdM none.

Adelante primero (default)
El servicio IdM BIND reenvía las consultas DNS al reenviador configurado. Si una consulta falla debido a un error del servidor o a un tiempo de espera, BIND vuelve a la resolución recursiva utilizando servidores en Internet. La política forward first es la política por defecto, y es adecuada para optimizar el tráfico DNS.
Sólo hacia adelante
El servicio IdM BIND reenvía las consultas DNS al reenviador configurado. Si una consulta falla debido a un error del servidor o a un tiempo de espera, BIND devuelve un error al cliente. La política forward only se recomienda para entornos con configuración de DNS dividida.
Ninguno (forwarding disabled)
Las consultas DNS no se reenvían con la política de reenvío none. Desactivar el reenvío sólo es útil como una anulación específica de zona para la configuración de reenvío global. Esta opción es el equivalente en IdM de especificar una lista vacía de reenvíos en la configuración de BIND.
Nota

No se puede utilizar el reenvío para combinar datos en IdM con datos de otros servidores DNS. Sólo puede reenviar consultas para subzonas específicas de la zona maestra en IdM DNS.

Por defecto, el servicio BIND no reenvía las consultas a otro servidor si el nombre DNS consultado pertenece a una zona para la que el servidor IdM es autoritativo. En este caso, si el nombre DNS consultado no se encuentra en la base de datos de IdM, se devuelve la respuesta NXDOMAIN. No se utiliza el reenvío.

Ejemplo 64.1. Ejemplo de escenario

El servidor IdM es autoritativo para la zona DNS test.example.. BIND está configurado para reenviar las consultas al servidor DNS con la dirección IP 192.0.2.254.

Cuando un cliente envía una consulta para el nombre DNS nonexistent.test.example., BIND detecta que el servidor IdM es autoritativo para la zona test.example. y no reenvía la consulta al servidor 192.0.2.254.. Como resultado, el cliente DNS recibe el mensaje de error NXDomain, informando al usuario de que el dominio consultado no existe.

64.3. Añadir un reenvío global en la interfaz web de IdM

En esta sección se describe cómo añadir un reenviador DNS global en la interfaz web de gestión de identidades (IdM).

Requisitos previos

  • Has iniciado sesión en la WebUI de IdM como administrador de IdM.
  • Conoce la dirección del Protocolo de Internet (IP) del servidor DNS al que se deben reenviar las consultas.

Procedimiento

  1. En la interfaz web de IdM, seleccione Network ServicesDNS Global ConfigurationDNS.

    Selecting DNS Forward Zones from the DNS menu
  2. En la sección DNS Global Configuration, haga clic en Add.

    Selecting the Add button
  3. Especifique la dirección IP del servidor DNS que recibirá las consultas DNS reenviadas.

    Entering the IP address of the global forwarder
  4. Seleccione la dirección Forward policy.

    Selecting the DNS forward policy and saving the DNS global configuration
  5. Haga clic en Save en la parte superior de la ventana.

Pasos de verificación

  1. Seleccione Network ServicesDNS Global ConfigurationDNS.

    Selecting DNS Global Configuration in IdM Web UI
  2. Compruebe que el reenvío global, con la política de reenvío que ha especificado, está presente y activado en la interfaz web de IdM.

    Verifying the presence of the global forwarder

64.4. Añadir un forwarder global en la CLI

Esta sección describe cómo añadir un reenviador DNS global desde la interfaz de línea de comandos (CLI).

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.
  • Conoce la dirección del Protocolo de Internet (IP) del servidor DNS al que se deben reenviar las consultas.

Procedimiento

  • Utilice el comando ipa dnsconfig-mod para añadir un nuevo reenviador global. Especifique la dirección IP del reenviador DNS con la opción --forwarder.

    [user@server ~]$ ipa dnsconfig-mod --forwarder=10.10.0.1
    Server will check DNS forwarder(s).
    This may take some time, please wait ...
      Global forwarders: 10.10.0.1
      IPA DNS servers: server.example.com

Pasos de verificación

  • Utilice el comando dnsconfig-show para mostrar los reenviadores globales.

    [user@server ~]$ ipa dnsconfig-show
      Global forwarders: 10.10.0.1
      IPA DNS servers: server.example.com

64.5. Añadir una zona de reenvío de DNS en la interfaz web de IdM

Esta sección describe cómo añadir una zona de reenvío de DNS en la interfaz web de gestión de identidades (IdM).

Importante

No utilice zonas de reenvío a menos que sea absolutamente necesario. Las zonas de reenvío no son una solución estándar y su uso puede dar lugar a comportamientos inesperados y problemáticos. Si debe utilizar zonas de reenvío, limítese a anular una configuración de reenvío global.

Al crear una nueva zona DNS, Red Hat recomienda utilizar siempre la delegación DNS estándar utilizando registros de servidor de nombres (NS) y evitar las zonas de reenvío. En la mayoría de los casos, el uso de un reenviador global es suficiente y las zonas de reenvío no son necesarias.

Requisitos previos

  • Has iniciado sesión en la WebUI de IdM como administrador de IdM.
  • Conoce la dirección del Protocolo de Internet (IP) del servidor DNS al que se deben reenviar las consultas.

Procedimiento

  1. En la interfaz web de IdM, seleccione Network ServicesDNS Forward ZonesDNS.

    Selecting DNS Forward Zones from the DNS menu
  2. En la sección DNS Forward Zones, haga clic en Add.

    Selecting the Add button
  3. En la ventana Add DNS forward zone, especifique el nombre de la zona de reenvío.

    Entering the name of the new Forward Zone
  4. Haga clic en el botón Add y especifique la dirección IP de un servidor DNS para recibir la solicitud de reenvío. Puede especificar varios reenviadores por zona de reenvío.

    Specifying the IP address of the forwarder DNS server
  5. Seleccione la dirección Forward policy.

    Choosing a Forward policy
  6. Haga clic en Add en la parte inferior de la ventana para añadir la nueva zona de reenvío.

Pasos de verificación

  1. En la interfaz web de IdM, seleccione Network ServicesDNS Forward ZonesDNS.

    Selecting DNS Forward Zones from the DNS menu
  2. Compruebe que la zona de reenvío que ha creado, con los reenviadores y la política de reenvío que ha especificado, está presente y habilitada en la interfaz web de IdM.

    Verifying the new forward zone is present

64.6. Añadir una zona de reenvío de DNS en la CLI

Esta sección describe cómo añadir una zona de reenvío DNS desde la interfaz de línea de comandos (CLI).

Importante

No utilice zonas de reenvío a menos que sea absolutamente necesario. Las zonas de reenvío no son una solución estándar y su uso puede dar lugar a comportamientos inesperados y problemáticos. Si debe utilizar zonas de reenvío, limítese a anular una configuración de reenvío global.

Al crear una nueva zona DNS, Red Hat recomienda utilizar siempre la delegación DNS estándar utilizando registros de servidor de nombres (NS) y evitar las zonas de reenvío. En la mayoría de los casos, el uso de un reenviador global es suficiente y las zonas de reenvío no son necesarias.

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.
  • Conoce la dirección del Protocolo de Internet (IP) del servidor DNS al que se deben reenviar las consultas.

Procedimiento

  • Utilice el comando dnsforwardzone-add para añadir una nueva zona de reenvío. Especifique al menos un reenvío con la opción --forwarder si la política de reenvío no es none, y especifique la política de reenvío con la opción --forward-policy.

    [user@server ~]$ ipa dnsforwardzone-add forward.example.com. --forwarder=10.10.0.14 --forwarder=10.10.1.15 --forward-policy=first
    
    Zone name: forward.example.com.
    Zone forwarders: 10.10.0.14, 10.10.1.15
    Forward policy: first

Pasos de verificación

  • Utilice el comando dnsforwardzone-show para mostrar la zona de reenvío DNS que acaba de crear.

    [user@server ~]$ ipa dnsforwardzone-show forward.example.com.
    
    Zone name: forward.example.com.
    Zone forwarders: 10.10.0.14, 10.10.1.15
    Forward policy: first

64.7. Establecimiento de un reenvío global de DNS en IdM mediante Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para establecer un DNS Global Forwarder en IdM.

En el siguiente procedimiento de ejemplo, el administrador de IdM crea un reenvío global de DNS a un servidor DNS con una dirección de Protocolo de Internet (IP) v4 de 8.8.6.6 y una dirección IPv6 de 2001:4860:4860::8800 en el puerto 53.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible set-configuration.yml. Por ejemplo:

    $ cp set-configuration.yml establish-global-forwarder.yml
  4. Abra el archivo establish-global-forwarder.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to establish a global forwarder in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Create a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800.
    3. En la sección forwarders de la parte ipadnsconfig:

      1. Cambie el primer valor de ip_address por la dirección IPv4 del reenviador global: 8.8.6.6.
      2. Cambie el segundo valor de ip_address por la dirección IPv6 del reenviador global: 2001:4860:4860::8800.
      3. Compruebe que el valor de port está ajustado a 53.
    4. Cambie el forward_policy a first.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to establish a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800
        ipadnsconfig:
          forwarders:
            - ip_address: 8.8.6.6
            - ip_address: 2001:4860:4860::8800
              port: 53
          forward_policy: first
          allow_sync_ptr: yes
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file establish-global-forwarder.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsconfig en el archivo README-dnsconfig.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsconfig.

64.8. Garantizar la presencia de un reenviador global de DNS en IdM mediante Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la presencia de un reenviador global de DNS en IdM. En el siguiente procedimiento de ejemplo, el administrador de IdM garantiza la presencia de un reenviador global de DNS a un servidor DNS con una dirección de Protocolo de Internet (IP) v4 de 7.7.9.9 y una dirección IP v6 de 2001:db8::1:0 en el puerto 53.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible forwarders-absent.yml. Por ejemplo:

    $ cp forwarders-absent.yml ensure-presence-of-a-global-forwarder.yml
  4. Abra el archivo ensure-presence-of-a-global-forwarder.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to ensure the presence of a global forwarder in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53.
    3. En la sección forwarders de la parte ipadnsconfig:

      1. Cambie el primer valor de ip_address por la dirección IPv4 del reenviador global: 7.7.9.9.
      2. Cambie el segundo valor de ip_address por la dirección IPv6 del reenviador global: 2001:db8::1:0.
      3. Compruebe que el valor de port está ajustado a 53.
    4. Cambie el state a present.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to ensure the presence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 7.7.9.9
            - ip_address: 2001:db8::1:0
              port: 53
          state: present
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-presence-of-a-global-forwarder.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsconfig en el archivo README-dnsconfig.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsconfig.

64.9. Garantizar la ausencia de un reenviador global de DNS en IdM utilizando Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la ausencia de un reenviador global de DNS en IdM. En el siguiente procedimiento de ejemplo, el administrador de IdM garantiza la ausencia de un reenviador global de DNS a un servidor DNS con una dirección de Protocolo de Internet (IP) v4 de 8.8.6.6 y una dirección IP v6 de 2001:4860:4860::8800 en el puerto 53.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible forwarders-absent.yml. Por ejemplo:

    $ cp forwarders-absent.yml ensure-absence-of-a-global-forwarder.yml
  4. Abra el archivo ensure-absence-of-a-global-forwarder.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to ensure the absence of a global forwarder in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53.
    3. En la sección forwarders de la parte ipadnsconfig:

      1. Cambie el primer valor de ip_address por la dirección IPv4 del reenviador global: 8.8.6.6.
      2. Cambie el segundo valor de ip_address por la dirección IPv6 del reenviador global: 2001:4860:4860::8800.
      3. Compruebe que el valor de port está ajustado a 53.
    4. Compruebe que la dirección state está ajustada a absent.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to ensure the absence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 8.8.6.6
            - ip_address: 2001:4860:4860::8800
              port: 53
          state: absent
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-absence-of-a-global-forwarder.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsconfig en el archivo README-dnsconfig.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsconfig.

64.10. Garantizar que los reenviadores globales de DNS estén desactivados en IdM mediante Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para asegurarse de que los reenviadores globales de DNS están desactivados en IdM. En el procedimiento de ejemplo que se muestra a continuación, el administrador de IdM se asegura de que la política de reenvío para el reenvío global se establezca en none, lo que efectivamente desactiva el reenvío global.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Verifique el contenido del archivo disable-global-forwarders.yml Ansible playbook que ya está configurado para desactivar todos los reenviadores globales de DNS. Por ejemplo:

    $ cat disable-global-forwarders.yml
    ---
    - name: Playbook to disable global DNS forwarders
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Disable global forwarders.
        ipadnsconfig:
          forward_policy: none
  4. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file disable-global-forwarders.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsconfig en el archivo README-dnsconfig.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsconfig.

64.11. Garantizar la presencia de una zona de reenvío de DNS en IdM mediante Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la presencia de una zona de reenvío de DNS en IdM. En el siguiente procedimiento de ejemplo, el administrador de IdM garantiza la presencia de una zona de reenvío de DNS para example.com a un servidor DNS con una dirección de protocolo de Internet (IP) de 8.8.8.8.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible forwarders-absent.yml. Por ejemplo:

    $ cp forwarders-absent.yml ensure-presence-forwardzone.yml
  4. Abra el archivo ensure-presence-forwardzone.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to ensure the presence of a dnsforwardzone in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Ensure presence of a dnsforwardzone for example.com to 8.8.8.8.
    3. En la sección tasks, cambie el título ipadnsconfig por ipadnsforwardzone.
    4. En la sección ipadnsforwardzone:

      1. Añade la variable ipaadmin_password y establécela con tu contraseña de administrador de IdM.
      2. Añade la variable name y ponla en example.com.
      3. En la sección forwarders:

        1. Retire las líneas ip_address y port.
        2. Añada la dirección IP del servidor DNS que debe recibir las solicitudes reenviadas, especificándola después de un guión:

          - 8.8.8.8
      4. Añade la variable forwardpolicy y ponla en first.
      5. Añade la variable skip_overlap_check y ponla en true.
      6. Cambie la variable state por present.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to ensure the presence of a dnsforwardzone in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the presence of a dnsforwardzone for example.com to 8.8.8.8
      ipadnsforwardzone:
          ipaadmin_password: password01
          name: example.com
          forwarders:
              - 8.8.8.8
          forwardpolicy: first
          skip_overlap_check: true
          state: present
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-presence-forwardzone.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsforwardzone en el archivo README-dnsforwardzone.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsforwardzone.

64.12. Garantizar que una zona de reenvío de DNS tenga varios reenviadores en IdM mediante Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar que una zona de reenvío de DNS en IdM tenga varios reenviadores. En el procedimiento de ejemplo que se muestra a continuación, el administrador de IdM se asegura de que la zona de reenvío de DNS para example.com se reenvía a 8.8.8.8 y 4.4.4.4.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible forwarders-absent.yml. Por ejemplo:

    $ cp forwarders-absent.yml ensure-presence-multiple-forwarders.yml
  4. Abra el archivo ensure-presence-multiple-forwarders.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to ensure the presence of multiple forwarders in a dnsforwardzone in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Ensure presence of 8.8.8.8 and 4.4.4.4 forwarders in dnsforwardzone for example.com.
    3. En la sección tasks, cambie el título ipadnsconfig por ipadnsforwardzone.
    4. En la sección ipadnsforwardzone:

      1. Añade la variable ipaadmin_password y establécela con tu contraseña de administrador de IdM.
      2. Añade la variable name y ponla en example.com.
      3. En la sección forwarders:

        1. Retire las líneas ip_address y port.
        2. Añade la dirección IP de los servidores DNS que quieres asegurar que están presentes, precedidos por un guión:

          - 8.8.8.8
          - 4.4.4.4
      4. Cambia la variable de estado a presente.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: name: Playbook to ensure the presence of multiple forwarders in a dnsforwardzone in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure presence of 8.8.8.8 and 4.4.4.4 forwarders in dnsforwardzone for example.com
      ipadnsforwardzone:
          ipaadmin_password: password01
         name: example.com
          forwarders:
              - 8.8.8.8
              - 4.4.4.4
          state: present
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-presence-multiple-forwarders.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsforwardzone en el archivo README-dnsforwardzone.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsforwardzone.

64.13. Garantizar que una zona de reenvío de DNS esté desactivada en IdM mediante Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para asegurarse de que una zona de reenvío de DNS está deshabilitada en IdM. En el siguiente procedimiento de ejemplo, el administrador de IdM se asegura de que la zona de reenvío de DNS para example.com esté deshabilitada.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible forwarders-absent.yml. Por ejemplo:

    $ cp forwarders-absent.yml ensure-disabled-forwardzone.yml
  4. Abra el archivo ensure-disabled-forwardzone.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to ensure a dnsforwardzone is disabled in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Ensure a dnsforwardzone for example.com is disabled.
    3. En la sección tasks, cambie el título ipadnsconfig por ipadnsforwardzone.
    4. En la sección ipadnsforwardzone:

      1. Añade la variable ipaadmin_password y establécela con tu contraseña de administrador de IdM.
      2. Añade la variable name y ponla en example.com.
      3. Retire toda la sección forwarders.
      4. Cambie la variable state por disabled.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to ensure a dnsforwardzone is disabled in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure a dnsforwardzone for example.com is disabled
      ipadnsforwardzone:
          ipaadmin_password: password01
          name: example.com
          state: disabled
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-disabled-forwardzone.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsforwardzone en el archivo README-dnsforwardzone.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsforwardzone.

64.14. Garantizar la ausencia de una zona de reenvío de DNS en IdM utilizando Ansible

Esta sección describe cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la ausencia de una zona de reenvío de DNS en IdM. En el siguiente procedimiento de ejemplo, el administrador de IdM asegura la ausencia de una zona de reenvío de DNS para example.com.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible forwarders-absent.yml. Por ejemplo:

    $ cp forwarders-absent.yml ensure-absence-forwardzone.yml
  4. Abra el archivo ensure-absence-forwardzone.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables:

    1. Cambie la variable name para el libro de jugadas a Playbook to ensure the absence of a dnsforwardzone in IdM DNS.
    2. En la sección tasks, cambie el name de la tarea por Ensure the absence of a dnsforwardzone for example.com.
    3. En la sección tasks, cambie el título ipadnsconfig por ipadnsforwardzone.
    4. En la sección ipadnsforwardzone:

      1. Añade la variable ipaadmin_password y establécela con tu contraseña de administrador de IdM.
      2. Añade la variable name y ponla en example.com.
      3. Retire toda la sección forwarders.
      4. Deje la variable state como absent.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Playbook to ensure the absence of a dnsforwardzone in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the absence of a dnsforwardzone for example.com
        ipadnsforwardzone:
           ipaadmin_password: password01
           name: example.com
           state: absent
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-absence-forwardzone.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsforwardzone en el archivo README-dnsforwardzone.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsforwardzone.

Capítulo 65. Gestión de registros DNS en IdM

Este capítulo describe cómo administrar los registros DNS en la Gestión de Identidades (IdM). Como administrador de IdM, puede añadir, modificar y eliminar registros DNS en IdM. El capítulo contiene las siguientes secciones:

Requisitos previos

65.1. Registros DNS en IdM

La gestión de identidades (IdM) admite muchos tipos de registros DNS diferentes. Los cuatro siguientes se utilizan con mayor frecuencia:

A

Este es un mapa básico para un nombre de host y una dirección IPv4. El nombre de registro de un registro A es un nombre de host, como www. El valor IP Address de un registro A es una dirección IPv4, como 192.0.2.1.

Para más información sobre los registros A, véase el RFC 1035.

AAAA

Este es un mapa básico para un nombre de host y una dirección IPv6. El nombre de registro de un registro AAAA es un nombre de host, como www. El valor de IP Address es una dirección IPv6, como 2001:DB8::1111.

Para más información sobre los registros AAAA, consulte el RFC 3596.

SRV

Service (SRV) resource records asigna los nombres de los servicios al nombre DNS del servidor que proporciona ese servicio en particular. Por ejemplo, este tipo de registro puede asignar un servicio como un directorio LDAP al servidor que lo gestiona.

El nombre de un registro SRV tiene el formato _service._protocol, como por ejemplo _ldap._tcp. Las opciones de configuración de los registros SRV incluyen la prioridad, el peso, el número de puerto y el nombre del host del servicio de destino.

Para más información sobre los registros SRV, consulte el RFC 2782.

PTR

Un registro de puntero (PTR) añade un registro DNS inverso, que asigna una dirección IP a un nombre de dominio.

Nota

Todas las búsquedas DNS inversas de direcciones IPv4 utilizan entradas inversas definidas en el dominio in-addr.arpa.. La dirección inversa, en forma legible para el ser humano, es la inversa exacta de la dirección IP normal, con el dominio in-addr.arpa. añadido. Por ejemplo, para la dirección de red 192.0.2.0/24, la zona inversa es 2.0.192.in-addr.arpa.

El nombre del registro de un PTR debe tener el formato estándar especificado en el RFC 1035, ampliado en el RFC 2317 y en el RFC 3596. El valor del nombre del host debe ser un nombre de host canónico del host para el que se desea crear el registro.

Nota

También se pueden configurar zonas inversas para direcciones IPv6, con zonas en el dominio .ip6.arpa.. Para obtener más información sobre las zonas inversas de IPv6, consulte el RFC 3596.

Al añadir registros de recursos DNS, tenga en cuenta que muchos de los registros requieren datos diferentes. Por ejemplo, un registro CNAME requiere un nombre de host, mientras que un registro A requiere una dirección IP. En la interfaz web de IdM, los campos del formulario para añadir un nuevo registro se actualizan automáticamente para reflejar los datos necesarios para el tipo de registro seleccionado en ese momento.

65.2. Añadir registros de recursos DNS en la interfaz web de IdM

Esta sección describe cómo añadir registros de recursos DNS en la interfaz web de gestión de identidades (IdM).

Requisitos previos

  • La zona DNS a la que quieres añadir un registro DNS existe y está gestionada por IdM. Para obtener más información sobre la creación de una zona DNS en IdM DNS, consulte Administración de zonas DNS en IdM.
  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  1. En la interfaz web de IdM, haga clic en Network ServicesDNSDNS Zones.
  2. Haga clic en la zona DNS a la que desea añadir un registro DNS.
  3. En la sección DNS Resource Records, haga clic en Add para añadir un nuevo registro.

    Figura 65.1. Añadir un nuevo registro de recursos DNS

    dns add record
  4. Seleccione el tipo de registro que desea crear y rellene los demás campos según sea necesario.

    Figura 65.2. Definición de un nuevo registro de recursos DNS

    dns add record form
  5. Haga clic en Añadir para confirmar el nuevo registro.

65.3. Añadir registros de recursos DNS desde la CLI de IdM

Esta sección describe cómo añadir un registro de recursos DNS de cualquier tipo desde la interfaz de línea de comandos (CLI).

Requisitos previos

  • La zona DNS a la que quieres añadir un registro DNS existe. Para obtener más información sobre la creación de una zona DNS en IdM DNS, consulte Administración de zonas DNS en IdM.
  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  1. Para añadir un registro de recursos DNS, utilice el comando ipa dnsrecord-add. El comando sigue esta sintaxis:

    $ ipa dnsrecord-add zone_name record_name --record_type_option=data

    En el comando anterior:

    • El zone_name es el nombre de la zona DNS a la que se añade el registro.
    • El record_name es un identificador para el nuevo registro de recursos DNS.

    Por ejemplo, para añadir un registro DNS de tipo A de host1 a la zona idm.example.com, introduzca:

    $ ipa dnsrecord-add idm.example.com host1 --a-rec=192.168.122.123

65.4. Opciones comunes de ipa dnsrecord-*

En esta sección se describen las opciones que puede utilizar al añadir, modificar y eliminar los tipos de registros de recursos DNS más comunes en la Gestión de identidades (IdM):

  • A (IPv4)
  • AAAA (IPv6)
  • SRV
  • PTR

En Bash, puede definir varias entradas enumerando los valores en una lista separada por comas dentro de llaves, como --⁠option={val1,val2,val3}.

Tabla 65.1. Opciones de registro general

OptionDescription

--ttl=number

Establece el tiempo de vida del disco.

--structured

Analiza los registros DNS en bruto y los devuelve en un formato estructurado.

Tabla 65.2. Opciones de registro "A"

OptionDescriptionExamples

--a-rec=ARECORD

Pasa un único registro A o una lista de registros A.

ipa dnsrecord-add idm.example.com host1 --a-rec=192.168.122.123

Puede crear un registro A comodín con una dirección IP determinada.

ipa dnsrecord-add idm.example.com "*" --a-rec=192.168.122.123 [a]

--a-ip-address=string

Indica la dirección IP del registro. Al crear un registro, la opción para especificar el valor del registro A es --a-rec. Sin embargo, cuando se modifica un registro A, se utiliza la opción --a-rec para especificar el valor actual del registro A. El nuevo valor se establece con la opción --a-ip-address.

ipa dnsrecord-mod idm.example.com --a-rec 192.168.122.123 --a-ip-address 192.168.122.124

[a] El ejemplo crea un registro comodín A con la dirección IP 192.0.2.123.

Tabla 65.3. Opciones de registro "AAAA"

OptionDescriptionExample

--aaaa-rec=AAAARECORD

Pasa un único registro AAAA (IPv6) o una lista de registros AAAA.

ipa dnsrecord-add idm.example.com www --aaaa-rec 2001:db8::1231:5675

--aaaa-ip-address=string

Proporciona la dirección IPv6 del registro. Al crear un registro, la opción para especificar el valor del registro A es --aaaa-rec. Sin embargo, cuando se modifica un registro A, se utiliza la opción --aaaa-rec para especificar el valor actual del registro A. El nuevo valor se establece con la opción --a-ip-address.

ipa dnsrecord-mod idm.example.com --aaaa-rec 2001:db8::1231:5675 --aaaa-ip-address 2001:db8::1231:5676

Tabla 65.4. Opciones de registro "PTR"

OptionDescriptionExample

--ptr-rec=PTRRECORD

Pasa un único registro PTR o una lista de registros PTR. Al añadir el registro DNS inverso, el nombre de la zona utilizado con el comando ipa dnsrecord-add se invierte, en comparación con el uso para añadir otros registros DNS. Normalmente, la dirección IP del host es el último octeto de la dirección IP en una red determinada. El primer ejemplo de la derecha añade un registro PTR para server4.idm.example.com con la dirección IPv4 192.168.122.4. El segundo ejemplo añade una entrada DNS inversa a la zona inversa IPv6 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. para el host server2.example.com con la dirección IP 2001:DB8::1111.

ipa dnsrecord-add 122.168.192.in-addr.arpa 4 --ptr-rec server4.idm.example.com.

$ ipa dnsrecord-add 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1.1.1.0.0.0.0.0.0.0.0.0.0.0.0 --ptr-rec server2.idm.example.com.

--ptr-hostname=string

Proporciona el nombre del host para el registro.

 

Tabla 65.5. "SRV Opciones de registro

OptionDescriptionExample

--srv-rec=SRVRECORD

Pasa un único registro SRV o una lista de registros SRV. En los ejemplos de la derecha, _ldap._tcp define el tipo de servicio y el protocolo de conexión para el registro SRV. La opción --srv-rec define los valores de prioridad, peso, puerto y destino. Los valores de peso de 51 y 49 en los ejemplos suman 100 y representan la probabilidad, en porcentajes, de que se utilice un registro concreto.

# ipa dnsrecord-add idm.example.com _ldap._tcp --srv-rec="0 51 389 server1.idm.example.com."

# ipa dnsrecord-add server.idm.example.com _ldap._tcp --srv-rec="1 49 389 server2.idm.example.com."

--srv-priority=number

Establece la prioridad del registro. Puede haber varios registros SRV para un tipo de servicio. La prioridad (0 - 65535) establece el rango del registro; cuanto menor sea el número, mayor será la prioridad. Un servicio tiene que utilizar primero el registro con la prioridad más alta.

# ipa dnsrecord-mod server.idm.example.com _ldap._tcp --srv-rec="1 49 389 server2.idm.example.com." --srv-priority=0

--srv-weight=number

Establece el peso del registro. Esto ayuda a determinar el orden de los registros SRV con la misma prioridad. Los pesos establecidos deben sumar 100, lo que representa la probabilidad (en porcentajes) de que se utilice un registro concreto.

# ipa dnsrecord-mod server.idm.example.com _ldap._tcp --srv-rec="0 49 389 server2.idm.example.com." --srv-weight=60

--srv-port=number

Da el puerto para el servicio en el host de destino.

# ipa dnsrecord-mod server.idm.example.com _ldap._tcp --srv-rec="0 60 389 server2.idm.example.com." --srv-port=636

--srv-target=string

Indica el nombre de dominio del host de destino. Puede ser un solo punto (.) si el servicio no está disponible en el dominio.

 

Recursos adicionales

  • Para obtener más información sobre cómo utilizar ipa dnsrecord-add y qué tipos de registros DNS son compatibles con IdM, ejecute el comando ipa dnsrecord-add --help.

65.5. Eliminación de registros DNS en la interfaz web de IdM

En esta sección se describe cómo eliminar registros DNS en Identity Management (IdM) mediante la interfaz web de IdM.

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  1. En la interfaz web de IdM, haga clic en Network ServicesDNSDNS Zones.
  2. Haga clic en la zona de la que desea eliminar un registro DNS, por ejemplo example.com..
  3. En la sección DNS Resource Records, haga clic en el nombre del registro de recursos.

    Figura 65.3. Selección de un registro de recursos DNS

    dns record delete select record
  4. Seleccione la casilla junto al nombre del tipo de registro que desea eliminar.
  5. Haga clic en Delete.

    Figura 65.4. Eliminación de un registro de recursos DNS

    dns record delete

El tipo de registro seleccionado se elimina. El resto de la configuración del registro de recursos queda intacta.

Recursos adicionales

65.6. Eliminación de un registro DNS completo en la interfaz web de IdM

En esta sección se describe cómo eliminar todos los registros de un recurso concreto de una zona mediante la interfaz web de gestión de identidades (IdM).

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  1. En la interfaz web de IdM, haga clic en Network ServicesDNSDNS Zones.
  2. Haga clic en la zona de la que desea eliminar un registro DNS, por ejemplo zone.example.com..
  3. En la sección DNS Resource Records, seleccione la casilla del registro de recursos que desea eliminar.
  4. Haga clic en Eliminar.

    Figura 65.5. Borrar un registro de recursos completo

    dns record delete all

El registro de recursos completo se ha eliminado.

65.7. Eliminación de registros DNS en la CLI de IdM

Esta sección describe cómo eliminar registros DNS de una zona gestionada por el DNS de Gestión de Identidades (IdM).

Requisitos previos

  • Has iniciado la sesión como administrador de IdM.

Procedimiento

  • Para eliminar registros de una zona, utilice el comando ipa dnsrecord-del y añada la opción --recordType-rec junto con el valor del registro. Por ejemplo, para eliminar un registro de tipo A:

    $ ipa dnsrecord-del ejemplo.com www --a-rec 192.0.2.1

    Si ejecuta ipa dnsrecord-del sin ninguna opción, el comando le pedirá información sobre el registro a eliminar. Tenga en cuenta que al pasar la opción --del-all con el comando se eliminan todos los registros asociados a la zona.

Recursos adicionales

  • Para obtener información detallada sobre cómo utilizar ipa dnsrecord-del y una lista completa de las opciones que acepta el comando, ejecute el comando ipa dnsrecord-del --help.

65.8. Recursos adicionales

Capítulo 66. Uso de Ansible para gestionar los registros DNS en IdM

En este capítulo se describe cómo gestionar los registros DNS en Identity Management (IdM) mediante un libro de jugadas de Ansible. Como administrador de IdM, puede añadir, modificar y eliminar registros DNS en IdM. El capítulo contiene las siguientes secciones:

66.1. Garantizar la presencia de registros DNS A y AAAA en IdM mediante Ansible

Esta sección muestra cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la presencia de registros A y AAAA para un determinado host de IdM. En el ejemplo utilizado en el procedimiento siguiente, un administrador de IdM garantiza la presencia de registros A y AAAA para host1 en la zona DNS idm.example.com.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.
  • La zona idm.example.com existe y es gestionada por IdM DNS. Para obtener más información sobre la adición de una zona DNS primaria en IdM DNS, consulte Uso de libros de juego de Ansible para gestionar zonas DNS de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible ensure-A-and-AAAA-records-are-present.yml. Por ejemplo:

    $ cp ensure-A-and-AAAA-records-are-present.yml ensure-A-and-AAAA-records-are-present-copy.yml
  4. Abra el archivo ensure-A-and-AAAA-records-are-present-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnsrecord:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable zone_name en idm.example.com.
    • En la variable records, establezca la variable name como host1, y la variable a_ip_address como 192.168.122.123.
    • En la variable records, establezca la variable name como host1, y la variable aaaa_ip_address como ::1.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Ensure A and AAAA records are present
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure A and AAAA records are present
      - name: Ensure that 'host1' has A and AAAA records.
        ipadnsrecord:
          ipaadmin_password: Secret123
          zone_name: idm.example.com
          records:
          - name: host1
            a_ip_address: 192.168.122.123
          - name: host1
            aaaa_ip_address: ::1
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-A-and-AAAA-records-are-present-copy.yml

Recursos adicionales

  • Para obtener más información sobre los registros A y AAAA, consulte los registros DNS en IdM.
  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsrecord en el archivo README-dnsrecord.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsrecord.
  • Puede ver ejemplos de playbooks de Ansible para el módulo ipadnsrecord en el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

66.2. Garantizar la presencia de registros DNS A y PTR en IdM mediante Ansible

Esta sección muestra cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la presencia de un registro A para un host IdM concreto, con su correspondiente registro PTR. En el ejemplo utilizado en el procedimiento siguiente, un administrador de IdM garantiza la presencia de registros A y PTR para host1 con una dirección IP de 192.168.122.45 en la zona idm.example.com.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.
  • La zona DNS idm.example.com existe y es administrada por IdM DNS. Para obtener más información sobre la adición de una zona DNS primaria en IdM DNS, consulte Uso de libros de juego de Ansible para gestionar zonas DNS de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible ensure-dnsrecord-with-reverse-is-present.yml. Por ejemplo:

    $ cp ensure-dnsrecord-with-reverse-is-present.yml ensure-dnsrecord-with-reverse-is-present-copy.yml
  4. Abra el archivo ensure-dnsrecord-with-reverse-is-present-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnsrecord:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable name en host1.
    • Establezca la variable zone_name en idm.example.com.
    • Establezca la variable ip_address en 192.168.122.45.
    • Establezca la variable create_reverse en yes.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Ensure DNS Record is present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure that dns record is present
      - ipadnsrecord:
          ipaadmin_password: Secret123
          name: host1
          zone_name: idm.example.com
          ip_address: 192.168.122.45
          create_reverse: yes
          state: present
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-dnsrecord-with-reverse-is-present-copy.yml

Recursos adicionales

  • Para obtener más información sobre los registros DNS A y PTR, consulte Registros DNS en IdM.
  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsrecord en el archivo README-dnsrecord.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsrecord.
  • Puede ver ejemplos de playbooks de Ansible para el módulo ipadnsrecord en el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

66.3. Garantizar la presencia de varios registros DNS en IdM mediante Ansible

Esta sección muestra cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar que se asocien varios valores a un registro DNS de IdM concreto. En el ejemplo utilizado en el procedimiento siguiente, un administrador de IdM asegura la presencia de múltiples registros A para host1 en la zona DNS idm.example.com.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.
  • La zona idm.example.com existe y es gestionada por IdM DNS. Para obtener más información sobre la adición de una zona DNS primaria en IdM DNS, consulte Uso de libros de juego de Ansible para gestionar zonas DNS de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible ensure-presence-multiple-records.yml. Por ejemplo:

    $ cp ensure-presence-multiple-records.yml ensure-presence-multiple-records-copy.yml
  4. Abra el archivo ensure-presence-multiple-records-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnsrecord:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • En la sección records, establezca la variable name como host1.
    • En la sección records, establezca la variable zone_name como idm.example.com.
    • En la sección records, ajuste la variable a_rec a 192.168.122.112 y a 192.168.122.122.
    • Defina un segundo registro en la sección records:

      • Establezca la variable name en host1.
      • Establezca la variable zone_name en idm.example.com.
      • Establezca la variable aaaa_rec en ::1.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Test multiple DNS Records are present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure that multiple dns records are present
      - ipadnsrecord:
          ipaadmin_password: Secret123
          records:
            - name: host1
              zone_name: idm.example.com
              a_rec: 192.168.122.112
              a_rec: 192.168.122.122
            - name: host1
              zone_name: idm.example.com
              aaaa_rec: ::1
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-presence-multiple-records-copy.yml

Recursos adicionales

  • Para obtener más información sobre los registros A en DNS, consulte Registros DNS en IdM.
  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsrecord en el archivo README-dnsrecord.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsrecord.
  • Puede ver ejemplos de playbooks de Ansible para el módulo ipadnsrecord en el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

66.4. Garantizar la presencia de varios registros CNAME en IdM mediante Ansible

Un registro de nombre canónico (registro CNAME) es un tipo de registro de recursos en el sistema de nombres de dominio (DNS) que asigna un nombre de dominio, un alias, a otro nombre, el nombre canónico.

Los registros CNAME pueden resultar útiles cuando se ejecutan varios servicios desde una misma dirección IP: por ejemplo, un servicio FTP y un servicio web, cada uno de los cuales se ejecuta en un puerto diferente.

Esta sección muestra cómo un administrador de Gestión de Identidades (IdM) puede utilizar un libro de jugadas de Ansible para asegurar que varios registros CNAME estén presentes en el DNS de IdM. En el ejemplo utilizado en el procedimiento siguiente, host03 es tanto un servidor HTTP como un servidor FTP. El administrador de IdM garantiza la presencia de los registros CNAME www y ftp para el registro A host03 en la zona idm.example.com.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.
  • La zona idm.example.com existe y es gestionada por IdM DNS. Para obtener más información sobre la adición de una zona DNS primaria en IdM DNS, consulte Uso de libros de juego de Ansible para gestionar zonas DNS de IdM.
  • El registro host03 A existe en la zona idm.example.com.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible ensure-CNAME-record-is-present.yml. Por ejemplo:

    $ cp ensure-CNAME-record-is-present.yml ensure-CNAME-record-is-present-copy.yml
  4. Abra el archivo ensure-CNAME-record-is-present-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnsrecord:

    • (Opcional) Adaptar la descripción que ofrece el name de la obra.
    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable zone_name en idm.example.com.
    • En la sección de variables records, establezca las siguientes variables y valores:

      • Establezca la variable name en www.
      • Establezca la variable cname_hostname en host03.
      • Establezca la variable name en ftp.
      • Establezca la variable cname_hostname en host03.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Ensure that 'www.idm.example.com' and 'ftp.idm.example.com' CNAME records point to 'host03.idm.example.com'.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipadnsrecord:
          ipaadmin_password: Secret123
          zone_name: idm.example.com
          records:
          - name: www
            cname_hostname: host03
          - name: ftp
            cname_hostname: host03
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-CNAME-record-is-present.yml

Recursos adicionales

  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsrecord en el archivo README-dnsrecord.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsrecord.
  • Puede ver ejemplos de playbooks de Ansible para el módulo ipadnsrecord en el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

66.5. Garantizar la presencia de un registro SRV en IdM mediante Ansible

Un registro de servicio DNS (SRV) define el nombre de host, el número de puerto, el protocolo de transporte, la prioridad y el peso de un servicio disponible en un dominio. En la Gestión de Identidades (IdM), puede utilizar los registros SRV para localizar los servidores y las réplicas de IdM.

Esta sección muestra cómo un administrador de Identity Management (IdM) puede utilizar un libro de jugadas de Ansible para garantizar la presencia de un registro SRV en el DNS de IdM. En el ejemplo utilizado en el procedimiento siguiente, un administrador de IdM asegura la presencia del registro SRV _kerberos._udp.idm.example.com con el valor de 10 50 88 idm.example.com. Esto establece los siguientes valores:

  • Establece la prioridad del servicio en 10.
  • Establece el peso del servicio en 50.
  • Establece el puerto a utilizar por el servicio en 88.

Requisitos previos

  • Ha instalado el paquete ansible-freeipa en el controlador de Ansible. Este es el host en el que se ejecutan los pasos del procedimiento.
  • Conoce la contraseña del administrador de IdM.
  • La zona idm.example.com existe y es gestionada por IdM DNS. Para obtener más información sobre la adición de una zona DNS primaria en IdM DNS, consulte Uso de libros de juego de Ansible para gestionar zonas DNS de IdM.

Procedimiento

  1. Navegue hasta el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra su archivo de inventario y asegúrese de que el servidor IdM que desea configurar aparece en la sección [ipaserver]. Por ejemplo, para indicar a Ansible que configure server.idm.example.com, introduzca:

    [ipaserver]
    server.idm.example.com
  3. Haga una copia del archivo de playbook de Ansible ensure-SRV-record-is-present.yml. Por ejemplo:

    $ cp ensure-SRV-record-is-present.yml ensure-SRV-record-is-present-copy.yml
  4. Abra el archivo ensure-SRV-record-is-present-copy.yml para editarlo.
  5. Adapte el archivo estableciendo las siguientes variables en la sección de tareas ipadnsrecord:

    • Establece la variable ipaadmin_password con tu contraseña de administrador de IdM.
    • Establezca la variable name en _kerberos._udp.idm.example.com.
    • Establezca la variable srv_rec en '10 50 88 idm.example.com'.
    • Establezca la variable zone_name en idm.example.com.

      Este es el archivo de Ansible playbook modificado para el ejemplo actual:

    ---
    - name: Test multiple DNS Records are present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure a SRV record is present
      - ipadnsrecord:
          ipaadmin_password: Secret123
          name: _kerberos._udp.idm.example.com
          srv_rec: ’10 50 88 idm.example.com’
          zone_name: idm.example.com
          state: present
  6. Guarda el archivo.
  7. Ejecuta el libro de jugadas:

    $ ansible-playbook -v -i inventory.file ensure-SRV-record-is-present.yml

Recursos adicionales

  • Para obtener más información sobre los registros SRV, consulte los registros DNS en IdM.
  • Puede ver más ejemplos de playbooks de Ansible para el módulo ansible-freeipa ipadnsrecord en el archivo README-dnsrecord.md Markdown disponible en el directorio /usr/share/doc/ansible-freeipa/. El archivo también contiene las definiciones de las variables de ipadnsrecord.
  • Puede ver ejemplos de playbooks de Ansible para el módulo ipadnsrecord en el directorio /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

Capítulo 67. Recogida de información de IdM Healthcheck

Healthcheck ha sido diseñado como una herramienta manual de línea de comandos que debería ayudarle a identificar posibles problemas en la gestión de identidades (IdM).

Este capítulo describe cómo puede crear una colección de registros basada en la salida del Healthcheck con rotación de 30 días.

Requisitos previos

  • La herramienta Healthcheck sólo está disponible en RHEL 8.1 o más reciente

67.1. Comprobación de la salud en IdM

La herramienta Healthcheck de Identity Management (IdM) ayuda a encontrar problemas que pueden afectar a la salud de su entorno de IdM.

Nota

La herramienta Healthcheck es una herramienta de línea de comandos que puede utilizarse sin autenticación Kerberos.

67.1.1. Los módulos son independientes

Healthcheck consta de módulos independientes que comprueban:

  • Problemas de replicación
  • Validez del certificado
  • Problemas de infraestructura de la Autoridad de Certificación
  • Problemas de confianza de IdM y Active Directory
  • Corregir los permisos y la propiedad de los archivos

67.1.2. Dos formatos de salida

Healthcheck genera las siguientes salidas, que puede configurar mediante la opción output-type:

  • json: Salida legible por máquina en formato JSON (por defecto)
  • human: Salida legible para el ser humano

Puede especificar un destino de archivo diferente con la opción --output-file.

67.1.3. Resultados

Cada módulo de Healthcheck devuelve uno de los siguientes resultados:

ÉXITO
configurado como se esperaba
ADVERTENCIA
no es un error, pero vale la pena vigilarlo o evaluarlo
ERROR
no está configurado como se esperaba
CRÍTICA
no está configurado como se esperaba, con una alta posibilidad de impacto

67.2. Rotación de troncos

La rotación de registros crea un nuevo archivo de registro cada día, y los archivos se organizan por fecha. Como los archivos de registro se guardan en el mismo directorio, puede seleccionar un archivo de registro concreto según la fecha.

La rotación significa que se configura un número para el número máximo de archivos de registro y si se supera el número, el archivo más nuevo reescribe y cambia el nombre del más antiguo. Por ejemplo, si el número de rotación es 30, el trigésimo primer archivo de registro sustituye al primero (el más antiguo).

La rotación de registros reduce los archivos de registro voluminosos y los organiza, lo que puede ayudar al análisis de los registros.

67.3. Configuración de la rotación de registros mediante el IdM Healthcheck

Esta sección describe cómo configurar una rotación de registros con:

  • el temporizador systemd
  • el servicio crond

El temporizador systemd ejecuta la herramienta Healthcheck periódicamente y genera los registros. El valor por defecto está fijado en las 4 de la mañana todos los días.

El servicio crond se utiliza para la rotación de registros.

El nombre del registro por defecto es healthcheck.log y los registros rotados utilizan el formato healthcheck.log-YYYYMMDD.

Requisitos previos

  • Debe ejecutar los comandos como root.

Procedimiento

  1. Habilitar un temporizador systemd:

    # systemctl enable ipa-healthcheck.timer
    Created symlink /etc/systemd/system/multi-user.target.wants/ipa-healthcheck.timer -> /usr/lib/systemd/system/ipa-healthcheck.timer.
  2. Inicie el temporizador systemd:

    # systemctl start ipa-healthcheck.timer
  3. Abra el archivo /etc/logrotate.d/ipahealthcheck para configurar el número de registros que deben guardarse.

    Por defecto, la rotación de registros está configurada para 30 días.

  4. En el archivo /etc/logrotate.d/ipahealthcheck, configure la ruta de acceso a los registros.

    Por defecto, los registros se guardan en el directorio /var/log/ipa/healthcheck/.

  5. En el archivo /etc/logrotate.d/ipahealthcheck, configure el tiempo de generación de registros.

    Por defecto, se crea un registro diario a las 4 de la mañana.

  6. Para utilizar la rotación de registros, asegúrese de que el servicio crond está activado y en funcionamiento:

    # systemctl enable crond
    # systemctl start crond

Para empezar a generar registros, inicie el servicio IPA healthcheck:

# systemctl start ipa-healthcheck

Para verificar el resultado, vaya a /var/log/ipa/healthcheck/ y compruebe si los registros se crean correctamente.

Capítulo 68. Comprobación de servicios mediante IdM Healthcheck

En esta sección se describen los servicios de supervisión utilizados por el servidor de gestión de identidades (IdM) mediante la herramienta Healthcheck.

Para más detalles, véase Healthcheck en IdM.

Requisitos previos

  • La herramienta Healthcheck sólo está disponible en RHEL 8.1 y posteriores

68.1. Servicios Examen de salud

La herramienta Healthcheck incluye una prueba para comprobar si algún servicio de IdM no se está ejecutando. Esta prueba es importante porque los servicios que no se están ejecutando pueden causar fallos en otras pruebas. Por lo tanto, compruebe primero que todos los servicios se están ejecutando. A continuación, puede comprobar los resultados de todas las demás pruebas.

Para ver todas las pruebas de servicios, ejecute ipa-healthcheck con la opción --list-sources:

# ipa-healthcheck --list-sources

Puede encontrar todos los servicios probados con Healthcheck en la fuente ipahealthcheck.meta.services:

  • certmonger
  • dirsrv
  • gssproxy
  • httpd
  • ipa_custodia
  • ipa_dnskeysyncd
  • ipa_otpd
  • kadmin
  • krb5kdc
  • llamado
  • pki_tomcatd
  • sssd
Nota

Realice estas pruebas en todos los servidores maestros de IdM cuando intente descubrir problemas.

68.2. Servicios de detección mediante el chequeo de salud

Esta sección describe una prueba manual independiente de los servicios que se ejecutan en el servidor de gestión de identidades (IdM) mediante la herramienta Healthcheck.

La herramienta Healthcheck incluye muchas pruebas, cuyos resultados se pueden acortar con:

  • excluyendo todas las pruebas exitosas --failures-only
  • incluyendo sólo pruebas de servicios --source=ipahealthcheck.meta.services

Procedimiento

  • Para ejecutar Healthcheck con advertencias, errores y problemas críticos de los servicios, introduzca:

    # ipa-healthcheck --source=ipahealthcheck.meta.services --failures-only

Una prueba exitosa muestra paréntesis vacíos:

[ ]

Si uno de los servicios falla, el resultado puede ser similar a este ejemplo:

{
  "source": "ipahealthcheck.meta.services",
  "check": "httpd",
  "result": "ERROR",
  "kw": {
    "status": false,
    "msg": "httpd: not running"
  }
}

Recursos adicionales

  • Para revisar la referencia detallada, introduzca man ipa-healthcheck en la línea de comandos.

Capítulo 69. Verificación de la configuración de confianza de IdM y AD mediante IdM Healthcheck

Esta sección le ayuda a comprender y utilizar la herramienta Healthcheck en la gestión de identidades (IdM) para identificar problemas con IdM y una confianza de Active Directory.

Para más detalles, consulte Sección 67.1, “Comprobación de la salud en IdM”.

Requisitos previos

  • La herramienta Healthcheck sólo está disponible en RHEL 8.1 o más reciente

69.1. Pruebas de confianza de IdM y AD Healthcheck

La herramienta Healthcheck incluye varias pruebas para comprobar el estado de su gestión de identidades (IdM) y la confianza de Active Directory (AD).

Para ver todas las pruebas de confianza, ejecute ipa-healthcheck con la opción --list-sources:

# ipa-healthcheck --list-sources

Puede encontrar todas las pruebas en la fuente ipahealthcheck.ipa.trust:

IPATrustAgentCheck
Esta prueba comprueba la configuración de SSSD cuando la máquina está configurada como agente de confianza. Para cada dominio en /etc/sssd/sssd.conf donde id_provider=ipa asegurar que ipa_server_mode es True.
IPATrustDomainsCheck
Esta prueba comprueba si los dominios de confianza coinciden con los dominios SSSD comparando la lista de dominios en sssctl domain-list con la lista de dominios de ipa trust-find excluyendo el dominio IPA.
IPATrustCatalogCheck

Esta prueba resuelve un usuario de AD, Administrator@REALM. Esto rellena los valores del catálogo global de AD y del controlador de dominio de AD en la salida de sssctl domain-status.

Para cada dominio de confianza busque el usuario con el id del SID 500 (el administrador) y luego compruebe la salida de sssctl domain-status <domain> --active-server para asegurarse de que el dominio está activo.

IPAsidgenpluginCheck
Esta prueba verifica que el plugin sidgen está habilitado en la instancia IPA 389-ds. La prueba también verifica que los plugins IPA SIDGEN y ipa-sidgen-task en cn=plugins,cn=config incluyen la opción nsslapd-pluginEnabled.
IPATrustAgentMemberCheck
Esta prueba verifica que el host actual es miembro de cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX.
IPATrustControllerPrincipalCheck
Esta prueba verifica que el host actual es miembro de cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX.
IPATrustControllerServiceCheck
Esta prueba verifica que el host actual inicia el servicio ADTRUST en ipactl.
IPATrustControllerConfCheck
Esta prueba verifica que ldapi está activado para el backend passdb en la salida de net conf list.
IPATrustControllerGroupSIDCheck
Esta prueba verifica que el SID del grupo de administradores termina en 512 (RID de los administradores del dominio).
IPATrustPackageCheck
Esta prueba verifica que el paquete trust-ad está instalado si el controlador de confianza y la confianza de AD no están habilitados.
Nota

Realice estas pruebas en todos los servidores maestros de IdM cuando intente encontrar un problema.

69.2. Examinar la confianza con la herramienta Healthcheck

Esta sección describe una prueba manual independiente de una comprobación del estado de la confianza de Identity Management (IdM) y Active Directory (AD) mediante la herramienta Healthcheck.

La herramienta Healthcheck incluye muchas pruebas, por lo que puede acortar los resultados:

  • excluyendo todas las pruebas exitosas --failures-only
  • incluyendo sólo las pruebas de confianza --source=ipahealthcheck.ipa.trust

Procedimiento

  • Para ejecutar Healthcheck con advertencias, errores y problemas críticos en la confianza, introduzca:

    # ipa-healthcheck --source=ipahealthcheck.ipa.trust --failures-only

La prueba exitosa muestra paréntesis vacíos:

# ipa-healthcheck --source=ipahealthcheck.ipa.trust --failures-only
[]

Recursos adicionales

  • Para revisar la referencia detallada, introduzca man ipa-healthcheck en la línea de comandos.

Capítulo 70. Verificación de certificados mediante IdM Healthcheck

Esta sección ayuda a comprender y utilizar la herramienta Healthcheck en la gestión de identidades (IdM) para identificar problemas con los certificados IPA mantenidos por certmonger.

Para más detalles, véase Healthcheck en IdM.

Requisitos previos

  • La herramienta Healthcheck sólo está disponible en RHEL 8.1 y posteriores.

70.1. Certificados IdM Pruebas de chequeo

La herramienta Healthcheck incluye varias pruebas para verificar el estado de los certificados mantenidos por certmonger en Identity Management (IdM). Para obtener más información sobre certmonger, consulte Obtención de un certificado IdM para un servicio mediante certmonger.

Este conjunto de pruebas comprueba la caducidad, la validación, la confianza y otras cuestiones. Se pueden lanzar múltiples errores por el mismo problema subyacente.

Para ver todas las pruebas de certificados, ejecute la página ipa-healthcheck con la opción --list-sources:

# ipa-healthcheck --list-sources

Puede encontrar todas las pruebas en la fuente ipahealthcheck.ipa.certs:

IPACertmongerExpirationCheck

Esta prueba comprueba los vencimientos en certmonger.

Si se informa de un error, el certificado ha caducado.

Si aparece una advertencia, el certificado expirará pronto. Por defecto, esta prueba se aplica dentro de los 28 días o menos antes de la expiración del certificado.

Puede configurar el número de días en el archivo /etc/ipahealthcheck/ipahealthcheck.conf. Después de abrir el archivo, cambie la opción cert_expiration_days situada en la sección por defecto.

Nota

Certmonger carga y mantiene su propia visión de la expiración del certificado. Esta comprobación no valida el certificado en disco.

IPACertfileExpirationCheck

Esta prueba comprueba si el archivo de certificado o la base de datos NSS no pueden abrirse. Esta prueba también comprueba la caducidad. Por lo tanto, lea atentamente el atributo msg en la salida de error o advertencia. El mensaje especifica el problema.

Nota

Esta prueba comprueba el certificado en el disco. Si falta un certificado, es ilegible, etc., se puede producir un error por separado.

IPACertNSSTrust
Esta prueba compara la confianza de los certificados almacenados en las bases de datos del NSS. Para los certificados rastreados esperados en las bases de datos del NSS, la confianza se compara con un valor esperado y se genera un error en caso de no coincidencia.
IPANSSChainValidation
Esta prueba valida la cadena de certificados del NSS. La prueba se ejecuta certutil -V -u V -e -d [dbdir] -n [nickname]
IPAOpenSSLChainValidation

Esta prueba valida la cadena de certificados de los certificados OpenSSL. Para que sea comparable con la validación de NSSChain aquí está el comando de OpenSSL que ejecutamos:

openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt [archivo cert]
IPARAAgent
Esta prueba compara el certificado en disco con el registro equivalente en LDAP en uid=ipara,ou=People,o=ipaca.
IPACertRevocation
Esta prueba utiliza certmonger para verificar que los certificados no han sido revocados. Por lo tanto, la prueba puede encontrar problemas relacionados con los certificados mantenidos por certmonger solamente.
IPACertmongerCA

Esta prueba verifica la configuración de la Autoridad de Certificación (CA) de certmonger. IdM no puede emitir certificados sin CA.

Certmonger mantiene un conjunto de ayudantes de CA. En IdM, hay una CA llamada IPA que emite certificados a través de IdM, autenticando como un host o usuario principal, para los certificados de host o servicio.

También existen dogtag-ipa-ca-renew-agent y dogtag-ipa-ca-renew-agent-reuse que renuevan los certificados del subsistema CA.

Nota

Ejecute estas pruebas en todos los servidores maestros de IdM cuando intente comprobar si hay problemas.

70.2. Certificados de control mediante la herramienta Healthcheck

Esta sección describe una prueba manual independiente de la comprobación del estado de un certificado de gestión de identidades (IdM) mediante la herramienta Healthcheck.

La herramienta Healthcheck incluye muchas pruebas, por lo que puede acortar los resultados con:

  • excluyendo todas las pruebas exitosas --failures-only
  • incluyendo sólo las pruebas del certificado --source=ipahealthcheck.ipa.certs

Requisitos previos

  • Las pruebas de Healthcheck deben realizarse como usuario root.

Procedimiento

  • Para ejecutar Healthcheck con advertencias, errores y cuestiones críticas relativas a los certificados, introduzca:

    ipa-healthcheck --source=ipahealthcheck.ipa.certs --failures-only

La prueba exitosa muestra paréntesis vacíos:

[]

La prueba fallida muestra la siguiente salida:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "dbdir": "/path/to/nssdb",
    "error": [error],
    "msg": "Unable to open NSS database '/path/to/nssdb': [error]"
  }
}

Esta prueba IPACertfileExpirationCheck falló al abrir la base de datos NSS.

Recursos adicionales

  • Para revisar la referencia detallada, introduzca man ipa-healthcheck en la línea de comandos.

Capítulo 71. Verificación de los certificados del sistema mediante IdM Healthcheck

Esta sección describe una herramienta de comprobación de la salud en la gestión de identidades (IdM) para identificar problemas con los certificados del sistema.

Para más detalles, véase Healthcheck en IdM.

Requisitos previos

  • La herramienta Healthcheck sólo está disponible en RHEL 8.1 o más reciente.

71.1. Certificados del sistema Pruebas de chequeo

La herramienta Healthcheck incluye varias pruebas para verificar los certificados del sistema (DogTag).

Para ver todas las pruebas, ejecute la página ipa-healthcheck con la opción --list-sources:

# ipa-healthcheck --list-sources

Puede encontrar todas las pruebas en la fuente ipahealthcheck.dogtag.ca:

DogtagCertsConfigCheck

Esta prueba compara los certificados de la CA (Autoridad de Certificación) en su base de datos NSS con los mismos valores almacenados en CS.cfg. Si no coinciden, la CA no se inicia.

En concreto, comprueba:

  • auditSigningCert cert-pki-ca contra ca.audit_signing.cert
  • ocspSigningCert cert-pki-ca contra ca.ocsp_signing.cert
  • caSigningCert cert-pki-ca contra ca.signing.cert
  • subsystemCert cert-pki-ca contra ca.subsystem.cert
  • Server-Cert cert-pki-ca contra ca.sslserver.cert

Si la Autoridad de Recuperación de Claves (KRA) está instalada:

  • transportCert cert-pki-kra contra ca.connector.KRA.transportCert
DogtagCertsConnectivityCheck

Esta prueba verifica la conectividad. Esta prueba es equivalente al comando ipa cert-show 1 que comprueba:

  • La configuración del proxy PKI en Apache
  • El IdM es capaz de encontrar una CA
  • El certificado de cliente del agente RA
  • Corrección de las respuestas de la AC a las solicitudes

Tenga en cuenta que la prueba comprueba un certificado con el número de serie 1 porque quiere verificar que se puede ejecutar un cert-show y obtener un resultado esperado de la CA (el certificado o un no encontrado).

Nota

Realice estas pruebas en todos los servidores maestros de IdM cuando intente encontrar un problema.

71.2. Certificados del sistema de control mediante Healthcheck

Esta sección describe una prueba manual independiente de los certificados de Gestión de Identidades (IdM) utilizando la herramienta Healthcheck.

Dado que la herramienta Healthcheck incluye muchas pruebas, puede limitar los resultados incluyendo sólo las pruebas de DogTag --source=ipahealthcheck.dogtag.ca

Procedimiento

  • Para ejecutar Healthcheck restringido a los certificados DogTag, introduzca:

    # ipa-healthcheck --source=ipahealthcheck.dogtag.ca

Un ejemplo de prueba exitosa:

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: SUCCESS",
  "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c",
  "when: 20191008135826Z",
  "duration: 0.252280",
  "kw:" {
    "key": "Server-Cert cert-pki-ca",
    "configfile":  "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg"
    }
}

Un ejemplo de prueba fallida:

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: CRITICAL",
  "uuid: 59d66200-1447-4b3b-be01-89810c803a98",
  "when: 20191008135912Z",
  "duration: 0.002022",
  "kw:" {
    "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized",
    }
}

Recursos adicionales

  • Para revisar la referencia detallada, introduzca man ipa-healthcheck en la línea de comandos.

Capítulo 72. Comprobación del espacio en disco mediante IdM Healthcheck

Esta sección describe cómo supervisar el espacio libre en disco del servidor de gestión de identidades mediante la herramienta Healthcheck.

Para más detalles, véase Healthcheck en IdM.

Requisitos previos

  • La herramienta Healthcheck sólo está disponible en RHEL 8.1 y posteriores.

72.1. Prueba de comprobación del espacio en disco

La herramienta Healthcheck incluye una prueba para comprobar el espacio disponible en el disco. Un espacio de disco libre insuficiente puede causar problemas con:

  • Registro
  • Ejecución
  • Copias de seguridad

La prueba comprueba las siguientes rutas:

Tabla 72.1. Caminos probados

Rutas comprobadas por la pruebaEspacio mínimo en disco en MB

/var/lib/dirsrv/

1024

/var/lib/ipa/backup/

512

/var/log/

1024

var/log/audit/

512

/var/tmp/

512

/tmp/

512

Para listar todas las pruebas, ejecute la página ipa-healthcheck con la opción --list-sources:

# ipa-healthcheck --list-sources

La prueba de comprobación del espacio del sistema de archivos se encuentra en la fuente ipahealthcheck.system.filesystemspace:

FileSystemSpaceCheck

Esta prueba comprueba el espacio disponible en el disco de las siguientes maneras:

  • El mínimo de bytes libres en bruto necesarios.
  • El porcentaje - el espacio libre mínimo en el disco está codificado al 20%.

72.2. Comprobación del espacio en disco mediante la herramienta Healthcheck

En esta sección se describe una prueba manual independiente del espacio de disco disponible en un servidor de gestión de identidades (IdM) mediante la herramienta Healthcheck.

Dado que Healthcheck incluye muchas pruebas, puedes limitar los resultados por:

  • excluyendo todas las pruebas exitosas --failures-only
  • incluyendo sólo las pruebas de comprobación del espacio --source=ipahealthcheck.system.filesystemspace

Procedimiento

  • Para ejecutar Healthcheck con las advertencias, los errores y las cuestiones críticas relativas al espacio disponible en el disco, introduzca:

    ipa-healthcheck --source=ipahealthcheck.system.filesystemspace --failures-only

Una prueba exitosa muestra paréntesis vacíos:

[]

Como ejemplo, una prueba fallida puede mostrar:

{
  "source": "ipahealthcheck.system.filesystemspace",
  "check": "FileSystemSpaceCheck",
  "result": "ERROR",
  "kw": {
    "msg": "/var/lib/dirsrv: free space under threshold: 0 MiB < 1024 MiB",
    "store": "/var/lib/dirsrv",
    "free_space": 0,
    "threshold": 1024
  }
}

La prueba fallida le informa de que el directorio /var/lib/dirsrv se ha quedado sin espacio.

Recursos adicionales

  • Para revisar la referencia detallada, introduzca man ipa-healthcheck en la línea de comandos.

Capítulo 73. Verificación de los permisos de los archivos de configuración de IdM mediante Healthcheck

Esta sección describe cómo probar los archivos de configuración de Identity Management (IdM) utilizando la herramienta Healthcheck.

Para más detalles, véase Healthcheck en IdM.

Requisitos previos

  • La herramienta Healthcheck sólo está disponible en sistemas RHEL 8.1 o más recientes.

73.1. Permisos de archivos Pruebas de comprobación de la salud

La herramienta Healthcheck comprueba la propiedad y los permisos de algunos archivos importantes instalados o configurados por Identity Management (IdM).

Si cambia la propiedad o los permisos de cualquier archivo probado, la prueba devuelve una advertencia en la sección result. Aunque no significa necesariamente que la configuración no vaya a funcionar, significa que el archivo difiere de la configuración por defecto.

Para ver todas las pruebas, ejecute la página ipa-healthcheck con la opción --list-sources:

# ipa-healthcheck --list-sources

La prueba de los permisos de los archivos se encuentra en la fuente ipahealthcheck.ipa.files:

IPAFileNSSDBCheck
Esta prueba comprueba la base de datos de 389-ds NSS y la base de datos de la Autoridad de Certificación (CA). La base de datos 389-ds se encuentra en /etc/dirsrv/slapd-<dashed-REALM> y la base de datos de la CA se encuentra en /etc/pki/pki-tomcat/alias/.
IPAFileCheck

Esta prueba comprueba los siguientes archivos:

  • /var/lib/ipa/ra-agent.{key|pem}
  • /var/lib/ipa/certs/httpd.pem
  • /var/lib/ipa/private/httpd.key
  • /etc/httpd/alias/ipasession.key
  • /etc/dirsrv/ds.keytab
  • /etc/ipa/ca.crt
  • /etc/ipa/custodia/server.keys

    Si PKINIT está activado:

  • /var/lib/ipa/certs/kdc.pem
  • /var/lib/ipa/private/kdc.key

    Si el DNS está configurado:

  • /etc/named.keytab
  • /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
TomcatFileCheck

Esta prueba comprueba algunos archivos específicos de tomcat si se ha configurado una CA:

  • /etc/pki/pki-tomcat/password.conf
  • /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
  • /etc/pki/pki-tomcat/server.xml
Nota

Realice estas pruebas en todos los servidores maestros de IdM cuando intente encontrar problemas.

73.2. Revisión de los archivos de configuración mediante Healthcheck

Esta sección describe una prueba manual independiente de los archivos de configuración de un servidor de gestión de identidades (IdM) mediante la herramienta Healthcheck.

La herramienta Healthcheck incluye muchas pruebas. Los resultados se pueden acotar por:

  • excluyendo todas las pruebas exitosas --failures-only
  • incluyendo sólo las pruebas de propiedad y permisos --source=ipahealthcheck.ipa.files

Procedimiento

  1. Para ejecutar las pruebas de Healthcheck sobre la propiedad y los permisos de los archivos de configuración de IdM, mostrando sólo las advertencias, los errores y los problemas críticos, introduzca

    # ipa-healthcheck --source=ipahealthcheck.ipa.files --failures-only

Una prueba exitosa muestra paréntesis vacíos:

# ipa-healthcheck --source=ipahealthcheck.ipa.files --failures-only
[]

Las pruebas fallidas muestran resultados similares a los siguientes WARNING:

{
  "source": "ipahealthcheck.ipa.files",
  "check": "IPAFileNSSDBCheck",
  "result": "WARNING",
  "kw": {
    "key": "_etc_dirsrv_slapd-EXAMPLE-TEST_pkcs11.txt_mode",
    "path": "/etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt",
    "type": "mode",
    "expected": "0640",
    "got": "0666",
    "msg": "Permissions of /etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt are 0666 and should be 0640"
  }
}

Recursos adicionales

  • Para revisar el material de referencia detallado, abra man ipa-healthcheck en la línea de comandos.

Capítulo 74. Comprobación de la replicación de IdM mediante Healthcheck

Esta sección describe cómo probar la replicación de Identity Management (IdM) utilizando la herramienta Healthcheck.

Para más detalles, véase Healthcheck en IdM.

Requisitos previos

  • La herramienta Healthcheck sólo está disponible en RHEL 8.1 o más reciente.

74.1. Pruebas de comprobación de la replicación

La herramienta Healthcheck comprueba la configuración de la topología de Identity Management (IdM) y busca problemas de conflicto de replicación.

Para listar todas las pruebas, ejecute la página ipa-healthcheck con la opción --list-sources:

# ipa-healthcheck --list-sources

Las pruebas de topología se sitúan bajo las fuentes ipahealthcheck.ipa.topology y ipahealthcheck.ds.replication:

IPATopologyDomainCheck

Esta prueba verifica:

  • si la topología no está desconectada y hay rutas de replicación entre todos los servidores.
  • si los servidores no tienen más del número recomendado de acuerdos de replicación.

    Si la prueba falla, la prueba devuelve errores, como errores de conexión o demasiados acuerdos de replicación.

    Si la prueba tiene éxito, la prueba devuelve los dominios configurados.

    Nota

    La prueba ejecuta el comando ipa topologysuffix-verify tanto para el dominio como para el sufijo ca (asumiendo que la Autoridad de Certificación está configurada en este maestro).

ReplicationConflictCheck
La prueba busca entradas en LDAP que coincidan con (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)).
Nota

Ejecute estas pruebas en todos los servidores maestros de IdM cuando intente comprobar si hay problemas.

74.2. Repetición de pruebas con Healthcheck

Esta sección describe una prueba manual independiente de la topología y la configuración de replicación de Identity Management (IdM) mediante la herramienta Healthcheck.

La herramienta Healthcheck incluye muchas pruebas, por lo que puede acortar los resultados con:

  • Prueba de conflicto de replicación --source=ipahealthcheck.ds.replication
  • Prueba de topología correcta --source=ipahealthcheck.ipa.topology

Requisitos previos

  • Las pruebas de Healthcheck deben realizarse como usuario root.

Procedimiento

  • Para ejecutar las comprobaciones de conflictos de replicación y topología de Healthcheck, introduzca:

    # ipa-healthcheck --source=ipahealthcheck.ds.replication --source=ipahealthcheck.ipa.topology

Son posibles cuatro resultados diferentes:

  • ÉXITO - la prueba se ha superado con éxito.

    {
      "source": "ipahealthcheck.ipa.topology",
      "check": "IPATopologyDomainCheck",
      "result": "SUCCESS",
      "kw": {
        "suffix": "domain"
      }
    }
  • ADVERTENCIA: la prueba ha sido superada pero puede haber un problema.
  • ERROR - la prueba ha fallado.

    {
      "source": "ipahealthcheck.ipa.topology",
      "check": "IPATopologyDomainCheck",
      "result": "ERROR",
      "uuid": d6ce3332-92da-423d-9818-e79f49ed321f
      "when": 20191007115449Z
      "duration": 0.005943
      "kw": {
        "msg": "topologysuffix-verify domain failed, server2 is not connected (server2_139664377356472 in MainThread)"
      }
    }
  • CRITICAL - la prueba ha fallado y afecta a la funcionalidad del servidor IdM.

Recursos adicionales

  • Para revisar la referencia detallada, abra man ipa-healthcheck en la línea de comandos.

Capítulo 75. Comprobación de los registros DNS mediante IdM Healthcheck

En esta sección se describe la herramienta Healthcheck de Identity Management (IdM) para identificar problemas con los registros DNS.

Para más detalles, véase Healthcheck en IdM.

Requisitos previos

  • La herramienta DNS records Healthcheck sólo está disponible en RHEL 8.2 o más reciente.

75.1. Prueba de comprobación de los registros DNS

La herramienta Healthcheck incluye una prueba para comprobar que los registros DNS esperados, necesarios para la autodetección, se pueden resolver.

Para listar todas las pruebas, ejecute la página ipa-healthcheck con la opción --list-sources:

# ipa-healthcheck --list-sources

La prueba de comprobación de los registros DNS se encuentra en la fuente ipahealthcheck.ipa.idns.

IPADNSSystemRecordsCheck
Esta prueba comprueba los registros DNS del comando ipa dns-update-system-records --dry-run utilizando el primer resolver especificado en el archivo /etc/resolv.conf. Los registros se comprueban en el maestro IPA.

75.2. Revisión de los registros DNS mediante la herramienta healthcheck

Esta sección describe una prueba manual independiente de los registros DNS en un servidor de gestión de identidades (IdM) mediante la herramienta Healthcheck.

La herramienta Healthcheck incluye muchas pruebas. Los resultados pueden reducirse incluyendo sólo las pruebas de registros DNS añadiendo la opción --source ipahealthcheck.ipa.idns.

Requisitos previos

  • Las pruebas de Healthcheck deben realizarse como usuario root.

Procedimiento

  • Para ejecutar la comprobación de los registros DNS, introduzca:

    # ipa-healthcheck --source ipahealthcheck.ipa.idns

    Si el registro se puede resolver, la prueba devuelve SUCCESS como resultado:

    {
        "source": "ipahealthcheck.ipa.idns",
        "check": "IPADNSSystemRecordsCheck",
        "result": "SUCCESS",
        "uuid": "eb7a3b68-f6b2-4631-af01-798cac0eb018",
        "when": "20200415143339Z",
        "duration": "0.210471",
        "kw": {
          "key": "_ldap._tcp.idm.example.com.:server1.idm.example.com."
        }
    }

    La prueba devuelve un WARNING cuando, por ejemplo, el número de registros no coincide con el número esperado:

    {
        "source": "ipahealthcheck.ipa.idns",
        "check": "IPADNSSystemRecordsCheck",
        "result": "WARNING",
        "uuid": "972b7782-1616-48e0-bd5c-49a80c257895",
        "when": "20200409100614Z",
        "duration": "0.203049",
        "kw": {
          "msg": "Got {count} ipa-ca A records, expected {expected}",
          "count": 2,
          "expected": 1
        }
    }

Recursos adicionales

  • Para revisar la referencia detallada, introduzca man ipa-healthcheck en la línea de comandos.

Capítulo 76. Desplazamiento o promoción de réplicas ocultas

Una vez instalada una réplica, puedes cambiar si la réplica está oculta o visible.

Para más detalles sobre las réplicas ocultas, véase El modo de réplica oculta.

Si la réplica es un maestro de renovación de CA, mueva el servicio a otra réplica. Para obtener más detalles, consulte Cambio y restablecimiento del maestro de renovación de CA de IdM.

Nota

La función de réplica oculta está disponible en Red Hat Enterprise Linux 8.1 y posteriores como Technology Preview y, por lo tanto, no es compatible.

Procedimiento

  • Para ocultar la réplica, introduzca:

    # ipa server-state replica.idm.example.com --state=hidden

    También puede hacer visible la réplica con el siguiente comando

    # ipa server-state replica.idm.example.com --state=enabled

Capítulo 77. Configuración de seguridad de la gestión de identidades

Esta sección describe las características relacionadas con la seguridad de la Gestión de Identidades.

77.1. Cómo aplica la Gestión de Identidades la configuración de seguridad por defecto

Por defecto, Identity Management (IdM) en RHEL 8 utiliza la política de cifrado de todo el sistema. La ventaja de esta política es que no es necesario endurecer manualmente los componentes individuales de IdM.

Importante

Red Hat recomienda que utilice la política de criptografía de todo el sistema. Cambiar la configuración de seguridad individual puede romper los componentes de IdM. Por ejemplo, Java en RHEL 8 no soporta completamente el protocolo TLS 1.3. Por lo tanto, el uso de este protocolo puede causar fallos en IdM.

Recursos adicionales

  • Para más detalles sobre las políticas criptográficas de todo el sistema, consulte la página man crypto-policies(7).

77.2. Enlaces LDAP anónimos en la gestión de identidades

Por defecto, los enlaces anónimos al servidor LDAP de Gestión de Identidades (IdM) están activados. Los enlaces anónimos pueden exponer ciertos ajustes de configuración o valores de directorio. Sin embargo, algunas utilidades, como realmd, o los clientes más antiguos de RHEL requieren que se habiliten los enlaces anónimos para descubrir la configuración del dominio cuando se inscribe un cliente.

Recursos adicionales

  • Para obtener más información sobre la desactivación de los enlaces anónimos en el servidor LDAP de IdM, consulte la sección Disabling Anonymous Binds en el sitio web Red Hat Directory Server 11 Administration Guide.

Capítulo 78. Configuración de Samba en un miembro del dominio IdM

Esta sección describe cómo configurar Samba en un host que está unido a un dominio de Red Hat Identity Management (IdM). Los usuarios de IdM y también, si están disponibles, de los dominios de confianza de Active Directory (AD), pueden acceder a los recursos compartidos y a los servicios de impresión proporcionados por Samba.

Importante

El uso de Samba en un miembro del dominio IdM es una característica de Technology Preview no soportada y contiene ciertas limitaciones. Por ejemplo, debido a que los controladores de confianza de IdM no admiten el servicio de catálogo global, los hosts de Windows inscritos en AD no pueden encontrar usuarios y grupos de IdM en Windows. Además, los controladores de confianza de IdM no admiten la resolución de grupos de IdM mediante los protocolos Distributed Computing Environment / Remote Procedure Calls (DCE/RPC). Como consecuencia, los usuarios de AD sólo pueden acceder a los recursos compartidos e impresoras de Samba desde los clientes de IdM.

Se anima a los clientes que despliegan Samba en los miembros del dominio IdM a que proporcionen sus comentarios a Red Hat.

Requisitos previos

  • El host se une como cliente al dominio IdM.
  • Tanto los servidores de IdM como el cliente deben ejecutarse en RHEL 8.1 o posterior.

78.1. Preparación del dominio IdM para instalar Samba en los miembros del dominio

Antes de establecer una confianza con AD y si desea configurar Samba en un cliente IdM, debe preparar el dominio IdM mediante la utilidad ipa-adtrust-install en un servidor IdM. Sin embargo, aunque se den ambas situaciones, debe ejecutar ipa-adtrust-install sólo una vez en un maestro de IdM.

Requisitos previos

  • El IdM está instalado.

Procedimiento

  1. Instale los paquetes necesarios:

    [root@ipaserver ~]# yum install ipa-server ipa-server-trust-ad samba-client
  2. Autenticarse como usuario administrativo de IdM:

    [root@ipaserver ~]# kinit admin
  3. Ejecute la utilidad ipa-adtrust-install:

    [root@ipaserver ~]# ipa-adtrust-install

    Los registros de servicio DNS se crean automáticamente si IdM se ha instalado con un servidor DNS integrado.

    Si IdM se instaló sin un servidor DNS integrado, ipa-adtrust-install imprime una lista de registros de servicio que deben añadirse manualmente al DNS antes de poder continuar.

  4. El script le indica que el /etc/samba/smb.conf ya existe y será reescrito:

    WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
    
    Do you wish to continue? [no]: yes
  5. El script le pide que configure el complemento slapi-nis, un complemento de compatibilidad que permite a los clientes de Linux más antiguos trabajar con usuarios de confianza:

    Do you want to enable support for trusted domains in Schema Compatibility plugin?
    This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
    
    Enable trusted domains support in slapi-nis? [no]: yes
  6. Cuando se le solicite, introduzca el nombre NetBIOS del dominio IdM o pulse Enter para aceptar el nombre propuesto:

    Trust is configured but no NetBIOS domain name found, setting it now.
    Enter the NetBIOS name for the IPA domain.
    Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
    Example: EXAMPLE.
    
    NetBIOS domain name [IDM]:
  7. Se le pide que ejecute la tarea de generación de SID para crear un SID para cualquier usuario existente:

    ¿Desea ejecutar la tarea ipa-sidgen? [no] yes

    Cuando el directorio se instala por primera vez, existe al menos un usuario (el administrador de IdM) y como esta es una tarea que consume muchos recursos, si tienes un número elevado de usuarios, puedes ejecutarla en otro momento.

  8. (Optional) Por defecto, el rango de puertos RPC dinámicos está definido como 49152-65535 para Windows Server 2008 y posteriores. Si necesita definir un rango de puertos RPC dinámicos diferente para su entorno, configure Samba para utilizar puertos diferentes y abra esos puertos en la configuración de su cortafuegos. El siguiente ejemplo establece el rango de puertos en 55000-65000.

    [root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000
    [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
    [root@ipaserver ~]# firewall-cmd --runtime-to-permanent
  9. Reinicie el servicio ipa:

    [root@ipaserver ~]# ipactl restart
  10. Utilice la utilidad smbclient para verificar que Samba responde a la autenticación Kerberos desde el lado de IdM:

    [root@ipaserver ~]# smbclient -L server.idm.example.com -k
    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.12.3)
    ...

78.2. Habilitación del tipo de cifrado AES en Active Directory mediante un GPO

Esta sección describe cómo habilitar el tipo de cifrado AES en Active Directory (AD) mediante un objeto de política de grupo (GPO). Algunas características de RHEL 8, como la ejecución de un servidor Samba en un cliente IdM, requieren este tipo de cifrado.

Tenga en cuenta que RHEL 8 no soporta los tipos de cifrado débil DES y RC4.

Requisitos previos

  • Usted está conectado a AD como un usuario que puede editar las políticas de grupo.
  • El Group Policy Management Console está instalado en el ordenador.

Procedimiento

  1. Abra la página web Group Policy Management Console.
  2. Haga clic con el botón derecho del ratón en Default Domain Policy, y seleccione Edit. Se abre la página Group Policy Management Editor.
  3. Navegue hasta Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.
  4. Haga doble clic en la política Network security: Configure encryption types allowed for Kerberos.
  5. Seleccione AES256_HMAC_SHA1 y, opcionalmente, Future encryption types.
  6. Haga clic en Aceptar.
  7. Cierre la página Group Policy Management Editor.
  8. Repita los pasos para el Default Domain Controller Policy.
  9. Espere a que los controladores de dominio (DC) de Windows apliquen la política de grupo automáticamente. Como alternativa, para aplicar la GPO manualmente en un DC, introduzca el siguiente comando utilizando una cuenta que tenga permisos de administrador:

    C:\N> gpupdate /force /target:computer

78.3. Instalación y configuración de un servidor Samba en un cliente IdM

Esta sección describe cómo instalar y configurar Samba en un cliente inscrito en un dominio IdM.

Requisitos previos

Procedimiento

  1. Instale el paquete ipa-client-samba:

    [root@idm_client]# yum install ipa-client-samba
  2. Utilice la utilidad ipa-client-samba para preparar el cliente y crear una configuración inicial de Samba:

    [root@idm_client]# ipa-client-samba
    Searching for IPA server...
    IPA server: DNS discovery
    Chosen IPA master: idm_server.idm.example.com
    SMB principal to be created: cifs/idm_client.idm.example.com@IDM.EXAMPLE.COM
    NetBIOS name to be used: IDM_CLIENT
    Discovered domains to use:
    
     Domain name: idm.example.com
    NetBIOS name: IDM
             SID: S-1-5-21-525930803-952335037-206501584
        ID range: 212000000 - 212199999
    
     Domain name: ad.example.com
    NetBIOS name: AD
             SID: None
        ID range: 1918400000 - 1918599999
    
    Continue to configure the system with these values? [no]: yes
    Samba domain member is configured. Please check configuration at /etc/samba/smb.conf and start smb and winbind services
  3. Por defecto, ipa-client-samba añade automáticamente la sección [homes] al archivo /etc/samba/smb.conf que comparte dinámicamente el directorio personal de un usuario cuando éste se conecta. Si los usuarios no tienen directorios personales en este servidor, o si no desea compartirlos, elimine las siguientes líneas de /etc/samba/smb.conf:

    [homes]
        read only = no
  4. Compartir directorios e impresoras. Para más detalles, consulte las siguientes secciones en la documentación de Deploying different types of servers para RHEL 8:

  5. Abra los puertos necesarios para un cliente Samba en el firewall local:

    [root@idm_client]# firewall-cmd --permanent --add-service=samba-client
    [root@idm_client]# firewall-cmd --reload
  6. Habilite e inicie los servicios smb y winbind:

    [root@idm_client]# systemctl enable --now smb winbind

Pasos de verificación

Ejecute los siguientes pasos de verificación en otro miembro del dominio IdM que tenga instalado el paquete samba-client:

  1. Autenticar y obtener un ticket de Kerberos:

    $ kinit example_user
  2. Enumerar los recursos compartidos en el servidor Samba utilizando la autenticación Kerberos:

    $ smbclient -L idm_client.idm.example.com -k
    lp_load_ex: changing to config backend registry
    
        Sharename       Type      Comment
        ---------       ----      -------
        example         Disk
        IPC$            IPC       IPC Service (Samba 4.12.3)
    ...

Recursos adicionales

  • Para obtener detalles sobre los pasos que ipa-client-samba realiza durante la configuración, consulte la página de manual ipa-client-samba(1).

78.4. Añadir manualmente una configuración de asignación de ID si IdM confía en un nuevo dominio

Samba requiere una configuración de asignación de ID para cada dominio desde el que los usuarios acceden a los recursos. En un servidor Samba existente que se ejecuta en un cliente IdM, debe añadir manualmente una configuración de asignación de ID después de que el administrador haya añadido una nueva confianza a un dominio de Active Directory (AD).

Requisitos previos

  • Has configurado Samba en un cliente IdM. Después, se añadió una nueva confianza a IdM.
  • Los tipos de cifrado DES y RC4 para Kerberos deben estar desactivados en el dominio AD de confianza. Por razones de seguridad, RHEL 8 no admite estos tipos de cifrado débil.

Procedimiento

  1. Autenticar usando el keytab del host:

    [root@idm_client]# kinit -k
  2. Utilice el comando ipa idrange-find para mostrar tanto el ID base como el tamaño del rango de ID del nuevo dominio. Por ejemplo, el siguiente comando muestra los valores del dominio ad.example.com:

    [root@idm_client]# ipa idrange-find --name="AD.EXAMPLE.COM_id_range" --raw
    ---------------
    1 range matched
    ---------------
      cn: AD.EXAMPLE.COM_id_range
      ipabaseid: 1918400000
      ipaidrangesize: 200000
      ipabaserid: 0
      ipanttrusteddomainsid: S-1-5-21-968346183-862388825-1738313271
      iparangetype: ipa-ad-trust
    ----------------------------
    Number of entries returned 1
    ----------------------------

    Los valores de los atributos ipabaseid y ipaidrangesize son necesarios en los siguientes pasos.

  3. Para calcular el ID utilizable más alto, utilice la siguiente fórmula:

    rango_máximo = ipabaseid ipaidrangesize - 1

    Con los valores del paso anterior, el mayor ID utilizable para el dominio ad.example.com es 1918599999 (1918400000 200000 - 1).

  4. Edite el archivo /etc/samba/smb.conf y añada la configuración de la asignación de ID para el dominio en la sección [global]:

    idmap config AD : range = 1918400000 - 1918599999
    idmap config AD : backend = sss

    Especifique el valor del atributo ipabaseid como el más bajo y el valor calculado del paso anterior como el valor más alto del rango.

  5. Reinicie los servicios smb y winbind:

    [root@idm_client]# systemctl restart smb winbind

Pasos de verificación

  1. Autentifíquese como usuario del nuevo dominio y obtenga un ticket Kerberos:

    $ kinit example_user
  2. Enumerar los recursos compartidos en el servidor Samba utilizando la autenticación Kerberos:

    $ smbclient -L idm_client.idm.example.com -k
    lp_load_ex: changing to config backend registry
    
        Sharename       Type      Comment
        ---------       ----      -------
        example         Disk
        IPC$            IPC       IPC Service (Samba 4.12.3)
    ...

78.5. Recursos adicionales

Capítulo 79. Uso de automontaje en IdM

Automount es una forma de gestionar, organizar y acceder a los directorios en varios sistemas. El programa Automount monta automáticamente un directorio cada vez que se solicita acceso a él. Esto funciona bien dentro de un dominio IdM, ya que permite compartir fácilmente los directorios en los clientes dentro del dominio. Esto es especialmente importante en el caso de los directorios personales de los usuarios.

En IdM, el automontaje funciona con el directorio LDAP interno y también con los servicios DNS si están configurados.

79.1. Configuración de un servidor NFS compatible con Kerberos

Este procedimiento describe cómo configurar un servidor NFS compatible con Kerberos.

Requisitos previos

Procedimiento

  1. Si alguno de sus clientes NFS sólo soporta criptografía débil, como los clientes de Red Hat Enterprise Linux 5:

    1. Actualice la configuración de Kerberos del servidor IdM para habilitar el tipo de cifrado débil des-cbc-crc:

      $ ldapmodify -x -D "cn=directory manager" -w password -h ipaserver.example.com -p 389
      
      dn: cn=REALM_NAME,cn=kerberos,dc=example,dc=com
      changetype: modify
      add: krbSupportedEncSaltTypes
      krbSupportedEncSaltTypes: des-cbc-crc:normal
      -
      add: krbSupportedEncSaltTypes
      krbSupportedEncSaltTypes: des-cbc-crc:special
      -
      add: krbDefaultEncSaltTypes
      krbDefaultEncSaltTypes: des-cbc-crc:special
    2. En el servidor NFS, añada la siguiente entrada al archivo /etc/krb5.conf del servidor NFS para habilitar el soporte de criptografía débil:

      allow_weak_crypto = true
  2. Obtener un ticket Kerberos:

    [root@nfs-server ~]# kinit admin
  3. Si el equipo host NFS no se ha añadido como cliente al dominio IdM, cree la entrada del host. Consulte Añadir entradas de host IdM desde la CLI de IdM.
  4. Cree la entrada del servicio NFS:

    [root@nfs-server ~]# ipa service-add nfs/nfs-server.example.com
  5. Recupera un keytab de servicio NFS para el servidor NFS utilizando el siguiente comando ipa-getkeytab que guarda las claves en el archivo /etc/krb5.keytab:

    root@nfs-server ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/nfs-server.example.com -k /etc/krb5.keytab

    Si alguno de sus clientes NFS sólo admite criptografía débil, pase además la opción -e des-cbc-crc al comando para solicitar un keytab cifrado con DES.

  6. Comprueba que el servicio NFS se ha configurado correctamente en IdM, con su keytab, revisando la entrada del servicio:

    [root@nfs-server ~]# ipa service-show nfs/nfs-server.example.com
      Principal name: nfs/nfs-server.example.com@IDM.EXAMPLE.COM
      Principal alias: nfs/nfs-server.example.com@IDM.EXAMPLE.COM
      Keytab: True
      Managed by: nfs-server.example.com
  7. Instale el nfs-utils paquete:

    root@nfs-server ~]# yum install nfs-utils
  8. Ejecute la utilidad ipa-client-automount para configurar los ajustes de NFS:

    [root@nfs-server ~] ipa-client-automount
    Searching for IPA server...
    IPA server: DNS discovery
    Location: default
    Continue to configure the system with these values? [no]: yes
    Configured /etc/idmapd.conf
    Restarting sssd, waiting for it to become available.
    Started autofs

    Por defecto, este comando activa el NFS seguro y establece el parámetro Domain en el archivo /etc/idmapd.conf al dominio DNS de IdM. Si utiliza un dominio diferente, especifíquelo con el parámetro --idmap-domain domain_name parámetro.

  9. Edite el archivo /etc/exports y añada recursos compartidos con la configuración de seguridad Kerberos krb5p:

    /export  *(rw,sec=krb5:krb5i:krb5p)
    /home  *(rw,sec=krb5:krb5i:krb5p)

    Este ejemplo comparte los directorios /export y /home en modo de lectura y escritura con la autenticación Kerberos activada.

  10. Reinicie y habilite el servidor nfs:

    [root@nfs-server ~]# systemctl restart nfs-server
    [root@nfs-server ~]# systemctl enable nfs-server
  11. Vuelve a exportar los directorios compartidos:

    [root@nfs-server ~]# exportfs -rav
  12. Opcionalmente, configure el servidor NFS como cliente NFS. Consulte Sección 79.2, “Configuración de un cliente NFS compatible con Kerberos”.

79.2. Configuración de un cliente NFS compatible con Kerberos

Este procedimiento describe cómo configurar un cliente NFS compatible con Kerberos.

Requisitos previos

Procedimiento

  1. Si el cliente NFS sólo admite criptografía débil, como un cliente Red Hat Enterprise Linux 5, configure la siguiente entrada en el archivo /etc/krb5.conf del servidor para permitir la criptografía débil:

    allow_weak_crypto = true
  2. Si el cliente NFS no está inscrito como cliente en el dominio de IdM, configure las entradas de host necesarias, como se describe en Añadir entradas de host de IdM desde la CLI de IdM.
  3. Instale el nfs-utils paquete:

    root@nfs-client ~]# yum install nfs-utils
  4. Obtenga un ticket Kerberos antes de ejecutar las herramientas IdM.

    [root@nfs-client ~]# kinit admin
  5. Ejecute la utilidad ipa-client-automount para configurar los ajustes de NFS:

    [root@nfs-client ~] ipa-client-automount
    Searching for IPA server...
    IPA server: DNS discovery
    Location: default
    Continue to configure the system with these values? [no]: yes
    Configured /etc/idmapd.conf
    Restarting sssd, waiting for it to become available.
    Started autofs

    Por defecto, esto habilita el NFS seguro en el archivo /etc/sysconfig/nfs y establece el dominio DNS de IdM en el parámetro Domain en el archivo /etc/idmapd.conf.

  6. Añada las siguientes entradas al archivo /etc/fstab para montar los recursos compartidos NFS desde el host nfs-server.example.com cuando el sistema arranque:

    nfs-server.example.com:/export  /mnt   nfs4  sec=krb5p,rw
    nfs-server.example.com:/home    /home  nfs4  sec=krb5p,rw

    Estos ajustes configuran Red Hat Enterprise Linux para montar el recurso compartido /export en el directorio /mnt y el recurso compartido /home en el directorio /home.

  7. Cree los puntos de montaje si no existen. En nuestro caso, ambos deberían existir.
  8. Montar los recursos compartidos NFS:

    [root@nfs-client ~]# mount /mnt/
    [root@nfs-client ~]# mount /home

    El comando utiliza la información de la entrada /etc/fstab.

  9. Configurar SSSD para renovar los tickets de Kerberos:

    1. Establezca los siguientes parámetros en la sección del dominio IdM del archivo /etc/sssd/sssd.conf para configurar SSSD para renovar automáticamente los tickets:

      [domain/EXAMPLE.COM]
      ...
      krb5_renewable_lifetime = 50d
      krb5_renew_interval = 3600
    2. Reinicie el SSSD:

      [root@nfs-client ~]# systemctl restart sssd
Importante

El módulo pam_oddjob_mkhomedir no admite la creación automática de directorios personales en un recurso compartido NFS. Por lo tanto, debe crear manualmente los directorios de inicio en el servidor en la raíz del recurso compartido que contiene los directorios de inicio.