Red Hat Training
A Red Hat training course is available for RHEL 8
Configurar y gestionar la gestión de identidades
Configuración, gestión y mantenimiento de la gestión de identidades en Red Hat Enterprise Linux 8
Resumen
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:
- 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.
- Utilice el cursor del ratón para resaltar la parte del texto que desea comentar.
- Haga clic en la ventana emergente Add Feedback que aparece debajo del texto resaltado.
- Siga las instrucciones mostradas.
Para enviar comentarios más complejos, cree un ticket de Bugzilla:
- Vaya al sitio web de Bugzilla.
- Como componente, utilice Documentation.
- Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s) parte(s) pertinente(s) de la documentación.
- 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.
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.
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
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 usuarioadmin
:[example_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM: [example_user@server ~]$
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óloexample_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
Para destruir su ticket de Kerberos:
[ejemplo_usuario@servidor ~]$ kdestroy
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
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
AvisoNo sobrescriba el archivo
krb5.conf
existente en el sistema externo.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.-
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)
, ykdestroy(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
ykadmin
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
ywinbind
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.
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.
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.
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 Identity
→ Services
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
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.
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
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 Identity
→ Services
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.- 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 paqueteipa-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
Servidor IdM instalado y accesible.
Para más detalles, véase Instalación de la gestión de identidades.
Para utilizar la interfaz de línea de comandos IPA, autentifíquese en IdM con un ticket Kerberos válido.
Para obtener más información sobre cómo obtener un ticket de Kerberos válido, consulte Cómo iniciar sesión en Gestión de identidades desde la línea de comandos.
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óloipa 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ásicoipa help
. -
topics
- Puede ejecutar el comandoipa 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 comandoipa 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
- Abra el terminal y conéctese al servidor IdM.
Introduzca
ipa help topics
para mostrar una lista de temas cubiertos por la ayuda.$ ipa help topics
Seleccione uno de los temas y cree un comando de acuerdo con el siguiente patrón:
ipa help [topic_name]
, en lugar de la cadenatopic_name
, añada uno de los temas que enumeró en el paso anterior.En el ejemplo, utilizamos el siguiente tema
user
$ ipa help user
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
- Abra el terminal y conéctese al servidor IdM.
Introduzca
ipa help commands
para mostrar una lista de comandos cubiertos por la ayuda.$ ipa help commands
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
- Abra el terminal y conéctese al servidor IdM.
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.
- En el campo First name:, introduzca el nombre del nuevo usuario y pulse la tecla Enter.
- En el campo Last name:, introduzca el apellido del nuevo usuario y pulse la tecla Enter.
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
- Abra el terminal y conéctese al servidor IdM.
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.
- 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.
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
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
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
-
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:
- Inicie sesión en la interfaz web de IdM.
Haga clic en IPA Server.
- En la pestaña IPA Server, haga clic en Configuration.
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
Haga clic en Save en la parte superior de la página.
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:
Billete Kerberos
Para más detalles, consulte Sección 6.1, “Autenticación Kerberos en la gestión de identidades”.
Tarjeta inteligente
Para obtener más información, consulte Configuración del servidor IdM para la autenticación con tarjeta inteligente.
Contraseña de un solo uso (OTP): puede combinarse con la autenticación por contraseña y Kerberos.
Para más detalles, consulte Sección 7.2, “Autenticación por contraseña de un solo uso (OTP) en la gestión de identidades”.
Procedimiento
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.
- 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.
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.
- Haga clic en Iniciar sesión.
Después de iniciar la sesión con éxito, puede empezar a configurar el servidor IdM.
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
Servidor IdM instalado en su entorno de red
Para más detalles, consulte Instalación de la gestión de identidades en Red Hat Enterprise Linux 8
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:
el cliente IdM
Para obtener más información, consulte Preparación del sistema para la instalación del cliente de gestión de identidades.
- el paquete krb5conf
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.
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
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 usuarioadmin
:[example_user@server ~]$ kinit admin Password for admin@EXAMPLE.COM: [example_user@server ~]$
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óloexample_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
- Abra el cuadro de diálogo de inicio de sesión de IdM Web UI en su navegador web.
Haga clic en el enlace para la configuración del navegador en la pantalla de inicio de sesión de la interfaz web.
Siga los pasos de la página de configuración.
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”.
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
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
AvisoNo sobrescriba el archivo
krb5.conf
existente en el sistema externo.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.-
Copie los fragmentos de configuración de Kerberos del directorio
/etc/krb5.conf.d/
al sistema externo. - 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.
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
- Inicie sesión en la interfaz web de IdM con su nombre de usuario y contraseña.
Abra la pestaña Identity → Users → Active users.
- Haga clic en su nombre de usuario para abrir la configuración del mismo.
- En la página User authentication types, seleccione Two factor authentication (password OTP).
- 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
- Inicie sesión en la interfaz web de IdM con su nombre de usuario y contraseña.
- Para crear el token en su teléfono móvil, abra la pestaña Authentication → OTP Tokens.
Haga clic en Add.
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.
- Copie el código QR en su teléfono móvil.
- 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.
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
- 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.
- Añada la contraseña para el nombre de usuario introducido anteriormente.
- Genere una contraseña única en su dispositivo.
- Introduzca la contraseña única justo después de la contraseña (sin espacio).
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.
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
En la pantalla de inicio de sesión de IdM Web UI, haga clic en Sync OTP Token.
- En la pantalla de inicio de sesión, introduzca su nombre de usuario y la contraseña de Gestión de Identidades.
- Genere una contraseña única e introdúzcala en el campo First OTP.
- Genere otra contraseña única e introdúzcala en el campo Second OTP.
Opcionalmente, introduzca el ID del token.
- 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
- En la pantalla de inicio de sesión de caducidad de la contraseña, introduzca el nombre de usuario.
- Añada la contraseña para el nombre de usuario introducido anteriormente.
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.
- Introduzca la nueva contraseña dos veces para verificarla.
Haga clic en Reset Password.
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
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
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 }}"
Adapte el archivo cambiando lo siguiente:
- La contraseña del administrador de IdM.
- Otros valores, si es necesario.
- Guarda el archivo.
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
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
.
-
La contraseña del administrador de IdM establecida por la variable
- Guarda el archivo.
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:
Inicie sesión en
ipaserver
como administrador de IdM:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
-
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. Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
.
-
La contraseña del administrador de IdM establecida por la variable
- Guarda el archivo.
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:
Inicie sesión en
ipaserver
como administrador de IdM:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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.
Puede eliminar las entradas de usuarios de forma permanente de la base de datos de IdM.
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.
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
.
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
- Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
- Obtención de un ticket Kerberos. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
- Abra el terminal y conéctese al servidor IdM.
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_.$-]?
NotaLos 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
- Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
- Obtención de un ticket Kerberos. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
- Abra el terminal y conéctese al servidor IdM.
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
- Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
- Obtención de un ticket Kerberos. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
- Abra el terminal y conéctese al servidor IdM.
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
- Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
- Obtención de un ticket Kerberos. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
- Abra el terminal y conéctese al servidor IdM.
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
- Privilegios de administrador para gestionar el IdM o el rol de administrador de usuarios.
- Obtención de un ticket Kerberos. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
- Abra el terminal y conéctese al servidor IdM.
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.
Puede eliminar las entradas de usuarios de forma permanente de la base de datos de IdM.
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.
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.
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
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.
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.
- Haga clic en el icono Add.
- En el cuadro de diálogo Add stage user, introduzca First name y Last name del nuevo usuario.
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.
- Opcional] En el menú desplegable GID, seleccione los grupos en los que debe incluirse el usuario.
- [Opcional] En los campos Password y Verify password,
Haga clic en el botón Add.
En este punto, puede ver la cuenta de usuario en la tabla Stage Users.
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
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.
- Vaya a la pestaña Users → Stage users.
- Haga clic en la casilla de la cuenta de usuario que desea activar.
Haga clic en el botón Activate.
- 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.
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.
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
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.
- Vaya a la pestaña Users → Active users.
- Haga clic en la casilla de las cuentas de usuario que desee desactivar.
Haga clic en el botón Disable.
- 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.
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
- Inicie sesión en la interfaz web de IdM.
- Vaya a la pestaña Users → Active users.
- Haga clic en la casilla de las cuentas de usuario que desee habilitar.
Haga clic en el botón Enable.
- 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.
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
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.
- Vaya a la pestaña Users → Active users.
- Haga clic en la casilla de las cuentas de usuario que desee conservar.
Haga clic en el botón Delete.
- En el cuadro de diálogo Remove users, cambie el botón de opción Delete mode por preserve.
Haga clic en el botón Delete.
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
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.
- Vaya a la pestaña Users → Preserved users.
- Haga clic en la casilla de las cuentas de usuario que desee restaurar.
Haga clic en el botón Restore.
- 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:
Preservar temporalmente a los usuarios
Para obtener más información, consulte la sección Conservación de usuarios activos en la interfaz web de IdM.
- Borrarlos definitivamente
- 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
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.
Vaya a la pestaña Users → Active users.
También puede eliminar la cuenta de usuario en Users → Stage users o Users → Preserved users.
- Haga clic en el icono Delete.
- En el cuadro de diálogo Remove users, cambie el botón de opción Delete mode por delete.
- 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:
-
Garantizar la presencia de un único usuario que figure directamente en el archivo
YML
. -
Garantizar la presencia de varios usuarios que figuran directamente en el archivo
YML
. -
Garantizar la presencia de varios usuarios listados en un archivo
JSON
al que se hace referencia desde el archivoYML
. -
Garantizar la ausencia de usuarios listados directamente en el archivo
YML
.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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.NotaSi 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.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
:Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicitar un ticket Kerberos para el administrador:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
NotaSi 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.
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
:Entre en
ipaserver
como administrador:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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 }}"
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" } ] }
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
:Entre en
ipaserver
como administrador:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
:
Entre en
ipaserver
como administrador:$ ssh administrator@server.idm.example.com Password: [admin@server /]$
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 deipauser
. -
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), ygidNumber
, 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 grupo | Miembros del grupo por defecto |
---|---|
| Todos los usuarios de IdM |
|
Usuarios con privilegios administrativos, incluido el usuario por defecto |
| Este es un grupo heredado que ya no tiene privilegios especiales |
| 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
.
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
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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
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 aipa group-add
:-
--nonposix
para crear un grupo no POSIX --external
para crear un grupo externoPara más detalles sobre los tipos de grupo, véase Los diferentes tipos de grupo en IdM.
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 aipa 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.
-
Muestra todos los grupos POSIX utilizando el comando
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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
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 deDOMAIN\user_name
ouser_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.
-
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.
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:
- Añadir un nuevo usuario sin un UPG, sin deshabilitar los grupos privados globalmente. Consulte Añadir un usuario sin grupo privado de usuarios cuando los grupos privados están habilitados globalmente.
- Deshabilite los grupos privados de usuarios globalmente para todos los usuarios y luego agregue un nuevo usuario. Consulte Desactivar los grupos privados de usuarios de forma global para todos los usuarios y Añadir un usuario cuando los grupos privados de usuarios están desactivados de forma global.
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.
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 comandoipa 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
Obtener privilegios de administrador:
$ kinit admin
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
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
NotaPara volver a habilitar la instancia
UPG Definition
más adelante, utilice el comandoipa-managed-entries -e "UPG Definition" enable
.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
- Los UPGs deben ser deshabilitados globalmente para todos los usuarios. Para más información, consulte Desactivación de los grupos privados de usuarios de forma global paratodos los usuarios
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 comandoipa 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 degroup_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 degroup_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 degroup_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 degroup_a
.
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
NotaLa 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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
-
Optional. Utilice el comando
ipa group-show
para confirmar que el grupo incluye al miembro que desea eliminar. 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 deDOMAIN\user_name
ouser_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 degroup_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 degroup_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 degroup_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 degroup_a
.
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), ygidNumber
, 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 grupo | Miembros del grupo por defecto |
---|---|
| Todos los usuarios de IdM |
|
Usuarios con privilegios administrativos, incluido el usuario por defecto |
| Este es un grupo heredado que ya no tiene privilegios especiales |
| 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
.
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
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
- Haga clic en Identity → Groups, y seleccione User Groups en la barra lateral izquierda.
- Haga clic en Add para empezar a añadir el grupo.
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.
- 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
- Haga clic en Identity → Groups y seleccione User Groups.
- Seleccione el grupo que desea eliminar.
- Haga clic en Delete.
- 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
- Haga clic en Identity → Groups y seleccione User Groups en la barra lateral izquierda.
- Haga clic en el nombre del grupo.
Seleccione el tipo de miembro del grupo que desea añadir: Users, User Groups, o External.
- Haga clic en Add.
- Seleccione la casilla junto a uno o más miembros que desee añadir.
Haga clic en la flecha hacia la derecha para mover los miembros seleccionados al grupo.
- 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
- Haga clic en Identity → Groups y seleccione User Groups en la barra lateral izquierda.
- Haga clic en el nombre del grupo.
Seleccione el tipo de gestor de miembros del grupo que desea añadir: Users o User Groups.
- Haga clic en Add.
- Seleccione la casilla junto a uno o más miembros que desee añadir.
Haga clic en la flecha hacia la derecha para mover los miembros seleccionados al grupo.
- Haga clic en Add para confirmar.
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:
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
- Seleccione Identity → Groups.
- Seleccione User Groups en la barra lateral izquierda.
- Haga clic en el nombre del grupo que desea ver.
Cambia entre Direct Membership y Indirect Membership.
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
- Haga clic en Identity → Groups y seleccione User Groups en la barra lateral izquierda.
- Haga clic en el nombre del grupo.
Seleccione el tipo de miembro del grupo que desea eliminar: Users, User Groups, o External.
- Seleccione la casilla junto al miembro que desea eliminar.
- Haga clic en Delete.
- 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
- Haga clic en Identity → Groups y seleccione User Groups en la barra lateral izquierda.
- Haga clic en el nombre del grupo.
Seleccione el tipo de gestor de socios que desea eliminar: Users o User Groups.
- Seleccione la casilla junto al gestor de miembros que desea eliminar.
- Haga clic en Delete.
- Haga clic en Delete para confirmar.
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:
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:
- Garantizar la presencia de los grupos de IdM y de los miembros de los grupos mediante los playbooks de Ansible
- Garantizar la presencia de los administradores de los miembros en los grupos de usuarios de IDM utilizando los libros de juego de Ansible
- Garantizar la ausencia de gestores de miembros en los grupos de usuarios de IDM mediante libros de juego de Ansible
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
- Conoce la contraseña del administrador de IdM.
- Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
- Los usuarios a los que desea hacer referencia en su libro de jugadas de Ansible existen en IdM. Para obtener más detalles sobre cómo garantizar la presencia de los usuarios mediante Ansible, consulte Gestión de las cuentas de usuario mediante libros de reproducción de Ansible.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
:
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
:
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
:
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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:
- Ventajas de la afiliación automática al grupo
- Reglas de los miembros automáticos
- Añadir una regla de automembresía utilizando la CLI de IdM
- Cómo añadir una condición a una regla de automembresía mediante la CLI de IdM
- Visualización de las reglas existentes de los miembros automáticos mediante la CLI de IdM
- Eliminación de una regla de automembresía mediante la CLI de IdM
- Eliminación de una condición de una regla de autómatas mediante la CLI de IdM
- Aplicación de reglas de automembresía a las entradas existentes mediante la CLI de IdM
- Configuración de un grupo de miembros automáticos por defecto mediante la CLI de IdM
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).
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.
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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
- El grupo de destino de la nueva regla debe existir en IdM.
Procedimiento
-
Introduzca el comando
ipa automember-add
para añadir una regla de automembresía. 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
- Puede visualizar las reglas y condiciones de los miembros automáticos existentes en IdM mediante Visualización de las reglas de los miembros automáticos existentes mediante la CLI de IdM.
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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
- La regla de destino debe existir en IdM. Para obtener más detalles, consulte Añadir una regla de automembresía utilizando la CLI de IdM.
Procedimiento
-
Defina una o más condiciones inclusivas o exclusivas utilizando el comando
ipa automember-add-condition
. 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
- Puede visualizar las reglas y condiciones de los miembros automáticos existentes en IdM mediante Visualización de las reglas de los miembros automáticos existentes mediante la CLI de IdM.
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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
-
Introduzca el comando
ipa automember-find
. 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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
-
Introduzca el comando
ipa automember-del
. 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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
-
Introduzca el comando
ipa automember-remove-condition
. 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.
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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
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
- Debe iniciar la sesión como administrador. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
- El grupo de destino que desea establecer como predeterminado existe en IdM.
Procedimiento
-
Introduzca el comando
ipa automember-default-group-set
para configurar un grupo de automembresía por defecto. 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
NotaPara 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:
- Ventajas de la afiliación automática al grupo
- Reglas de los miembros automáticos
- Añadir una regla de automembresía mediante la interfaz web de IdM
- Cómo añadir una condición a una regla de miembro automático mediante la interfaz web de IdM
- Visualización de las reglas y condiciones existentes de los miembros automáticos mediante la interfaz web de IdM
- Eliminación de una regla de automembresía mediante la interfaz web de IdM
- Eliminación de una condición de una regla de miembro automático mediante la interfaz web de IdM
- Aplicación de reglas de automembresía a las entradas existentes mediante la interfaz web de IdM
- Configuración de un grupo de usuarios por defecto mediante la interfaz web de IdM
- Configuración de un grupo de hosts por defecto mediante la interfaz web de IdM
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).
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.
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
- Haga clic en Identity → Automember, y seleccione User group rules o Host group rules.
- Haga clic en Add.
En el campo Automember rule, seleccione el grupo al que se aplicará la regla. Este es el nombre del grupo de destino.
- Haga clic en Add para confirmar.
- 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
- Haga clic en Identity → Automember, y seleccione User group rules o Host group rules.
- Haga clic en la regla a la que desea añadir una condición.
En las secciones Inclusive o Exclusive, haga clic en Añadir.
- En el campo Attribute, seleccione el atributo requerido, por ejemplo uid.
- En el campo Expression, defina una expresión regular.
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).
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
- Haga clic en Identity → Automember, y seleccione User group rules o Host group rules para ver las reglas respectivas de los miembros automáticos.
Es opcional: Haga clic en una regla para ver las condiciones de esa regla en las secciones Inclusive o Exclusive.
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
- Haga clic en Identity → Automember, y seleccione User group rules o Host group rules para ver las reglas respectivas de los miembros automáticos.
- Seleccione la casilla junto a la regla que desea eliminar.
Haga clic en Delete.
- 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
- Haga clic en Identity → Automember, y seleccione User group rules o Host group rules para ver las reglas respectivas de los miembros automáticos.
- Haga clic en una regla para ver las condiciones de esa regla en las secciones Inclusive o Exclusive.
- Seleccione la casilla junto a las condiciones que desea eliminar.
Haga clic en Delete.
- 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.
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
- Seleccione Identity → Users o Hosts.
Haga clic en Actions → Rebuild auto membership.
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
- Seleccione Identity → Users o Hosts.
- Haga clic en el nombre de usuario o de host deseado.
Haga clic en Actions → Rebuild auto membership.
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
- Haga clic en Identity → Automember, y seleccione User group rules.
En el campo Default user group, seleccione el grupo que desea establecer como grupo de usuarios por defecto.
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
- Haga clic en Identity → Automember, y seleccione Host group rules.
En el campo Default host group, seleccione el grupo que desea establecer como grupo de hosts por defecto.
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.
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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
-
Optional: Muestra las reglas de autoservicio existentes con el comando
ipa selfservice-find
. -
Optional: Muestra los detalles de la regla de autoservicio que desea modificar con el comando
ipa selfservice-show
. -
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
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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
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.
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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- 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.
Procedimiento
- Abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Self Service Permissions.
Haga clic en Add en la parte superior derecha de la lista de las reglas de acceso de autoservicio:
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:
- Seleccione las casillas de verificación junto a los atributos que desea que los usuarios puedan editar.
Optional: Si un atributo al que quiere dar acceso no está en la lista, puede añadir un listado para él:
- Haga clic en el botón Add.
- Introduzca el nombre del atributo en el campo de texto Attribute de la siguiente ventana Add Custom Attribute.
- Pulse el botón OK para añadir el atributo
- Compruebe que el nuevo atributo está seleccionado
-
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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- 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.
Procedimiento
- Abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Self Service Permissions.
Haga clic en el nombre de la regla de autoservicio que desea modificar.
- 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.
- 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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- 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.
Procedimiento
- Abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Self Service Permissions.
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.
- 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.
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 atributodisplayname
a la regla de ejemplobasic 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
- En el menú IPA Server, haga clic en Role-Based Access Control → Delegations.
Haga clic en Add.
En la ventana Add delegation, haga lo siguiente:
- Nombra la nueva regla de delegación.
- 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).
- 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.
- 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
En el menú IPA Server, haga clic en Role-Based Access Control → Delegations.
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
En el menú IPA Server, haga clic en Role-Based Access Control → Delegations.
- Haga clic en la regla que desea modificar.
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.
- 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
- En el menú IPA Server, haga clic en Role-Based Access Control → Delegations.
- Seleccione la casilla junto a la regla que desea eliminar.
Haga clic en Delete.
- 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.); establecesubtree
ytarget filter
-
memberof
: miembros de un grupo; establece untarget 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 untarget
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.
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.
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
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.
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.
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.
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
Papel | Privilegio | Descripció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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
Procedimiento
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"
Especifique las propiedades del permiso con las siguientes opciones
--bindtype
especifica el tipo de regla de enlace. Esta opción acepta los argumentosall
,anonymous
ypermission
. Elpermission
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 espermission
.NotaNo 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 sonadd
,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}
Notaadd
ydelete
son operaciones de nivel de entrada (por ejemplo, eliminar un usuario, añadir un grupo, etc.) mientras queread
,search
,compare
ywrite
son más de nivel de atributo: se puede escribir enuserCertificate
pero no leeruserPassword
.--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
NotaLas 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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
- Permisos existentes. Para obtener más información sobre los permisos, consulte Administración de permisos de IdM en la CLI.
Procedimiento
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"
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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- Un ticket Kerberos activo. Para más detalles, consulte Uso de kinit para iniciar sesión en IdM manualmente.
- Privilegios existentes. Para obtener más información sobre los privilegios, consulte Administración de privilegios de IdM en la CLI.
Procedimiento
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
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 ----------------------------
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.); establecesubtree
ytarget filter
-
memberof
: miembros de un grupo; establece untarget 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 untarget
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.
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.
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
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.
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.
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.
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
Papel | Privilegio | Descripció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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- 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.
Procedimiento
Para añadir un nuevo permiso, abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Permissions:
Se abre la lista de permisos: Haga clic en el botón Add en la parte superior de la lista de los permisos:
Se abre el formulario Add Permission. Especifique el nombre del nuevo permiso y defina sus propiedades en consecuencia:
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
NotaNo 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.
- Elija los derechos a conceder con este permiso en Granted rights.
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.
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.
ImportanteSi no establece ningún atributo para el permiso, éste incluye todos los atributos por defecto.
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.
- 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.
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.
NotaLas 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):
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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- 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.
- Permisos existentes. Para obtener más información sobre los permisos, consulte Gestión de permisos en la interfaz web de IdM.
Procedimiento
Para añadir un nuevo privilegio, abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Privileges:
Se abre la lista de privilegios. Haga clic en el botón Add en la parte superior de la lista de privilegios:
Se abre el formulario Add Privilege. Introduzca el nombre y una descripción del privilegio:
- 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.
- 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.
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:
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:
- Confirme haciendo clic en el botón Add.
- 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.
- 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
- Privilegios de administrador para gestionar el IdM o el rol User Administrator.
- 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.
- Privilegios existentes. Para obtener más información sobre los privilegios, consulte Gestión de privilegios en la interfaz web de IdM.
Procedimiento
Para añadir un nuevo rol, abra el submenú Role-Based Access Control en la pestaña IPA Server y seleccione Roles:
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.
Se abre el formulario Add Role. Introduzca el nombre de la función y una descripción:
- 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.
- 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.
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).
En la ventana que se abre, seleccione los miembros de la izquierda y utilice el botón > para moverlos a la columna Prospective.
En la parte superior de la pestaña Privileges, haga clic en Add.
Seleccione los privilegios de la izquierda y utilice el botón > para moverlos a la columna Prospective.
- Haga clic en el botón Add para guardar.
- 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.
- 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:
- Vistas de identificación
- Posible impacto negativo de las opiniones de ID en el rendimiento del SSSD
- Atributos que una vista de identificación puede anular
- Obtención de ayuda para los comandos de la vista de identificación
- 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
- Modificación de una vista IdM ID
- Añadir una vista de ID para anular el directorio principal de un usuario de IdM en un cliente de IdM
- Aplicación de una vista de ID a un grupo de hosts de IdM
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 defallback_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.
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
)
-
Nombre de usuario (
- Atributos del grupo
-
Nombre del grupo (
cn
) -
Número de GID del grupo (
gidNumber
)
-
Nombre del grupo (
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
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
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.
NotaEl 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 comandoipa idoverrideuser-add-cert
:$ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
-
Introduzca el comando
-
Opcional: Utilizando el comando
ipa idoverrideuser-mod
, puede especificar nuevos valores de atributos para una anulación de usuario existente. Aplicar
example_for_host1
al hosthost1.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 ---------------------------------------------
NotaEl 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.
Para aplicar la nueva configuración al sistema host1.idm.example.com inmediatamente:
SSH al sistema como root:
$ ssh root@host1 Password:
Borrar la caché de SSSD:
root@host1 ~]# sss_cache -E
- 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:
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 ~]$
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
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/
Cambia la propiedad del directorio:
[root@host1 /]# chown idm_user:idm_user /home/user_1234/
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.
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
.-
Introduzca el comando
Para aplicar la nueva configuración al sistema host1.idm.example.com inmediatamente:
SSH al sistema como root:
$ ssh root@host1 Password:
Borrar la caché de SSSD:
root@host1 ~]# sss_cache -E
- Reinicie el demonio SSSD:
root@host1 ~]# systemctl restart sssd
Pasos de verificación
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 ~]$
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
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/
Cambia la propiedad del directorio:
[root@host1 /]# chown idm_user:idm_user /home/user_1234/
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
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/
-
Introduzca el comando
Aplicar
example_for_host1
al hosthost1.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 ---------------------------------------------
NotaEl 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.
Para aplicar la nueva configuración al sistema host1.idm.example.com inmediatamente:
SSH al sistema como root:
$ ssh root@host1 Password:
Borrar la caché de SSSD:
root@host1 ~]# sss_cache -E
- Reinicie el demonio SSSD:
root@host1 ~]# systemctl restart sssd
Pasos de verificación
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 /]$
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:
- Cómo crear un grupo de hosts y añadir hosts a él.
- Cómo aplicar una vista de identificación al grupo de hosts.
- Cómo añadir un nuevo host al grupo de hosts y aplicar la vista de ID al nuevo host.
Requisitos previos
- Asegúrese de que la vista de ID que desea aplicar al grupo de hosts existe en IdM. Por ejemplo, para crear una vista de ID para anular el nombre de inicio de sesión de un usuario de IdM en un cliente de IdM específico, consulte 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.
Procedimiento
Cree un grupo de hosts y añada hosts a él:
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
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 -------------------------
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 ---------------------------------------------
Añade un nuevo host al grupo de hosts y aplica la vista de ID al nuevo host:
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 -------------------------
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.
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.
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.
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.
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.
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.
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á.
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
- Optional. Si está recuperando un rango de ID de ADN de una réplica que no funciona, primero encuentre el rango de ID utilizando los comandos descritos en Visualización de rangos de ID de ADN actualmente asignados.
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
- Puede comprobar que los nuevos rangos de ADN están configurados correctamente utilizando los comandos descritos en Visualización de los rangos de ID de ADN actualmente asignados.
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:
- Preparar la gestión de identidades (IdM) para utilizar un sistema de aprovisionamiento externo para añadir usuarios de etapa a IdM.
- Creación de un script para mover los usuarios añadidos por el sistema de aprovisionamiento externo de la etapa a los usuarios activos.
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
Inicie sesión como administrador de IdM:
$ kinit admin
Cree un usuario llamado provisionator con privilegios para añadir usuarios de escenario.
- Añade la cuenta de usuario del provisionador:
$ ipa user-add provisionator --first=provisioning --last=account --password
Conceder al usuario provisionador los privilegios necesarios.
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"
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"
Añade el usuario provisionador al rol:
$ ipa role-add-member --users=provisionator \ "System Provisioning"
- 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 [...]
Cree un usuario, activator, con los privilegios para gestionar las cuentas de usuario.
Añade la cuenta de usuario del activador:
$ ipa user-add activator --first=activation --last=account --password
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"
Cree un grupo de usuarios para las cuentas de la aplicación:
$ ipa group-add application-accounts
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
(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 [...]
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}
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:
- Para más detalles sobre la adición de nuevos usuarios, véase Gestión de cuentas de usuario mediante la línea de comandos.
- Para más detalles sobre la concesión a los usuarios de los privilegios necesarios para gestionar otras cuentas de usuario, véase Delegación de permisos sobre los usuarios.
- Para obtener más detalles sobre la gestión de las políticas de contraseñas de IdM, consulte Definición de políticas de contraseñas de IdM.
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.
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
- Las cuentas provisionator y activator existen en IdM. Para obtener más detalles, consulte Preparación de las cuentas de IdM para la activación automática de las cuentas de usuario de escenario.
- Tienes privilegios de root en el servidor IdM en el que estás ejecutando el procedimiento.
- Has iniciado la sesión como administrador de IdM.
- Usted confía en su sistema de aprovisionamiento externo.
Procedimiento
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.
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
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
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
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
Recarga la nueva configuración:
# systemctl daemon-reload
Activar
ipa-activate-all.timer
:# systemctl enable ipa-activate-all.timer
Inicio
ipa-activate-all.timer
:# systemctl start ipa-activate-all.timer
(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
-
El
Procedimiento
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
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
Utilice el protocolo
SSH
para conectarse al servidor IdM como provisionator:$ ssh provisionator@server.idm.example.com Password: [provisionator@server ~]$
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
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
-
El
Procedimiento
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 ~]$
Obtenga el TGT de la cuenta provisionator, un usuario de IdM con un rol para agregar nuevos usuarios de escenario:
$ kinit provisionator
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.
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
Introduzca add como el tipo de cambio que está realizando:
tipo de cambio: añadir
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.
Introduzca la dirección
uid
del usuario:uid: stageuser
Introduzca la dirección
cn
del usuario:cn: Babs Jensen
Introduzca el apellido del usuario:
sn: Jensen
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"
- 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
-
Tenga en cuenta que el usuario está explícitamente desactivado por el atributo
nsaccountlock
.
-
Tenga en cuenta que el usuario está explícitamente desactivado por el atributo
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 siendonssAccountLock: 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
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
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
Inicie sesión como usuario de IdM con un rol para preservar usuarios:
$ kinit admin
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.
Introduzca la dirección
dn
del usuario que desea conservar:dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
Introduzca modrdn como el tipo de cambio que desea realizar:
tipo de cambio: modrdn
Especifique el newrdn para el usuario:
newrdn: uid=user1
Indique que desea conservar el usuario:
deleteoldrdn: 0
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.
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"
- 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 comando
ipa 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 grupoadmins
. La funciónHost 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 rolEnrollment Administrator
, que proporciona el privilegioHost 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 esipa 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ón Usuario Anfitrió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)
-
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
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
Usuario Anfitrió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? |
---|---|---|---|
| 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 |
| 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. |
|
| El host debe tener una entrada en IdM. | Cuando quieras que el host temporalmente desactivado vuelva a estar activo. |
|
| 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. |
|
| El host debe tener una entrada en IdM. | Si desea eliminar el host del ámbito de IdM de forma permanente. |
|
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? |
---|---|---|
|
En el caso de una inscripción en dos pasos: | 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. |
| 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. |
| 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. |
| 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. |
| 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 |
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
Tenga en cuenta que la pestaña IdM Web UI Identity
→ Hosts
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 UI | Opción de línea de comandos | Descripción |
---|---|---|
Descripción |
| Una descripción del anfitrión. |
Localidad |
| La ubicación geográfica del anfitrión. |
Ubicación |
| La ubicación física del host, como el rack de su centro de datos. |
Plataforma |
| El hardware o la arquitectura del host. |
Sistema operativo |
| El sistema operativo y la versión del host. |
Dirección MAC |
|
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 |
Claves públicas SSH |
| 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) |
|
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 |
Establecer una contraseña única |
| Esta opción establece una contraseña para el host que se puede utilizar en la inscripción masiva. |
- |
| Esta opción genera una contraseña aleatoria que se utilizará en la inscripción masiva. |
- |
| Un blob de certificado para el host. |
- |
| 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 comandoipa 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.
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.
- Vuelva a crear la máquina cliente con el mismo nombre de host.
Ejecute el comando
ipa-client-install --force-join
en la máquina cliente:# ipa-client-install --force-join
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 forhostadmin
@EXAMPLE.COM
:
Recursos adicionales
- Para un procedimiento más detallado sobre la inscripción de clientes utilizando las credenciales de un usuario autorizado, consulte Instalación de un cliente utilizando credenciales de usuario: Instalación interactiva en Installing Identity Management.
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.
- Vuelva a crear la máquina cliente con el mismo nombre de host.
-
Copie el archivo keytab desde la ubicación de la copia de seguridad al directorio
/etc/
en la máquina cliente recreada. 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
NotaEl 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.
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:
- Preparar el anfitrión. Para más detalles, consulte Sección 27.8.1, “Requisitos previos”
- 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”
- Cambiar el nombre del host. Para más detalles, consulte Sección 27.8.3, “Cambiar el nombre del sistema anfitrión”
- 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”
- 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, eshost/old-client-name.example.com
.
Para todos los directores de servicio mostrados por
ipa service-find old-client-name.example.com
determine la ubicación de las fichas de claves correspondientes en elold-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
Ejecute el comando
ipa-client-install --uninstall
:[root@client]# ipa-client-install --uninstall
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"
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
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
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
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
- 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.
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
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 comando
ipa 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 grupoadmins
. La funciónHost 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 rolEnrollment Administrator
, que proporciona el privilegioHost 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 esipa 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ón Usuario Anfitrió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)
-
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
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
Usuario Anfitrió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
Tenga en cuenta que la pestaña IdM Web UI Identity
→ Hosts
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 UI | Opción de línea de comandos | Descripción |
---|---|---|
Descripción |
| Una descripción del anfitrión. |
Localidad |
| La ubicación geográfica del anfitrión. |
Ubicación |
| La ubicación física del host, como el rack de su centro de datos. |
Plataforma |
| El hardware o la arquitectura del host. |
Sistema operativo |
| El sistema operativo y la versión del host. |
Dirección MAC |
|
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 |
Claves públicas SSH |
| 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) |
|
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 |
Establecer una contraseña única |
| Esta opción establece una contraseña para el host que se puede utilizar en la inscripción masiva. |
- |
| Esta opción genera una contraseña aleatoria que se utilizará en la inscripción masiva. |
- |
| Un blob de certificado para el host. |
- |
| 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
-
Abra la pestaña
Identity
y seleccione la subpestañaHosts
. Haga clic en Añadir en la parte superior de la lista de hosts.
Figura 28.1. Añadir entradas de host
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
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.
NotaSeleccione la casilla
Force
si desea omitir la comprobación de si el host se puede resolver mediante DNS.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
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:
-
Garantizar la presencia de entradas de host IdM que sólo se definen por su
FQDNs
- Garantizar la presencia de entradas de host IdM con direcciones IP
- Garantizar la presencia de varias entradas de host IdM con contraseñas aleatorias
- Garantizar la presencia de una entrada de host IdM con múltiples direcciones IP
- Garantizar la ausencia de entradas de host IdM
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.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
Ejecuta el libro de jugadas:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
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
Inicie sesión en su servidor IdM como administrador:
$ ssh admin@server.idm.example.com Password:
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.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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ámetroip_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
Ejecuta el libro de jugadas:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
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
Inicie sesión en su servidor IdM como administrador:
$ ssh admin@server.idm.example.com Password:
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.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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 yupdate_password
se limita aon_create
, añade las opcionesrandom: yes
yforce: 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
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"}}}
Para implementar los hosts como clientes de IdM utilizando contraseñas aleatorias de un solo uso (OTP), consulte Opciones de autorización para la inscripción de clientes de IdM utilizando un libro de jugadas de Ansible o Instalación de un cliente utilizando una contraseña de un solo uso: Instalación interactiva.
Pasos de verificación
Inicie sesión en su servidor IdM como administrador:
$ ssh admin@server.idm.example.com Password:
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.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
Cree un archivo Ansible playbook. Especifique, como
name
de la variableipahost
, elfully-qualified domain name
(FQDN) del host cuya presencia en IdM desea asegurar. Especifique cada uno de los múltiples valores de IPv4 e IPv6ip_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
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
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
Inicie sesión en su servidor IdM como administrador:
$ ssh admin@server.idm.example.com Password:
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.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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ónupdatedns: 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
Ejecuta el libro de jugadas:
$ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-absent.yml
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
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
- 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.
Procedimiento
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
- 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.
Procedimiento
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
- 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.
Procedimiento
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" --------------------------
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
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}
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
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 -------------------------
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
-
Optional. Utilice el comando
ipa hostgroup-find
para encontrar hosts y grupos de hosts. 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 -------------------------
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 -------------------------
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
-
Optional. Utilice el comando
ipa hostgroup-find
para encontrar hosts y grupos de hosts. 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 ---------------------------
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 ---------------------------
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
- 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.
Procedimiento
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.
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.
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.
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
- 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.
Procedimiento
- Haga clic en Identity → Groups, y seleccione la pestaña Host Groups.
- Haga clic en Add. Aparece el cuadro de diálogo Add host group.
- Proporcione la información sobre el grupo: nombre (obligatorio) y descripción (opcional).
Haga clic en Add para confirmar.
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
- 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.
Procedimiento
- Haga clic en Identity → Groups y seleccione la pestaña Host Groups.
- Seleccione el grupo de hosts IdM que desea eliminar y haga clic en Delete. Aparece un diálogo de confirmación.
Haga clic en Delete para confirmar
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
- 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.
Procedimiento
- Haga clic en Identity → Groups y seleccione la pestaña Host Groups.
- Haga clic en el nombre del grupo al que desea añadir miembros.
- 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.
- 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.
Haga clic en Add para confirmar.
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
- 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.
Procedimiento
- Haga clic en Identity → Groups y seleccione la pestaña Host Groups.
- Haga clic en el nombre del grupo del que desea eliminar miembros.
- Haga clic en la pestaña Hosts o Host groups según el tipo de miembros que desee eliminar.
- Seleccione la casilla junto al miembro que desea eliminar.
Haga clic en Eliminar. Aparece un diálogo de confirmación.
- 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
Haga clic en Identity → Groups y seleccione la pestaña Host Groups.
- Haga clic en el nombre del grupo al que desea añadir administradores miembros.
- 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.
Haga clic en Add.
- 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.
- Haga clic en Add para confirmar.
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.
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
Haga clic en Identity → Groups y seleccione la pestaña Host Groups.
- Haga clic en el nombre del grupo del que desea eliminar a los administradores miembros.
- 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.
- Seleccione el usuario o los grupos de usuarios que desea eliminar y haga clic en Delete.
Haga clic en Delete para confirmar.
NotaDespué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.
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):
- Garantizar la presencia de grupos de acogida de IdM
- Garantizar la presencia de hosts en los grupos de hosts de IdM
- Anidación de grupos de hosts IdM
- Garantizar la presencia de los gestores miembros en los grupos de acogida de IdM
- Garantizar la ausencia de hosts en los grupos de hosts de IdM
- Garantizar la ausencia de grupos de hosts anidados de los grupos de hosts de IdM
- Garantizar la ausencia de gestores miembros de los grupos de acogida de 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.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
con la lista de servidores IdM a los que dirigirse:[ipaserver] server.idm.example.com
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í.
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
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicitar un ticket Kerberos para el administrador:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
- Conoce la contraseña del administrador de IdM.
- Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
- Los hosts a los que desea hacer referencia en su libro de jugadas de Ansible existen en IdM. Para obtener más detalles, consulte Garantizar la presencia de una entrada de host de IdM mediante los libros de reproducción de Ansible.
- Los grupos de hosts a los que se hace referencia desde el archivo de playbook de Ansible se han añadido a IdM. Para obtener más detalles, consulte Garantizar la presencia de los grupos de hosts de IdM mediante los playbooks de Ansible.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
con la lista de servidores IdM a los que dirigirse:[ipaserver] server.idm.example.com
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 variableipahostgroup
. Especifique el nombre del host con el parámetrohost
de la variableipahostgroup
. 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.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
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicitar un ticket Kerberos para el administrador:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
- Conoce la contraseña del administrador de IdM.
- Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
- Los grupos de hosts a los que se hace referencia desde el archivo del libro de jugadas de Ansible existen en IdM. Para obtener más detalles, consulte Garantizar la presencia de los grupos de hosts de IdM mediante los playbooks de Ansible.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
con la lista de servidores IdM a los que dirigirse:[ipaserver] server.idm.example.com
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 variablename
. Especifique el nombre del grupo de hosts anidado A con la variablehostgroup
. 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.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
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicitar un ticket Kerberos para el administrador:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
:
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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
- Conoce la contraseña del administrador de IdM.
- Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
- Los hosts a los que desea hacer referencia en su libro de jugadas de Ansible existen en IdM. Para obtener más detalles, consulte Garantizar la presencia de una entrada de host de IdM mediante los libros de reproducción de Ansible.
- Los grupos de hosts a los que se hace referencia desde el archivo del libro de jugadas de Ansible existen en IdM. Para obtener más detalles, consulte Garantizar la presencia de los grupos de hosts de IdM mediante los playbooks de Ansible.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
con la lista de servidores IdM a los que dirigirse:[ipaserver] server.idm.example.com
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 variableipahostgroup
. Especifique el nombre del host cuya ausencia del grupo de hosts desea asegurar utilizando el parámetrohost
de la variableipahostgroup
. 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.
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
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicitar un ticket Kerberos para el administrador:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
- Conoce la contraseña del administrador de IdM.
- Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
- Los grupos de hosts a los que se hace referencia desde el archivo del libro de jugadas de Ansible existen en IdM. Para obtener más detalles, consulte Garantizar la presencia de los grupos de hosts de IdM mediante los playbooks de Ansible.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
con la lista de servidores IdM a los que dirigirse:[ipaserver] server.idm.example.com
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 variablename
. Especifique el nombre del grupo de hosts anidado con la variablehostgroup
. 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.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
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicitar un ticket Kerberos para el administrador:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
con la lista de servidores IdM a los que dirigirse:[ipaserver] server.idm.example.com
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.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
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
Solicitar un ticket Kerberos para el administrador:
$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
:
Entre en
ipaserver
como administrador:$ ssh admin@server.idm.example.com Password: [admin@server /]$
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:
- El papel del KDC de IdM
- Tipos de política de tickets IdM Kerberos
- Indicadores de autenticación Kerberos
- Aplicación de indicadores de autenticación para un servicio IdM
- Configuración de la política global del ciclo de vida del ticket
- Configuración de políticas globales de tickets por indicador de autenticación
- Configuración de la política de tickets por defecto para un usuario
- Configuración de políticas de tickets de indicadores de autenticación individuales para un usuario
-
Opciones del indicador de autentificación para el comando
krbtpolicy-mod
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
, comoadmin@EXAMPLE.COM
-
Para los servicios:
service/fully-qualified-hostname@REALM
, comohttp/master.example.com@EXAMPLE.COM
-
Para los anfitriones:
host/fully-qualified-hostname@REALM
, comohost/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.
-
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. - 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.
- 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.
- Con el TGT, el cliente solicita un service ticket al KDC para comunicarse con un servicio Kerberizado en un host de destino.
- 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.
- El KDC emite al cliente un service ticket.
- 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óntestservice
enclient2.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:
- Para configurar diferentes valores globales del ciclo de vida del ticket para cada indicador de autenticación, consulte Configuración de políticas globales de tickets por indicador de autenticación.
- Para definir los valores del ciclo de vida de los tickets para un solo usuario que se aplican independientemente del método de autenticación utilizado, consulte Configuración de la política de tickets predeterminada para un usuario.
- Para definir valores individuales del ciclo de vida del ticket para cada indicador de autenticación que sólo se aplican a un único usuario, consulte Configuración de políticas de tickets de indicadores de autenticación individuales para un usuario.
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
- Para asociar un servicio IdM con indicadores de autenticación, consulte Aplicación de indicadores de autenticación para un servicio IdM.
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
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óntestservice
que se ejecuta en el hostclient.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
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
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
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
- Ha creado una entrada de servicio IdM para un servicio que se ejecuta en un host IdM. Consulte Creación de una entrada de servicio IdM y su llavero Kerberos.
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
valorAutenticació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 hostclient.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
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
- Para probar la solicitud de un vale de servicio para un servicio IdM, consulte Recuperación de un vale de servicio Kerberos para un servicio IdM.
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
- Si el servicio con el que está trabajando no es un servicio IdM interno, ha creado una entrada IdM service correspondiente para él. Consulte Creación de una entrada de servicio IdM y su llavero Kerberos.
- Tiene un ticket de concesión de tickets de Kerberos (TGT).
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
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
- Para más información sobre los indicadores de autenticación de Kerberos, consulte Sección 33.3, “Indicadores de autenticación Kerberos”.
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
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).
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
- Para ajustar la política de tickets predeterminada para un solo usuario, consulte Configuración de la política de tickets predeterminada para un usuario.
- Para configurar políticas de tickets individuales para cada indicador de autenticación para un solo usuario, consulte Configuración de políticas de tickets de indicadores de autenticación individuales para un usuario.
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
yMax renew
.
Recursos adicionales
-
Para obtener una lista de las opciones del indicador de autenticación para el comando
ipa krbtpolicy-mod
, consulte Opciones del indicador de autenticación para el comandokrbtpolicy-mod
. - Para ajustar la política de tickets predeterminada para un solo usuario, consulte Configuración de la política de tickets predeterminada para un usuario.
- Para configurar políticas de tickets individuales para cada indicador de autenticación para un solo usuario, consulte Configuración de políticas de tickets de indicadores de autenticación individuales para un usuario.
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
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
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
- Para ajustar la política global de tickets para todos los usuarios, consulte Configuración de la política global del ciclo de vida de los tickets.
- Para configurar diferentes políticas de tickets por defecto por indicador de autenticación, consulte Configuración de políticas globales de tickets por indicador de autenticación.
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
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
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
-
Para obtener una lista de las opciones del indicador de autenticación para el comando
ipa krbtpolicy-mod
, consulte Opciones del indicador de autenticación para el comandokrbtpolicy-mod
. - Para ajustar la política de tickets predeterminada para un solo usuario, consulte Configuración de la política de tickets predeterminada para un usuario.
- Para ajustar la política global de tickets para todos los usuarios, consulte Configuración de la política global del ciclo de vida de los tickets.
- Para configurar diferentes políticas de tickets globales por indicador de autenticación, consulte Configuración de políticas de tickets globales por indicador de autenticación.
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ón | Argumento de la vida útil máxima | Argumento para la edad máxima de renovación |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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
Atributo | Explicación | Ejemplo |
---|---|---|
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:
*
* | Clases de caracteres = 0
El número de clases requerido por defecto es 0. Para configurar el número, ejecute el comando 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 |
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 | Duración del bloqueo = 600 Los usuarios con cuentas bloqueadas no pueden conectarse durante 10 minutos. |
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.
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
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina elFQDN
de su servidor IdM en la sección[ipaserver]
:[ipaserver] server.idm.example.com
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.
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.
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.
- ¿Qué es la herramienta de notificación de contraseña caducada?
- Instalación de la herramienta de notificación de caducidad de la contraseña
- Ejecutar la herramienta EPN para enviar mensajes de correo electrónico a los usuarios cuyas contraseñas van a caducar
- Habilitar el temporizador ipa-epn.timer para que envíe un correo electrónico a todos los usuarios cuyas contraseñas caduquen
- Modificación de la plantilla de correo electrónico de notificación de contraseña caducada
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.
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.
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
-
El paquete
ipa-client-epn
está instalado. Véase Instalación de la herramienta de notificación de caducidad de la contraseña. -
Personalice la plantilla de correo electrónico
ipa-epn
si es necesario. Consulte Modificar la plantilla de correo electrónico de notificación de contraseña caducada.
Procedimiento
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
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
Configure su servidor SMTP y su puerto:
smtp_server = localhost smtp_port = 25
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
-
Guarde el archivo
/etc/ipa/epn.conf
. 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
NotaSi 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.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
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
NotaSi 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
-
El paquete
ipa-client-epn
está instalado. Véase Instalación de la herramienta de notificación de caducidad de la contraseña -
Personalice la plantilla de correo electrónico de
ipa-epn
si es necesario. Consulte Modificar la plantilla de correo electrónico de notificación de contraseña caducada
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
Abra la plantilla de mensajes EPN:
# vi /etc/ipa/epn/expire_msg.template
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
- 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
Añade el comando
/usr/sbin/reboot
a la base de datos de comandos de IdMsudo
:- Navegue hasta Policy → Sudo → Sudo Commands.
- Haga clic en Add en la esquina superior derecha para abrir el cuadro de diálogo Add sudo command.
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
- Haga clic en Add.
Utilice la nueva entrada de comando
sudo
para crear una regla sudo que permita a idm_user reiniciar la máquina idmclient:- Navegue hasta Policy → Sudo → Sudo rules.
- Haga clic en Add en la esquina superior derecha para abrir el cuadro de diálogo Add sudo rule.
-
Introduzca el nombre de la regla
sudo
: idm_user_reboot. - Haga clic en Add and Edit.
Especifica el usuario:
- En la sección Who, marque el botón de opción Specified Users and Groups.
- 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".
- 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.
- Haga clic en Add.
Especifica el host:
- En la sección Access this host, marque el botón de opción Specified Hosts and Groups.
- 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".
- 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.
- Haga clic en Add.
Especifica los comandos:
- 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.
- 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".
-
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. Haga clic en Add para volver a la página idm_sudo_reboot.
Figura 36.2. Añadir la regla sudo de IdM
- 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.
- Inicie sesión en idmclient como idm_user.
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
- Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
- Conoce la contraseña del administrador de IdM.
- Ha asegurado la presencia de 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 información 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 existe una cuenta local idm_user en idmclient. El usuario idm_user no aparece en el archivo
/etc/passwd
en idmclient.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaservers
:[ipaservers] server.idm.example.com
Añade uno o más comandos de
sudo
: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 comandossudo
. 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
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
Cree una regla
sudo
que haga referencia a los comandos:Cree un playbook de Ansible
ensure-sudorule-for-idmuser-on-idmclient-is-present.yml
que utilice la entrada del comandosudo
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
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.
- Inicie sesión en idmclient como idm_user.
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
- El paquete ansible-freeipa está instalado en el controlador Ansible.
- Conoce la contraseña del administrador de IdM.
- Los usuarios y grupos de usuarios que desea utilizar para su regla HBAC existen en IdM. Consulte Gestión de cuentas de usuario mediante libros de juego de Ansible y Garantizar la presencia de grupos y miembros de grupos de IdM mediante libros de juego de Ansible para obtener más detalles.
- Los hosts y grupos de hosts a los que desea aplicar su regla HBAC existen en IdM. Para más información, consulte Gestión de hosts mediante libros de juego de Ansible y Gestión de grupos de hosts mediante libros de juego de Ansible.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
, y defina en élipaserver
:[ipaserver] server.idm.example.com
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
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
- Inicie sesión en la interfaz web de IdM como administrador.
- Navegue hasta Policy → Host-Based-Access-Control → HBAC Test.
- En la pestaña Who, seleccione idm_user.
- En la pestaña Accessing, seleccione client.idm.example.com.
- En la pestaña Via service, seleccione sshd.
- En la pestaña Rules, seleccione login.
- 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 AC | Descripción | Utilice | Enlaces útiles |
---|---|---|---|
El | 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 |
Las sub-CAs de IdM son CAs a las que la CA de | 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
- Para obtener más detalles sobre las configuraciones de CA compatibles con el servidor de IdM, consulte Planificación de los servicios de CA.
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 |
| Sí | Sí |
| Opcional | Sí |
| Opcional | Sí |
| Simétrico | Asimétrico |
| 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:
- Solicitud de nuevos certificados para un usuario, host o servicio mediante la interfaz web de IdM.
Solicitar nuevos certificados para un usuario, host o servicio a la CA de IdM mediante la CLI de IdM:
Solicitud de nuevos certificados para un usuario, host o servicio a la CA IdM mediante certutil
-
Para ver un ejemplo concreto de cómo solicitar un nuevo certificado de usuario a la CA de IdM mediante la utilidad
certutil
y exportarlo a un cliente de IdM, consulte Solicitar un nuevo certificado de usuario y exportarlo al cliente.
-
Para ver un ejemplo concreto de cómo solicitar un nuevo certificado de usuario a la CA de IdM mediante la utilidad
- Solicitud de nuevos certificados para un usuario, host o servicio a la CA IdM mediante openssl
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
Su implementación de IdM contiene una CA integrada:
- Para obtener información sobre cómo planificar sus servicios de CA en IdM, consulte Planificación de sus servicios de CA.
- Para obtener información sobre cómo instalar un servidor IdM con DNS integrado y CA integrada como CA raíz, consulte Instalación de un servidor IdM: Con DNS integrado, con una CA integrada como CA raíz
- Para obtener información sobre cómo instalar un servidor IdM con DNS integrado y una CA externa como CA raíz, consulte Instalación de un servidor IdM: Con DNS integrado, con una CA externa como CA raíz
- Para obtener información sobre cómo instalar un servidor IdM sin DNS integrado y con una CA integrada como CA raíz, consulte Instalación de un servidor IdM: Sin DNS integrado, con una CA integrada como CA raíz.
Opcional] Su implementación de IdM admite que los usuarios se autentiquen con un certificado:
- Para obtener información sobre cómo configurar la implementación de IdM para que admita la autenticación de usuarios con un certificado almacenado en el sistema de archivos del cliente IdM, consulte Configuración de la autenticación con un certificado almacenado en el escritorio de un cliente IdM.
- Para obtener información sobre cómo configurar la implantación de IdM para que admita la autenticación de usuarios con un certificado almacenado en una tarjeta inteligente insertada en un cliente de IdM, consulte
- Para obtener información sobre cómo configurar la implantación de IdM para que admita la autenticación de usuarios con tarjetas inteligentes emitidas por un sistema de certificados de Active Directory, consulte
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
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
-
En la pestaña
Identity
, seleccione la subpestañaUsers
,Hosts
, oServices
. Haga clic en el nombre del usuario, host o servicio para abrir su página de configuración.
Figura 39.1. Lista de anfitriones
- Haga clic en Acciones → Nuevo certificado.
- Opcional: Seleccione la CA emisora y el ID del perfil.
-
Siga las instrucciones para utilizar la utilidad de línea de comandos (CLI)
certutil
en la pantalla. - 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
.
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
Cree un directorio temporal para la base de datos de certificados:
# mkdir ~/certdb/
Cree una nueva base de datos temporal de certificados, por ejemplo:
# certutil -N -d ~/certdb/
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
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
-
Para más información sobre el comando
ipa cert-request
, consulte la salida del comandoipa cert-request --help
. - Para obtener más información sobre la creación de un perfil de certificado personalizado, consulte Creación y gestión de perfiles de certificado en Gestión de identidades.
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
.
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
- 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.
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
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
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
-
Para más información sobre el comando
ipa cert-request
, consulte la salida del comandoipa cert-request --help
. - Para obtener más información sobre la creación de un perfil de certificado personalizado, consulte Creación y gestión de perfiles de certificado en Gestión de identidades.
39.4. Recursos adicionales
- Para obtener información sobre cómo revocar certificados utilizando la CA de IdM, consulte Revocar certificados con las CA de IdM integradas.
- Para obtener información sobre cómo restaurar certificados utilizando la CA de IdM, consulte Restauración de certificados con las CA de IdM integradas.
- Para obtener información sobre cómo restringir una aplicación para que confíe sólo en los certificados emitidos por una sub-CA de IdM, consulte Restringir una aplicación para que confíe sólo en un subconjunto de certificados.
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:
- Está cargando un certificado externo en un perfil de usuario. Para más detalles, consulte Sección 40.2, “Conversión de un certificado externo para cargarlo en una cuenta de usuario de IdM”.
- Se utiliza un certificado de CA externa cuando se configura el servidor de IdM para la autenticación con tarjeta inteligente o se configura el cliente de IdM para la autenticación con tarjeta inteligente, de modo que los usuarios puedan autenticarse en IdM utilizando tarjetas inteligentes con certificados emitidos por la autoridad de certificación externa.
- Está exportando un certificado de una base de datos NSS a un formato pkcs #12 que incluye tanto el certificado como la clave privada. Para obtener más detalles, consulte Sección 40.3.1, “Exportación de un certificado y una clave privada de una base de datos NSS a un archivo PKCS #12”.
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ón | Lectura humana | Extensiones comunes de nombres de archivos | Ejemplos de comandos IdM que aceptan el formato de codificación |
---|---|---|---|
PEM/base64 | Sí | .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 comandokinit -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 comandokinit -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 archivoPEM
se haya convertido al formatoUNIX
. Para convertir un archivo, utilice la utilidaddos2unix
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
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 utilidadopenssl 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:
Obtenga las credenciales del administrador:
$ kinit admin
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 utilidadsed
antes de añadir la cadena al comandoipa 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...
NotaNo puede pasar un archivo
PEM
que contenga el certificado como entrada al comandoipa 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.
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
Utilizando el
CLI
, convierta el certificado al formatoPEM
: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 utilidadopenssl 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:
-
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
ybase64
. - En la interfaz web de IdM, inicie sesión como responsable de seguridad.
-
Vaya a
Identity
→Users
→some_user
. -
Haga clic en
Add
junto aCertificates
. - Pegue el contenido del certificado en formato PEM en la ventana que se abre.
-
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:
- El certificado se encuentra en una base de datos NSS. Para saber cómo proceder en esta situación, consulte Sección 40.3.1, “Exportación de un certificado y una clave privada de una base de datos NSS a un archivo PKCS #12”.
-
El certificado y la clave privada están en dos archivos separados
PEM
. Para más detalles sobre cómo proceder en esta situación, consulte Sección 40.3.2, “Combinación de archivos PEM de certificados y claves privadas en un archivo PKCS #12”.
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
Utilice el comando
pk12util
para exportar el certificado de la base de datos NSS al formatoPKCS12
. Por ejemplo, para exportar el certificado con el apodosome_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 SUCCESSFULEstablezca 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 encertfile.key
en un archivocertfile.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
Comando | Formatos aceptables | Notas |
---|---|---|
| certificado PEM base64 | |
| Certificado PEM y DER; cadena de certificados PKCS#7; PKCS#8 y clave privada sin procesar; certificado y clave privada PKCS#12 | |
| DER; PEM; PKCS#7 | |
| Certificado PEM y DER; cadena de certificados PKCS#7 | |
| Certificado PEM y DER; cadena de certificados PKCS#7 | |
| N/A |
Crea el archivo |
| N/A |
Crea el archivo |
| N/A |
Crea el archivo |
| N/A |
Crea el archivo |
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.
- ¿Qué es un perfil de certificado?
- Creación de un modelo de certificado
- ¿Qué es una lista de control de acceso de CA?
- Definición de una ACL de CA para controlar el acceso a los perfiles de certificado
- Uso de perfiles de certificado y ACLs de CA para emitir certificados
- Modificación de un modelo de certificado
- Parámetros de configuración del modelo de certificado
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 comandoipa 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
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
Abra el archivo de configuración del perfil recién creado en un editor de texto.
$ vi smime.cfg
Cambie el
Profile ID
por un nombre que refleje el uso del perfil, por ejemplosmime
.NotaCuando 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.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
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 comandoipa 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 comandoipa 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
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
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
Añada el
smime_user
al gruposmime_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 -------------------------
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
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 -------------------------
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 comandoipa 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.
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
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'
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 comandoipa help user-show
. -
Para más detalles sobre el comando
ipa cert-request
, consulte el comandoipa 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
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 --------------------------
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
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.
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 comandoipa 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ámetro | Descripción |
---|---|
desc |
Una descripción de texto libre del modelo de certificado, que se muestra en la página de entidades finales. Por ejemplo, |
activar |
Habilita el perfil para que sea accesible a través de la página de entidades finales. Por ejemplo, |
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, |
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
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, |
lista.de entrada |
Enumera las entradas permitidas para el modelo de certificado por su nombre. Por ejemplo, |
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, |
lista de salida |
Enumera los posibles formatos de salida del modelo de certificado por su nombre. Por ejemplo, |
output.output_id.class_id |
Especifica el nombre de la clase java para el formato de salida nombrado en output.list. Por ejemplo, |
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.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, |
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:
Renueve un certificado solicitando un nuevo certificado utilizando la solicitud de firma de certificado (CSR) original o una nueva CSR generada a partir de la clave privada. Puede solicitar un nuevo certificado utilizando las siguientes utilidades:
- certmonger
-
Puede utilizar
certmonger
para solicitar un certificado de servicio. Antes de que el certificado caduque,certmonger
renovará automáticamente el certificado, garantizando así la validez continua del certificado de servicio. Para más detalles, consulte Obtención de un certificado IdM para un servicio mediante certmonger; - certutil
-
Puede utilizar
certutil
para renovar los certificados de usuario, host y servicio. Para obtener detalles sobre la solicitud de un certificado de usuario, consulte Solicitar un nuevo certificado de usuario y exportarlo al cliente; - openssl
-
Puede utilizar
openssl
para renovar los certificados de usuario, host y servicio.
Revocar un certificado. Para más detalles, consulte:
Restaurar un certificado si ha sido revocado temporalmente. Para más detalles, consulte:
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
-
En el menú
Authentication
, haga clic enCertificates
>Certificates
. 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
-
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
ID | Razón | Explicació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
-
Haga clic en
Authentication
>Certificates
>Certificates
. 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
- En la página de información del certificado, haga clic en Acciones → Revocar certificado.
- 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
Utilice el comando
ipa cert-revoke
, y especifique:- el número de serie del certificado
- el número de identificación del motivo de la revocación; consulte Sección 42.2.1, “Motivos de revocación de certificados” para más detalles
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
-
En el menú
Authentication
, haga clic enCertificates
>Certificates
. 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
- En la página de información del certificado, haga clic en Acciones → Restaurar 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:
- 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.
Un administrador tiene que crear una regla de asignación de certificados para permitir el inicio de sesión en IdM de un usuario
- cuya cuenta contiene una entrada de datos de asignación de certificados
- 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:
- La entrada de usuario AD contiene el certificado completo. Para obtener más información sobre cómo configurar IdM en este caso, consulte Configuración de la asignación de certificados para usuarios cuya entrada de usuario de AD contiene el certificado completo.
-
AD está configurado para asignar certificados de usuario a cuentas de usuario. En este caso, la entrada de usuario de AD no contiene el certificado completo, sino que contiene un atributo denominado
altSecurityIdentities
. Para obtener más información sobre cómo configurar IdM en este caso, consulte Configuración de la asignación de certificados si AD está configurado para asignar certificados de usuario a cuentas de usuario. -
La entrada del usuario AD no contiene ni el certificado completo ni los datos de asignación. En este caso, la única solución es utilizar el comando
ipa idoverrideuser-add
para añadir el certificado completo a la anulación del ID del usuario AD en IdM. Para obtener más información, consulte 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.
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
yclientAuth 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
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 valorRFC2253
para mostrar la salida con el nombre distinguido relativo (RDN) más específico primeroSi 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
-
la opción
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 dominioad.example.com
y el asunto del certificado debe coincidir con la entradacertmapdata
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
- Inicie sesión en la interfaz web de IdM como administrador.
-
Navegue hasta
Authentication
→Certificate Identity Mapping Rules
→Certificate Identity Mapping Rules
. Haga clic en
Add
.Figura 43.1. Añadir una nueva regla de asignación de certificados en la interfaz web de IdM
- Introduzca el nombre de la regla.
Introduzca la regla de asignación. Por ejemplo, para que el IdM busque las entradas
Issuer
ySubject
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})
Introduzca la regla de coincidencia. Por ejemplo, para permitir sólo los certificados emitidos por la
Smart Card CA
de la organizaciónEXAMPLE.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
-
Haga clic en
Add
en la parte inferior del cuadro de diálogo para añadir la regla y cerrar el cuadro. 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
Obtenga las credenciales del administrador:
# kinit admin
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
ySubject
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 elSmart Card CA
de la organizaciónEXAMPLE.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: TRUEEl 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
- Inicie sesión en la interfaz web de IdM como administrador.
-
Navegue hasta
Users
→Active users
→idm_user
. -
Busque la opción
Certificate mapping data
y haga clic enAdd
. Si tiene el certificado de
idm_user
a su disposición: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...]
- Copie el certificado.
En la interfaz web de IdM, haz clic en
Add
junto aCertificate
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
Alternativamente, si no tiene el certificado de
idm_user
a su disposición pero conoce elIssuer
y elSubject
del certificado, marque el botón de radio deIssuer 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
-
Haga clic en
Add
. Opcionalmente, si tiene acceso al certificado completo en el formato
.pem
, verifique que el usuario y el certificado están vinculados:Utilice la utilidad
sss_cache
para invalidar el registro deidm_user
en la caché de SSSD y forzar una recarga de la información deidm_user
:# sss_cache -u idm_user
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 comoidm_user
.
43.2.2.2. Adición de datos de asignación de certificados a una entrada de usuario en la CLI de IdM
Obtenga las credenciales del administrador:
# kinit admin
Si dispone del certificado de
idm_user
, añada el certificado a la cuenta de usuario mediante el comandoipa 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 elIssuer
y elSubject
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
Opcionalmente, si tiene acceso al certificado completo en el formato
.pem
, verifique que el usuario y el certificado están vinculados:Utilice la utilidad
sss_cache
para invalidar el registro deidm_user
en la caché de SSSD y forzar una recarga de la información deidm_user
:# sss_cache -u idm_user
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 comoidm_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
- Inicie sesión en la interfaz web de IdM como administrador.
-
Navegue hasta
Authentication
→Certificate Identity Mapping Rules
→Certificate Identity Mapping Rules
. Haga clic en
Add
.Figura 43.5. Añadir una nueva regla de asignación de certificados en la interfaz web de IdM
- Introduzca el nombre de la regla.
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})
Introduzca la regla de coincidencia. Por ejemplo, para permitir que sólo se autentifiquen los certificados emitidos por el
AD-ROOT-CA
del dominioAD.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
-
Haga clic en
Add
. 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
Obtenga las credenciales del administrador:
# kinit admin
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 dominioAD.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: TRUEEl 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 IdMcertmapdata
. - 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
- Inicie sesión en la interfaz web de IdM como administrador.
-
Navegue hasta
Authentication
→Certificate Identity Mapping Rules
→Certificate Identity Mapping Rules
. Haga clic en
Add
.Figura 43.7. Añadir una nueva regla de asignación de certificados en la interfaz web de IdM
- Introduzca el nombre de la regla.
Introduzca la regla de asignación. Por ejemplo, para hacer que AD DC busque las entradas
Issuer
ySubject
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})
Introduzca la regla de coincidencia. Por ejemplo, para permitir sólo los certificados emitidos por el
AD-ROOT-CA
del dominioAD.EXAMPLE.COM
para autenticar a los usuarios en el IdM:<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
Introduzca el dominio:
ad.example.com
Figura 43.8. Regla de asignación de certificados si AD está configurado para la asignación
-
Haga clic en
Add
. 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
Obtenga las credenciales del administrador:
# kinit admin
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
ySubject
en cualquier certificado presentado, y sólo permita certificados emitidos por elAD-ROOT-CA
del dominioAD.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
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 dead_user
. La regla del partido estipula que se aplican las siguientes condiciones:
-
El certificado que
ad_user
utiliza para autenticarse en AD fue emitido porAD-ROOT-CA
del dominioad.example.com
. -
El tema es
<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user
:
-
El certificado que
$ 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
-
El atributo
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 IdMcertmapdata
. -
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
- Inicie sesión en la interfaz web de IdM como administrador.
-
Navegue hasta
Authentication
→Certificate Identity Mapping Rules
→Certificate Identity Mapping Rules
. Haga clic en
Add
.Figura 43.9. Añadir una nueva regla de asignación de certificados en la interfaz web de IdM
- Introduzca el nombre de la regla.
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})
Introduzca la regla de coincidencia. Por ejemplo, para permitir que sólo se autentifiquen los certificados emitidos por el
AD-ROOT-CA
del dominioAD.EXAMPLE.COM
:<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
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
-
Haga clic en
Add
. 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
Obtenga las credenciales del administrador:
# kinit admin
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 dominioAD.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: TRUEEl 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
-
Navegue hasta
Identity
→ID Views
→Default Trust View
. Haga clic en
Add
.Figura 43.11. Añadir un nuevo ID de usuario en la interfaz web de IdM
-
En el campo
User to override
, introduzcaad_user@ad.example.com
. Copie y pegue el certificado de
ad_user
en el campoCertificate
.Figura 43.12. Configuración de la anulación del ID de usuario para un usuario de AD
-
Haga clic en
Add
. Opcionalmente, verifique que el usuario y el certificado están vinculados:
Utilice la utilidad
sss_cache
para invalidar el registro dead_user@ad.example.com
en la caché de SSSD y forzar una recarga de la información dead_user@ad.example.com
:# sss_cache -u ad_user@ad.example.com
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 comoad_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
Obtenga las credenciales del administrador:
# kinit admin
Añada el certificado de
ad_user@ad.example.com
a la cuenta de usuario mediante el comandoipa 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
Opcionalmente, verifique que el usuario y el certificado están vinculados:
Utilice la utilidad
sss_cache
para invalidar el registro dead_user@ad.example.com
en la caché de SSSD y forzar una recarga de la información dead_user@ad.example.com
:# sss_cache -u ad_user@ad.example.com
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 comoad_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 atributoipacertmapdata
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 atributoaltSecurityIdentities
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 localidm.example.com
sino también en el dominioad.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:
-
userCertificate;binary={cert!bin}
es un filtro que devuelve las entradas de usuario que incluyen el certificado completo. En el caso de los usuarios de AD, la creación de este tipo de filtro se describe detalladamente en Añadir una regla de asignación de certificados si la entrada de usuario de AD no contiene ningún certificado ni datos de asignación. -
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 atributoipacertmapdata
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 atributoaltSecurityIdentities
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 de usuario.
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,
- puede omitir Sección 44.2, “Solicitar un nuevo certificado de usuario y exportarlo al cliente” si el usuario que desea autenticar utilizando un certificado ya tiene un certificado;
- puede omitir Sección 44.3, “Asegurarse de que el certificado y el usuario están vinculados” si el certificado del usuario ha sido emitido por la CA de IdM.
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:
En un servidor de gestión de identidades, obtenga privilegios de administrador y cree un script de shell para configurar el servidor.
Ejecute el comando
ipa-advise config-server-for-smart-card-auth
, y guarde su salida en un archivo, por ejemploserver_certificate_script.sh
:# kinit admin # ipa-advise config-server-for-smart-card-auth >
server_certificate_script.sh
Añade permisos de ejecución al archivo utilizando la utilidad
chmod
:# chmod x
server_certificate_script.sh
En todos los servidores del dominio de Gestión de Identidades, ejecute el script
server_certificate_script.sh
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
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
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.
Puede omitir esta sección si el usuario que desea autenticar utilizando un certificado ya tiene un certificado.
Procedimiento
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: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 bits4096
para el usuarioidm_user
en el ámbitoIDM.EXAMPLE.COM
, estableciendo el apodo de las claves privadas del certificado comoidm_user
para facilitar su localización, y estableciendo el asunto comoCN=idm_user,O=IDM.EXAMPLE.COM
:# certutil -R -d
~/certdb/
-a -g4096
-nidm_user
-s \ "CN=idm_user
,O=IDM.EXAMPLE.COM" >certificate_request.csr
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:
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 seguridadidm_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
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 apodoidm_user
que está almacenado en el archivo~/idm_user.pem
en la base de datos~/certdb/
:# certutil -A -d
~/certdb/
-nidm_user
-t \ "P,," -i~/idm_user.pem
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_userUtilice el comando
pk12util
para exportar el certificado de la base de datos NSS al formato PKCS12. Por ejemplo, para exportar el certificado con el apodoidm_user
de la base de datos NSS/root/certdb
al archivo~/idm_user.p12
:# pk12util -d
~/certdb
-o~/idm_user.p12
-nidm_user
Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: Re-enter password: pk12util: PKCS12 EXPORT SUCCESSFULTransfiera 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/
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/
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
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).
- Si el certificado lo proporciona una autoridad de certificación que no forma parte de su entorno de gestión de identidades, vincule el usuario y el certificado siguiendo el procedimiento descrito en Vinculación de cuentas de usuario con certificados.
- Si el certificado lo proporciona la CA de Gestión de identidades, el certificado ya se añade automáticamente en la entrada del usuario y no tiene que vincular el certificado a la cuenta de usuario. Para obtener más información sobre la creación de un nuevo certificado en IdM, consulte Sección 44.2, “Solicitar un nuevo certificado de usuario y exportarlo al cliente”.
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
- Tienes a tu disposición el certificado de usuario que quieres importar al navegador en el formato PKCS#12.
Procedimiento
Abra Firefox y, a continuación, vaya a
Preferences
→Privacy & Security
.Figura 44.1. Sección de privacidad y seguridad en Preferencias
Haga clic en Ver Certificados.
Figura 44.2. Ver Certificados en Privacidad y Seguridad
-
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. Asegúrese de que la Autoridad de Certificación de Gestión de Identidades es reconocida por Firefox como una autoridad de confianza:
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
Add Exception
. Haga clic enView
.Figura 44.4. Ver los detalles de un certificado
En la pestaña
Details
, resalte los camposCertificate Authority
.Figura 44.5. Exportación del certificado CA
-
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.
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
Haga clic en Ver Certificados.
Figura 44.7. Ver Certificados en Privacidad y Seguridad
-
En la pestaña
Authorities
, haga clic en Importar. Localice y abra el certificado CA que guardó en el paso anterior en el archivoCertificateAuthority.crt
. Confíe en el certificado para identificar los sitios web y, a continuación, haga clic en Aceptar y en OK.
- 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
-
En el navegador, navegue hasta la interfaz web de Gestión de Identidades en, por ejemplo,
https:
//server.idm.example.com/ipa/ui
. Haga clic en Login Using Certificate.
.Inicio de sesión mediante certificado en la interfaz web de gestión de identidades
- 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 atributoX509_username:/path/to/file.p12
para especificar dónde encontrar la información de identidad X509 del usuario. Por ejemplo, para obtener el TGT paraidm_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
NotaEl 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.
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
Obtenga las credenciales del administrador de IdM:
~]$ kinit admin Password for admin@IDM.EXAMPLE.COM:
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.
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
.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
ImportanteTambié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.
-
el comando
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
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
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
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.
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 predeterminadasubCA
, 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 successfulSi 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 successfulLa salida muestra que se ha creado un CSR y que está almacenado en el archivo
/var/lib/ipa/ca.csr
.
-
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. 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.
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
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
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.
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
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:
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.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
Reinicie IdM con el parámetro
--force
:# ipactl restart --force
Con el parámetro
--force
, la utilidadipactl
ignora los fallos de inicio de servicios individuales. Por ejemplo, si el servidor es también una CA con certificados caducados, el serviciopki-tomcat
no se inicia. Esto es esperado e ignorado por el uso del parámetro--force
.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.Si el servidor es también una CA, el comando anterior informa
CA_UNREACHABLE
para el certificado que utiliza el serviciopki-tomcat
:Request ID '20190522120835': status: CA_UNREACHABLE subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205 ...
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
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
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
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
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
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 elcommand-line interface
(CLI), que permite al administrador del sistema enviar activamente comandos al demoniocertmonger
.
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
En el cliente
my_company.idm.example.com
IdM en el que se ejecuta el servicioHTTP
, solicite un certificado para el servicio correspondiente a la entidad de seguridadHTTP/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 demy_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 comandoipa-getcert request
es un atajo paragetcert 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 deSubjectAltName
que se añadirá a la solicitud. -
La opción
-C
indica acertmonger
que reinicie el serviciohttpd
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
.
NotaRHEL 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.-
El comando
-
El certificado debe almacenarse en el archivo local
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”
- Figura 48.2, “Certmonger solicita un certificado de servicio”
- Figura 48.3, “CA IdM que emite el certificado de servicio”
- Figura 48.4, “Certmonger aplicando el certificado de servicio”
- Figura 48.5, “Certmonger solicita un nuevo certificado cuando el antiguo está a punto de caducar”
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
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
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
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
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
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:
- En el servidor IdM, se crea un certificado para un sistema que aún no existe.
- Crea el nuevo sistema.
- Se inscribe el nuevo sistema como cliente de IdM.
- Importa el certificado y la clave del servidor IdM al cliente IdM.
-
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 valorIPA
al comandogetcert 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
.
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 manualgetcert 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
Obtenga el PIN de los certificados CA del subsistema:
# grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
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"'
Añade el seguimiento de los certificados IdM restantes, los certificados
HTTP
,LDAP
,IPA renewal agent
yPKINIT
:# 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
Reiniciar
certmonger
:# systemctl restart certmonger
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 sistemacertificate
, 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
.
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.
NotaNo 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
Optional: Crear un archivo de inventario, por ejemplo
inventory.file
:$ touch inventario.archivo
Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:
[webserver] server.idm.example.com
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 ejemplowebserver
. Establezca la variable
certificate_requests
para incluir lo siguiente:-
Establezca el parámetro
name
con el nombre deseado para el certificado, como por ejemplomycert
. -
Establezca el parámetro
dns
con el dominio que se incluirá en el certificado, como por ejemplo*.example.com
. -
Ajuste el parámetro
ca
aself-sign
.
-
Establezca el parámetro
Establezca la función
rhel-system-roles.certificate
enroles
.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
-
Configure
- Guarda el archivo.
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 sistemacertificate
, 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 manualansible-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
.
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.
NotaNo 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
Optional: Crear un archivo de inventario, por ejemplo
inventory.file
:$ touch inventario.archivo
Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:
[webserver] server.idm.example.com
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 ejemplowebserver
. Establezca la variable
certificate_requests
para incluir lo siguiente:-
Establezca el parámetro
name
con el nombre deseado para el certificado, como por ejemplomycert
. -
Establezca el parámetro
dns
con el dominio que se incluirá en el certificado, como por ejemplowww.example.com
. -
Establezca el parámetro
principal
para especificar la entidad principal de Kerberos, comoHTTP/www.example.com@EXAMPLE.COM
. -
Ajuste el parámetro
ca
aipa
.
-
Establezca el parámetro
Establezca la función
rhel-system-roles.certificate
enroles
.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
-
Configure
- Guarda el archivo.
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 sistemacertificate
, 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 manualansible-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.
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.
NotaNo 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
Optional: Crear un archivo de inventario, por ejemplo
inventory.file
:$ touch inventario.archivo
Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:
[webserver] server.idm.example.com
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 ejemplowebserver
. Establezca la variable
certificate_requests
para incluir lo siguiente:-
Establezca el parámetro
name
con el nombre deseado para el certificado, como por ejemplomycert
. -
Establezca el parámetro
dns
con el dominio que se incluirá en el certificado, como por ejemplowww.example.com
. -
Establezca el parámetro
ca
en la CA que desea utilizar para emitir el certificado, como por ejemploself-sign
. -
Establezca el parámetro
run_before
con el comando que desea ejecutar antes de que se emita o renueve este certificado, comosystemctl 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, comosystemctl start httpd.service
.
-
Establezca el parámetro
Establezca la función
rhel-system-roles.certificate
enroles
.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
-
Configure
- Guarda el archivo.
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 sistemacertificate
, 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 manualansible-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:
- Crear una sub-CA de IdM
- Descargue el certificado sub-CA desde IdM WebUI
- Cree una ACL de CA especificando la combinación correcta de usuarios, servicios y CAs, y el perfil de certificado utilizado
- Solicitar un certificado para el servicio web que se ejecuta en un cliente IdM desde la sub-CA IdM
- Configurar un servidor HTTP Apache de una sola instancia
- Añadir el cifrado TLS al servidor HTTP Apache
- Establecer las versiones de protocolo TLS soportadas en un servidor HTTP Apache
- Establezca los cifrados admitidos en el servidor HTTP Apache
- Configurar la autenticación del certificado de cliente TLS en el servidor web
- Solicitar un certificado para el usuario a la sub-CA de IdM y exportarlo al cliente
- Importe el certificado de usuario en el navegador y configure el navegador para que confíe en el certificado sub-CA
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
- En el menú Authentication, haga clic en Certificates.
- Seleccione Certificate Authorities y haga clic en Add.
- 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.
- 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.
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
ImportanteSi 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.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,uNotaEl 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
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.
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.COMEn 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
ImportanteSi 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.
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
NotaEl 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
En el menú Authentication, haga clic en Certificates > Certificates.
Figura 50.1. certificado sub-CA en la lista de certificados
- Haga clic en el número de serie del certificado sub-CA para abrir la página de información del certificado.
- En la página de información del certificado, haga clic en Actions > Download.
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
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
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
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
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
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 -------------------------
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 -------------------------
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.
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
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
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
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 -------------------------
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 -------------------------
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.
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
En el cliente
my_company.idm.example.com
IdM en el que se ejecuta el servicioHTTP
, solicite un certificado para el servicio correspondiente a la entidad de seguridadHTTP/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 demy_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 comandoipa-getcert request
es un atajo paragetcert 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 deSubjectAltName
que se añadirá a la solicitud. -
La opción
-X
especifica que el emisor del certificado debe serwebserver-ca
, noipa
. -
La opción
-C
indica acertmonger
que reinicie el serviciohttpd
después de obtener el certificado.
-
Para especificar que el certificado se emita con un perfil determinado, utilice la opción
-T
.
NotaRHEL 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.-
El comando
-
El certificado debe almacenarse en el archivo local
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:
- Figura 50.2, “Comunicación no encriptada”
- Figura 50.3, “Certmonger solicita un certificado de servicio”
- Figura 50.4, “CA IdM que emite el certificado de servicio”
- Figura 50.5, “Certmonger aplicando el certificado de servicio”
- Figura 50.6, “Certmonger solicita un nuevo certificado cuando el antiguo está a punto de caducar”
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
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
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
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
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
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
Instale el paquete
httpd
:# yum install httpd
Abra el puerto TCP
80
en el firewall local:# firewall-cmd --permanent --add-port=80/tcp # firewall-cmd --reload
Habilite e inicie el servicio
httpd
:# systemctl enable --now httpd
Opcional: Añada los archivos HTML al directorio
/var/www/html/
.NotaAl añadir contenido a
/var/www/html/
, los archivos y directorios deben ser legibles por el usuario bajo el cual se ejecutahttpd
por defecto. El propietario del contenido puede ser el usuarioroot
y el grupo de usuariosroot
, u otro usuario o grupo a elección del administrador. Si el propietario del contenido es el usuarioroot
y el grupo de usuariosroot
, los archivos deben poder ser leídos por otros usuarios. El contexto SELinux para todos los archivos y directorios debe serhttpd_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/
ohttp://server_IP/
.Si el directorio
/var/www/html/
está vacío o no contiene un archivoindex.html
oindex.htm
, Apache muestra elRed Hat Enterprise Linux Test Page
. Si/var/www/html/
contiene archivos HTML con un nombre diferente, puede cargarlos introduciendo la URL de ese archivo, comohttp://server_IP/example.html
ohttp://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 manhttpd.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
Instale el paquete
mod_ssl
:# dnf install mod_ssl
Edite el archivo
/etc/httpd/conf.d/ssl.conf
y añada la siguiente configuración a la directiva<VirtualHost _default_:443>
:Establezca el nombre del servidor:
Nombre del servidor my_company.idm.example.com
ImportanteEl nombre del servidor debe coincidir con la entrada establecida en el campo
Common Name
del certificado.Opcional: Si el certificado contiene nombres de host adicionales en el campo
Subject Alt Names
(SAN), puede configurarmod_ssl
para que proporcione cifrado TLS también para estos nombres de host. Para configurarlo, añada el parámetroServerAliases
con los nombres correspondientes:ServidorAlias www.my_company.idm.example.com server.my_company.idm.example.com
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"
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
AvisoSi 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.
Abra el puerto
443
en el firewall local:# firewall-cmd --permanent --add-port=443 # firewall-cmd --reload
Reinicie el servicio
httpd
:# systemctl restart httpd
NotaSi 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
.
-
Utilice un navegador y conéctese a
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) oTLS1.1
. -
Si quiere configurar que Apache sólo soporte el protocolo
TLSv1.2
oTLSv1.3
.
Requisitos previos
- El cifrado TLS está activado en el servidor my_company.idm.example.com como se describe en Sección 50.7, “Cómo añadir el cifrado TLS a un servidor HTTP Apache”.
Procedimiento
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 protocoloTLSv1.3
:SSLProtocolo -Todo TLSv1.3
Reinicie el servicio
httpd
:# systemctl restart httpd
Pasos de verificación
Utilice el siguiente comando para verificar que el servidor soporta
TLSv1.3
:# openssl s_client -connect example.com:443 -tls1_3
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
- Opcional: Repita el comando para otras versiones del protocolo TLS.
Recursos adicionales
-
Para más detalles sobre la política criptográfica a nivel de sistema, consulte la página man
update-crypto-policies(8)
y Using system-wide cryptographic policies. -
Para más detalles sobre el parámetro
SSLProtocol
, consulte la documentación demod_ssl
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.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
- El cifrado TLS está activado en el servidor my_company.idm.example.com como se describe en Sección 50.7, “Cómo añadir el cifrado TLS a un servidor HTTP Apache”.
Procedimiento
Edite el archivo
/etc/httpd/conf/httpd.conf
y añada el parámetroSSLCipherSuite
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
, yAES256 EDH
y desactiva todos los cifrados que utilizan el código de autenticación de mensajes (MAC)SHA1
ySHA256
.Reinicie el servicio
httpd
:# systemctl restart httpd
Pasos de verificación
Para mostrar la lista de cifrados que soporta el servidor HTTP Apache:
Instale el paquete
nmap
:# yum install nmap
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
-
Para más detalles sobre la política criptográfica a nivel de sistema, consulte la página man
update-crypto-policies(8)
y Using system-wide cryptographic policies. -
Para más detalles sobre el parámetro
SSLCipherSuite
, consulte la documentación demod_ssl
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.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/
.
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
- El cifrado TLS está activado en el servidor my_company.idm.example.com como se describe en Sección 50.7, “Cómo añadir el cifrado TLS a un servidor HTTP Apache”.
Procedimiento
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/
.Reinicie el servicio
httpd
:# systemctl restart httpd
Pasos de verificación
Utilice la utilidad
curl
para acceder a la URLhttps://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.
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 archivoindex.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
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: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 bits4096
para el usuarioidm_user
en el ámbitoIDM.EXAMPLE.COM
, estableciendo el apodo de las claves privadas del certificado comoidm_user
para facilitar su localización, y estableciendo el asunto comoCN=idm_user,O=IDM.EXAMPLE.COM
:# certutil -R -d
~/certdb/
-a -g4096
-nidm_user
-s \ "CN=idm_user
,O=IDM.EXAMPLE.COM" >certificate_request.csr
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:
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éditoidm_user
@IDM.EXAMPLE.COM
desdewebclient-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
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 apodoidm_user
que está almacenado en el archivo~/idm_user.pem
en la base de datos~/certdb/
:# certutil -A -d
~/certdb/
-nidm_user
-t \ "P,," -i~/idm_user.pem
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_userUtilice el comando
pk12util
para exportar el certificado de la base de datos NSS al formato PKCS12. Por ejemplo, para exportar el certificado con el apodoidm_user
de la base de datos NSS/root/certdb
al archivo~/idm_user.p12
:# pk12util -d
~/certdb
-o~/idm_user.p12
-nidm_user
Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: Re-enter password: pk12util: PKCS12 EXPORT SUCCESSFULTransfiera 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/
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/
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
- Tienes a tu disposición el certificado de usuario que quieres importar al navegador en el formato PKCS#12.
- Ha descargado el certificado sub-CA y lo tiene a su disposición en el formato PEM.
Procedimiento
Abra Firefox y, a continuación, vaya a
Preferences
→Privacy & Security
.Figura 50.7. Sección de privacidad y seguridad en Preferencias
Haga clic en Ver Certificados.
Figura 50.8. Ver Certificados en Privacidad y Seguridad
-
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. 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:
Abre Firefox, ve a Preferencias y haz clic en Privacidad & Seguridad.
Figura 50.9. Sección de privacidad y seguridad en Preferencias
Haga clic en Ver Certificados.
Figura 50.10. Ver Certificados en Privacidad y Seguridad
-
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 51. Invalidar rápidamente un grupo específico de certificados relacionados
Como administrador del sistema, si quiere ser capaz de invalidar un grupo específico de certificados relacionados rápidamente:
- Diseñe sus aplicaciones de forma que sólo confíen en los certificados emitidos por una sub-CA específica de Gestión de Identidades (IdM) ligera. Posteriormente, podrá invalidar todos estos certificados revocando únicamente el certificado de la sub-CA de Gestión de Identidades (IdM) que emitió estos certificados. Para obtener detalles sobre cómo crear y utilizar una sub-CA ligera en IdM, consulte Capítulo 50, Restringir una aplicación para que confíe sólo en un subconjunto de certificados.
Para asegurarse de que todos los certificados que han sido emitidos por la sub-CA de IdM que se va a revocar son inmediatamente inválidos, configure las aplicaciones que dependen de dichos certificados para que utilicen los respondedores OCSP de IdM. Por ejemplo, para configurar el navegador Firefox para que utilice respondedores OCSP, asegúrese de que la casilla de verificación
Query OCSP responder servers to confirm the current validity of certificates
esté marcada en las Preferencias de Firefox.En IdM, la lista de revocación de certificados (CRL) se actualiza cada cuatro horas.
Para invalidar todos los certificados emitidos por una sub-CA de IdM, revoque el certificado de la sub-CA de IdM. Además, desactive las ACL pertinentes de la CA y considere la posibilidad de desactivar la sub-CA de IdM. La desactivación de la sub-CA impide que la sub-CA emita nuevos certificados, pero permite que se produzcan respuestas del Protocolo de Estado de los Certificados en Línea (OCSP) para los certificados emitidos anteriormente, ya que se conservan las claves de firma de la sub-CA.
No elimine la sub-CA si utiliza OCSP en su entorno. Al eliminar la sub-CA se borran las claves de firma de la sub-CA, impidiendo la producción de respuestas OCSP para los certificados emitidos por esa sub-CA.
El único escenario en el que es preferible eliminar una sub-CA a desactivarla es cuando se quiere crear una nueva sub-CA con el mismo nombre distinguido (DN) del sujeto pero con una nueva clave de firma.
51.1. Desactivación de las ACL de CA en la CLI de IdM
Cuando desee retirar un servicio de IdM o un grupo de servicios de IdM, considere la posibilidad de deshabilitar cualquier ACL de CA existente.
Complete esta sección para desactivar la ACL TLS_web_server_authentication CA que restringe el servidor web que se ejecuta en su cliente IdM para solicitar un certificado que debe emitir la sub-CA webserver-ca
IdM, y para desactivar la ACL TLS_web_client_authentication CA que restringe a los usuarios de IdM para solicitar un certificado de usuario que debe emitir la sub-CA webclient-ca
IdM.
Procedimiento
Opcionalmente, para ver todas las ACL de la CA en su entorno IdM, introduzca el comando
ipa caacl-find
:$ ipa caacl-find ----------------- 3 CA ACLs matched ----------------- ACL name: hosts_services_caIPAserviceCert Enabled: TRUE ACL name: TLS_web_server_authentication Enabled: TRUE ACL name: TLS_web_client_authentication Enabled: TRUE
Opcionalmente, para ver los detalles de una CA ACL, introduzca el comando
ipa caacl-show
y especifique el nombre de la CA ACL:$ ipa caacl-show 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 CAs: webserver-ca Profiles: caIPAserviceCert Services: HTTP/rhel8server.idm.example.com@IDM.EXAMPLE.COM
Para desactivar una CA ACL, introduzca el comando
ipa caacl-disable
y especifique el nombre de la CA ACL.Para desactivar la ACL de TLS_web_server_authentication CA, introduzca:
$ ipa caacl-disable TLS_web_server_authentication ------------------------------------------------- Disabled CA ACL "TLS_web_server_authentication" -------------------------------------------------
Para desactivar la ACL de TLS_web_client_authentication CA, introduzca:
$ ipa caacl-disable TLS_web_client_authentication ------------------------------------------------- Disabled CA ACL "TLS_web_client_authentication" -------------------------------------------------
La única ACL de CA habilitada ahora es la ACL de CA de hosts_services_caIPAserviceCert.
ImportanteTenga mucho cuidado al desactivar la ACL de la CA
hosts_services_caIPAserviceCert
. Desactivarhosts_services_caIPAserviceCert
, sin otra ACL de CA que conceda a los servidores IdM el uso de la CAipa
con el perfilcaIPAserviceCert
significa que la renovación de los certificados IdMHTTP
yLDAP
fallará. Los certificados IdMHTTP
yLDAP
caducados acabarán provocando un fallo del sistema IdM.
51.2. Desactivación de una sub-CA de IdM
Después de revocar el certificado de CA de una sub-CA de IdM para invalidar todos los certificados emitidos por esa sub-CA, considere la posibilidad de desactivar la sub-CA de IdM si ya no la necesita. Puede volver a habilitar la sub-CA más adelante.
La desactivación de la sub-CA impide que la sub-CA emita nuevos certificados, pero permite que se produzcan respuestas del Protocolo de Estado de Certificados en Línea (OCSP) para los certificados emitidos anteriormente, ya que se conservan las claves de firma de la sub-CA.
Requisitos previos
- Has iniciado la sesión como administrador de IdM.
Procedimiento
Introduzca el comando
ipa ca-disable
y especifique el nombre de la sub-CA:$ ipa ca-disable webserver-CA -------------------- Disabled CA "webserver-CA" --------------------
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:
- El concepto de bóveda.
- Los diferentes roles asociados a una bóveda.
- Los diferentes tipos de bóvedas disponibles en IdM en función del nivel de seguridad y control de acceso.
- Los diferentes tipos de bóvedas disponibles en IdM en función de la propiedad.
- El concepto de contenedores acorazados.
- Los comandos básicos para la gestión de almacenes en IdM.
- Instalación de la autoridad de recuperación de claves (KRA), que es un requisito previo para utilizar bóvedas en IdM.
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.
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.
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.
NotaLas 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, comoipa 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
- Determinados privilegios de los propietarios y miembros dependen del tipo de cámara acorazada. Consulte Bóvedas estándar, simétricas y asimétricas para obtener más detalles.
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
Tipo | Descripción | Propietario | Nota |
---|---|---|---|
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
Tipo | Descripción | Propó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.
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
Comando | Propósito |
---|---|
| Muestra información conceptual sobre los almacenes IdM y ejemplos de comandos de almacén. |
|
Al añadir la opción |
| 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 |
| 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
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
- El componente del sistema de certificados de la Autoridad de recuperación de claves (KRA) se ha instalado en uno o varios 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.
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
Obtenga el ticket de concesión de tickets de Kerberos (TGT) para
idm_user
:$ kinit idm_user
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
ImportanteAsegú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 parauser1
, el propietario del contenedor del almacén de usuario será tambiénadmin
, yuser1
no podrá acceder al almacén de usuario ni crear nuevos almacenes de usuario.Utilice el comando
ipa vault-archive
con la opción--in
para archivar el archivosecret.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
SSH a idm_client como idm_user:
$ ssh idm_user@idm_client.idm.example.com
Inicie sesión como
idm_user
:$ kinit user
Utilice el comando
ipa vault-retrieve --out
con la opción--out
para recuperar el contenido de la bóveda y guardarlo en el archivosecret_exported.txt
.$ ipa vault-retrieve my_vault --out secret_exported.txt -------------------------------------- Retrieved data from vault "my_vault" --------------------------------------
Recursos adicionales
- Puede utilizar Ansible para automatizar el proceso de gestión de los almacenes de usuarios de IdM. Para obtener más información, consulte Uso de Ansible para gestionar los almacenes de usuarios de IdM: almacenamiento y recuperación de secretos.
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
- El componente del sistema de certificados de la Autoridad de recuperación de claves (KRA) se ha instalado en uno o varios 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.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Cree un archivo de inventario, por ejemplo inventory.file:
$ touch inventory.file
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
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
- Abra el archivo ensure-standard-vault-is-present-copy.yml para editarlo.
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
-
Establezca la variable
- Guarda el archivo.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
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
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
- Abra el archivo data-archive-in-standard-vault-copy.yml para editarlo.
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
-
Establezca la variable
- Guarda el archivo.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
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
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
- Abra el archivo retrieve-data-standard-vault.yml-copy.yml para editarlo.
-
Adapte el archivo ajustando la variable
hosts
a ipahost. 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
-
Establezca la variable
- Guarda el archivo.
Ejecuta el libro de jugadas:
$ ansible-playbook -v -i inventory.file retrieve-data-standard-vault.yml-copy.yml
Pasos de verificación
SSH
a host01 como user01:$ ssh user01@host01.idm.example.com
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:
-
Genere una clave privada utilizando, por ejemplo, la utilidad
openssl
. - 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
- El componente del sistema de certificados de la Autoridad de recuperación de claves (KRA) se ha instalado en uno o varios 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.
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
Inicie sesión como administrador:
$ kinit admin
Obtener la clave pública de la instancia de servicio. Por ejemplo, utilizando la utilidad
openssl
: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)
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
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.
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
- Tiene acceso al keytab de la entidad principal de servicio propietaria de la bóveda de servicio, por ejemplo HTTP/webserver.idm.example.com.
- Has creado una cámara acorazada asimétrica y has archivado un secreto en ella.
- Tiene acceso a la clave privada utilizada para recuperar el secreto de la bóveda de servicio.
Procedimiento
Inicie sesión como administrador:
$ kinit admin
Obtener un ticket Kerberos para el servicio:
# kinit HTTP/webserver.idm.example.com -k -t /etc/httpd/conf/ipa.keytab
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
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.
- 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
- Puede utilizar Ansible para automatizar el proceso de gestión de los almacenes de servicios IdM. Para obtener más información, consulte Uso de Ansible para gestionar almacenes de servicios de IdM: almacenamiento y recuperación de secretos.
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:
-
Genere una clave privada utilizando, por ejemplo, la utilidad
openssl
. - 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
- El componente del sistema de certificados de la Autoridad de recuperación de claves (KRA) se ha instalado en uno o varios 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.
Esta sección incluye estos procedimientos:
- Garantizar la presencia de una bóveda de servicio asimétrica en IdM utilizando Ansible
- Almacenamiento de un secreto de servicio IdM en una bóveda asimétrica mediante Ansible
- Recuperación de un secreto de servicio para un servicio IdM mediante Ansible
- Cambiar el secreto de la bóveda de un servicio IdM cuando está comprometido usando Ansible
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Obtener la clave pública de la instancia de servicio. Por ejemplo, utilizando la utilidad
openssl
: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)
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
Opcional: Crear un archivo de inventario si no existe, por ejemplo inventory.file:
$ touch inventory.file
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
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
- Abra el archivo ensure-asymmetric-vault-is-present-copy.yml para editarlo.
- Añade una tarea que copie la clave pública service-public.pem desde el controlador de Ansible al servidor server.idm.example.com.
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
-
Establezca la variable
- Guarda el archivo.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Opcional: Crear un archivo de inventario si no existe, por ejemplo inventory.file:
$ touch inventory.file
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
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
- Abra el archivo data-archive-in-asymmetric-vault-copy.yml para editarlo.
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
enmember
.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
-
Establezca la variable
- Guarda el archivo.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Opcional: Crear un archivo de inventario si no existe, por ejemplo inventory.file:
$ touch inventory.file
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
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
- Abra el archivo data-archive-in-asymmetric-vault-copy.yml para editarlo.
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
enmember
.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
-
Establezca la variable
- Guarda el archivo.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
Opcional: Crear un archivo de inventario si no existe, por ejemplo inventory.file:
$ touch inventory.file
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
-
Defina su servidor IdM en la sección
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
- Abra el archivo retrieve-data-asymmetric-vault-copy.yml para editarlo.
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
enmember
.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
-
Establece la variable
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
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
- Guarda el archivo.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/vault
:$ cd /usr/share/doc/ansible-freeipa/playbooks/vault
-
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: 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
ImportanteAsegúrese de que la lista no contiene el servidor web comprometido, en el ejemplo actual webserver3.idm.example.com.
-
El servidor IdM en la sección
- Abra el archivo data-archive-in-asymmetric-vault-copy.yml para editarlo.
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
enmember
.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
-
Establezca la variable
- Guarda el archivo.
Ejecuta el libro de jugadas:
$ ansible-playbook -v -i inventory.file data-archive-in-asymmetric-vault-copy.yml
- Abra el archivo retrieve-data-asymmetric-vault-copy.yml para editarlo.
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
enmember
.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
-
Establece la variable
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
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
- Guarda el archivo.
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:
Comprueba que un servicio instalado manualmente está presente en un cliente IdM e instala automáticamente ese servicio si está ausente. Para más detalles, consulte:
Comprueba que un servicio inscrito en IdM tiene un certificado adjunto e instala automáticamente ese certificado si no lo tiene. Para más detalles, consulte:
Permitir a los usuarios y hosts de IdM recuperar y crear el llavero de servicio. Para más detalles, véase:
Permite a los usuarios y hosts de IdM añadir un alias de Kerberos a un servicio. Para más detalles, consulte:
Comprueba que un servicio no está presente en un cliente IdM y elimina automáticamente ese servicio si está presente. Para más detalles, consulte:
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
Cree un archivo de inventario, por ejemplo
inventory.file
:$ touch inventory.file
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
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
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
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 tareaipaservice
.
-
Cambia la contraseña del administrador de IdM definida por la variable
- Guarde y salga del archivo.
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
- Inicie sesión en la interfaz web de IdM como administrador de IdM.
-
Navegue hasta
Identity
→Services
.
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
- Puede asegurar la comunicación entre el servidor HTTP y los clientes del navegador añadiendo encriptación TLS a un servidor HTTP Apache.
- Puede solicitar un certificado para el servicio HTTP a una autoridad de certificación IdM. Para más información, consulte el procedimiento descrito en Obtención de un certificado IdM para un servicio mediante certmonger.
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
- Ha instalado un servicio HTTP en su host.
- El host en el que has configurado HTTP no es un cliente de IdM. Si no es así, siga los pasos de Garantizar la presencia de un servicio HTTP en IdM mediante un playbook de Ansible.
- Tienes la contraseña de administrador de IdM.
- El registro DNS A - o el registro AAAA si se utiliza IPv6 - para el host está disponible.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
:$ touch inventory.file
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
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
Abra el archivo copiado,
/usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check-copy.yml
, para editarlo. Localice las variablesipaadmin_password
yname
en la tareaipaservice
:--- - 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
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.
-
Establece la variable
- Guarde y salga del archivo.
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
- Inicie sesión en la interfaz web de IdM como administrador de IdM.
-
Navegue hasta
Identity
→Services
.
Ahora puede ver HTTP/client.idm.example.com@IDM.EXAMPLE.COM en la lista Services.
Recursos adicionales
- Puede asegurar la comunicación entre el servidor HTTP y los clientes del navegador añadiendo encriptación TLS a un servidor HTTP Apache.
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
- El sistema que aloja el servicio HTTP está inscrito en IdM.
- Es posible que no exista el registro DNS A o DNS AAAA para el host. De lo contrario, si el registro DNS para el host existe, siga el procedimiento en Asegurar la presencia de un servicio HTTP en IdM utilizando un libro de jugadas de Ansible.
- Tienes la contraseña de administrador de IdM.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
:$ touch inventory.file
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
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
Abra el archivo copiado,
/usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml
, para editarlo. Localice las variablesipaadmin_password
yname
en la tareaipaservice
:--- - 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
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.
-
Establece la variable
- Guarde y salga del archivo.
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
- Inicie sesión en la interfaz web de IdM como administrador de IdM.
-
Navegue hasta
Identity
→Services
.
Ahora puede ver HTTP/client.idm.example.com@IDM.EXAMPLE.COM en la lista Services.
Recursos adicionales
- Puede asegurar la comunicación entre el servidor HTTP Apache y los clientes del navegador añadiendo encriptación TLS al servidor HTTP Apache.
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
- Ha instalado un servicio HTTP en su host.
- Ha inscrito el servicio HTTP en IdM.
- Tienes la contraseña de administrador de IdM.
- Dispone de un certificado firmado externamente cuyo Asunto se corresponde con el principal del servicio HTTP.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
:$ touch inventory.file
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
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
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
Decodifique el archivo
DER
a la salida estándar utilizando el comandobase64
. Utilice la opción-w0
para deshabilitar el envoltorio:$ base64 cert1.der -w0 MIIC/zCCAeegAwIBAgIUV74O+4kXeg21o4vxfRRtyJm...
- Copiar el certificado de la salida estándar al portapapeles.
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
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 variablecertificate:
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.
-
Sustituya el certificado, definido mediante la variable
- Guarde y salga del archivo.
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
- Inicie sesión en la interfaz web de IdM como administrador de IdM.
-
Navegue hasta
Identity
→Services
. - 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
Cree un archivo de inventario, por ejemplo
inventory.file
:$ touch inventory.file
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
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
-
Abra el archivo
/usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml
Ansible playbook para editarlo. 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óntasks
.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
-
La contraseña del administrador de IdM especificada por la variable
- Guarda el archivo.
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
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:
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
Cree un archivo de inventario, por ejemplo
inventory.file
:$ toque inventory.file
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
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
-
Abra el archivo copiado,
/usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml
, para editarlo: Adapte el archivo:
-
Establece la variable
ipaadmin_password
con tu contraseña de administrador de IdM. -
Establezca la variable
name
de la tareaipaservice
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óntasks
.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
-
Establece la variable
- Guarda el archivo.
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
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:
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
- Conoce la contraseña del administrador de IdM.
- Ha instalado el paquete ansible-freeipa en el controlador de Ansible.
- Ha configurado un servicio HTTP en su host.
- Ha inscrito el servicio HTTP en IdM.
- El host en el que has configurado HTTP es un cliente IdM.
Procedimiento
Cree un archivo de inventario, por ejemplo
inventory.file
:$ touch inventory.file
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
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
-
Abra el archivo
/usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml
Ansible playbook para editarlo. 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 variablename
. En el ejemplo actual, es host/mycompany.idm.example.com. El nombre de la tarea especificada por la variable
name
en la seccióntasks
.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
-
La contraseña del administrador de IdM especificada por la variable
- Guarda el archivo.
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
- Para obtener más información sobre los alias de entidades de seguridad de Kerberos y su gestión sin Ansible, consulte Gestión de alias de entidades de seguridad de Kerberos para usuarios, hosts y servicios.
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
Cree un archivo de inventario, por ejemplo
inventory.file
:$ touch inventory.file
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
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
-
Abra el archivo
/usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml
Ansible playbook para editarlo. 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 tareaipaservice
.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
-
La contraseña del administrador de IdM definida por la variable
- Guarde y salga del archivo.
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
- Inicie sesión en la interfaz web de IdM como administrador de IdM.
-
Navegue hasta
Identity
→Services
.
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.
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.
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
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 grupoadmins
:# 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.
Destruye el ticket Kerberos actual del administrador de IdM:
# kdestroy -A
NotaLa 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.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:
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.
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
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 ----------------------------
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
Autenticarse en el IdM como usuario de
admin
:$ kinit admin
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 hostdemo.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
Ajuste el parámetro
dns_canonicalize_hostname
en la sección[libdefaults]
del archivo/etc/krb5.conf
afalse
:[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
El servicio DNS está instalado en el servidor IdM. Para obtener más información sobre cómo instalar un servidor IdM con DNS integrado, consulte uno de los siguientes enlaces:
Este capítulo incluye las siguientes secciones:
- Cómo garantiza IdM que los reenviadores globales de /etc/resolv.conf no sean eliminados por NetworkManager
- Garantizar la presencia de un reenviador global de DNS en IdM mediante Ansible
- Garantizar la ausencia de un reenviador global de DNS en IdM utilizando Ansible
- Introducción a las políticas de reenvío de DNS en IdM
- 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
- Uso de un libro de jugadas de Ansible para garantizar que los reenviadores globales estén desactivados en el DNS de IdM
- 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
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:
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
-
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 archivozzz-ipa.conf
.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
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
-
Abra el archivo
ensure-presence-of-a-global-forwarder.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to ensure the presence of a global forwarder in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porEnsure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
. En la sección
forwarders
de la parteipadnsconfig
:-
Cambie el primer valor de
ip_address
por la dirección IPv4 del reenviador global:7.7.9.9
. -
Cambie el segundo valor de
ip_address
por la dirección IPv6 del reenviador global:2001:db8::1:0
. -
Compruebe que el valor de
port
está ajustado a53
.
-
Cambie el primer valor de
Cambie el
state
apresent
.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
-
Cambie la variable
- Guarda el archivo.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
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
-
Abra el archivo
ensure-absence-of-a-global-forwarder.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to ensure the absence of a global forwarder in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porEnsure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
. En la sección
forwarders
de la parteipadnsconfig
:-
Cambie el primer valor de
ip_address
por la dirección IPv4 del reenviador global:8.8.6.6
. -
Cambie el segundo valor de
ip_address
por la dirección IPv6 del reenviador global:2001:4860:4860::8800
. -
Compruebe que el valor de
port
está ajustado a53
.
-
Cambie el primer valor de
Compruebe que la dirección
state
está ajustada aabsent
.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
-
Cambie la variable
- Guarda el archivo.
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.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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
Haga una copia del archivo de playbook de Ansible set-configuration.yml. Por ejemplo:
$ cp set-configuration.yml set-forward-policy-to-first.yml
- Abra el archivo set-forward-policy-to-first.yml para editarlo.
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
-
Establece la variable
- Guarda el archivo.
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 MarkdownREADME-dnsconfig.md
disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsconfig
. -
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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
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
- Abra el archivo disable-global-forwarders-copy.yml para editarlo.
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
-
Establece la variable
- Guarda el archivo.
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 MarkdownREADME-dnsconfig.md
disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsconfig
. -
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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
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
- Abra el archivo disallow-reverse-sync-copy.yml para editarlo.
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
-
Establece la variable
- Guarda el archivo.
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 MarkdownREADME-dnsconfig.md
disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsconfig
. -
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
El servicio DNS está instalado en el servidor IdM. Para obtener más información sobre cómo instalar un servidor IdM con DNS integrado, consulte uno de los siguientes enlaces:
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.
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 comandosipa dnszone-*
.De acuerdo con las reglas estándar del DNS, toda zona primaria debe contener los registros
start of authority
(SOA) ynameserver
(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 nombresub.test.example.
. Además, la zonatest.example.
está configurada con la dirección IP del reenviador192.0.2.254
para la subzonasub.text.example
.Un cliente que consulta el nombre
nonexistent.test.example.
recibe la respuestaNXDomain
, 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 configurado192.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
En la interfaz web de IdM, haga clic en
Network Services
→DNS
→DNS Zones
.Figura 62.1. Gestión de las zonas primarias del DNS de IdM
- Haga clic en Añadir en la parte superior de la lista de todas las zonas.
Indique el nombre de la zona.
Figura 62.2. Introducir una nueva zona primaria de IdM
- 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 comandoipa 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
-
En la interfaz web de IdM, haga clic en
Network Services
→DNS
→DNS Zones
. Seleccione la casilla junto al nombre de la zona y haga clic en Eliminar.
Figura 62.3. Eliminación de una zona DNS maestra
- 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-*
yipa 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:
-
El comando
dnszone-mod
en la interfaz de línea de comandos (CLI). Para obtener más información, consulte Edición de la configuración de una zona DNS primaria en la CLI de IdM. - La interfaz web de IdM. Para más información, consulte Editar la configuración de una zona DNS primaria en la interfaz web de IdM.
-
Un libro de jugadas de Ansible que utiliza el módulo
ipadnszone
. Para obtener más información, consulte Uso de los libros de juego de Ansible para gestionar las zonas DNS de IdM.
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
Atributo | Opción de línea de comandos | Descripción |
---|---|---|
Servidor de nombres autorizado |
| 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 |
Dirección de correo electrónico del administrador |
| 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 |
| 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 |
| Establece el intervalo, en segundos, que debe esperar un servidor DNS secundario antes de solicitar actualizaciones al servidor DNS primario. |
Reintento de SOA |
| Establece el tiempo, en segundos, que se debe esperar antes de reintentar una operación de actualización fallida. |
La SOA caduca |
| 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 |
| 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 |
|
Establece el TTL en segundos para los registros en el vértice de la zona. En la zona |
Tiempo de vida por defecto |
|
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 |
Política de actualización de BIND |
| Establece los permisos permitidos a los clientes en la zona DNS. |
Actualización dinámica |
| 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 |
| 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 |
Permitir consulta |
| 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 |
| 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 |
| 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 |
| 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
En la interfaz web de IdM, haga clic en
Network Services
→DNS
→DNS Zones
.Figura 62.4. Gestión de las zonas primarias del DNS
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
Haga clic en
Settings
.Figura 62.6. La pestaña de configuración en la página de edición de la zona primaria
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.
Haga clic en Guardar para confirmar la nueva configuración.
NotaSi 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.NotaSi 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 comandoipa 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.
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
- Para obtener más información sobre cómo proceder para habilitar las transferencias de zonas en la interfaz web de IdM, consulte Activación de las transferencias de zonas en la interfaz web de IdM.
- Para obtener más información sobre cómo proceder para activar las transferencias de zona en la CLI de IdM, consulte Activación de las transferencias de zona en la CLI de IdM.
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
-
En la interfaz web de IdM, haga clic en
Network Services
→DNS
→DNS Zones
. -
Haga clic en
Settings
. 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
- 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 comandoipa 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
SSH a uno de los servidores DNS a los que se ha habilitado la transferencia de zonas:
$ ssh 192.0.2.1
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
- Para más información sobre cómo utilizar Red Hat Ansible Engine para gestionar las zonas DNS de IdM, consulte Uso de los libros de juego de Ansible para gestionar las zonas DNS de IdM.
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:
- ¿Qué tipos de zonas DNS son compatibles con IdM?
- Qué atributos DNS se pueden configurar en IdM
- Cómo utilizar un playbook de Ansible para crear una zona primaria en IdM DNS
- Cómo utilizar un playbook de Ansible para asegurar la presencia de una zona DNS primaria de IdM con múltiples variables
- Cómo utilizar 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
Requisitos previos
- El servicio DNS está instalado en el servidor IdM. Para más información sobre cómo utilizar Red Hat Ansible Engine para instalar un servidor IdM con DNS integrado, consulte Instalación de un servidor de gestión de identidades mediante un libro de jugadas de Ansible.
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.
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 comandosipa dnszone-*
.De acuerdo con las reglas estándar del DNS, toda zona primaria debe contener los registros
start of authority
(SOA) ynameserver
(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 nombresub.test.example.
. Además, la zonatest.example.
está configurada con la dirección IP del reenviador192.0.2.254
para la subzonasub.text.example
.Un cliente que consulta el nombre
nonexistent.test.example.
recibe la respuestaNXDomain
, 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 configurado192.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:
-
El comando
dnszone-mod
en la interfaz de línea de comandos (CLI). Para obtener más información, consulte Edición de la configuración de una zona DNS primaria en la CLI de IdM. - La interfaz web de IdM. Para más información, consulte Editar la configuración de una zona DNS primaria en la interfaz web de IdM.
-
Un libro de jugadas de Ansible que utiliza el módulo
ipadnszone
. Para obtener más información, consulte Uso de los libros de juego de Ansible para gestionar las zonas DNS de IdM.
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
Atributo | ansible-freeipa variable | Descripción |
---|---|---|
Servidor de nombres autorizado |
| 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 |
Dirección de correo electrónico del administrador |
| 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 |
| 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 |
| Establece el intervalo, en segundos, que debe esperar un servidor DNS secundario antes de solicitar actualizaciones al servidor DNS primario. |
Reintento de SOA |
| Establece el tiempo, en segundos, que se debe esperar antes de reintentar una operación de actualización fallida. |
La SOA caduca |
| 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 |
| 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 |
|
Establece el TTL en segundos para los registros en el vértice de la zona. En la zona |
Tiempo de vida por defecto |
|
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 |
Política de actualización de BIND |
| Establece los permisos permitidos a los clientes en la zona DNS. |
Actualización dinámica |
| 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 |
| 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 |
Permitir consulta |
| 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 |
| 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 |
| 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 |
| 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 MarkdownREADME-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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnszone
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
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
Haga una copia del archivo de playbook de Ansible dnszone-present.yml. Por ejemplo:
$ cp dnszone-present.yml dnszone-present-copy.yml
- Abra el archivo dnszone-present-copy.yml para editarlo.
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
-
Establece la variable
- Guarda el archivo.
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 archivoREADME-dnszone.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnszone
. -
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnszone
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
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
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
- Abra el archivo dnszone-all-params-copy.yml para editarlo.
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
, ydefault_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
-
Establece la variable
- Guarda el archivo.
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 archivoREADME-dnszone.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnszone
. -
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnszone
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
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
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
- Abra el archivo dnszone-reverse-from-ip-copy.yml para editarlo.
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.
-
Establece la variable
- Guarda el archivo.
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 archivoREADME-dnszone.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnszone
. -
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:
- Sección 64.1, “Las dos funciones de un servidor DNS IdM”
- Sección 64.2, “Políticas de reenvío de DNS en IdM”
- Sección 64.3, “Añadir un reenvío global en la interfaz web de IdM”
- Sección 64.4, “Añadir un forwarder global en la CLI”
- Sección 64.5, “Añadir una zona de reenvío de DNS en la interfaz web de IdM”
- Sección 64.6, “Añadir una zona de reenvío de DNS en la CLI”
- Sección 64.7, “Establecimiento de un reenvío global de DNS en IdM mediante Ansible”
- Sección 64.8, “Garantizar la presencia de un reenviador global de DNS en IdM mediante Ansible”
- Sección 64.9, “Garantizar la ausencia de un reenviador global de DNS en IdM utilizando Ansible”
- Sección 64.10, “Garantizar que los reenviadores globales de DNS estén desactivados en IdM mediante Ansible”
- Sección 64.11, “Garantizar la presencia de una zona de reenvío de DNS en IdM mediante Ansible”
- Sección 64.12, “Garantizar que una zona de reenvío de DNS tenga varios reenviadores en IdM mediante Ansible”
- Sección 64.13, “Garantizar que una zona de reenvío de DNS esté desactivada en IdM mediante Ansible”
- Sección 64.14, “Garantizar la ausencia de una zona de reenvío de DNS en IdM utilizando 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.
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
En la interfaz web de IdM, seleccione
Network Services
→DNS Global Configuration
→DNS
.En la sección
DNS Global Configuration
, haga clic enAdd
.Especifique la dirección IP del servidor DNS que recibirá las consultas DNS reenviadas.
Seleccione la dirección
Forward policy
.-
Haga clic en
Save
en la parte superior de la ventana.
Pasos de verificación
Seleccione
Network Services
→DNS Global Configuration
→DNS
.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.
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).
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
En la interfaz web de IdM, seleccione
Network Services
→DNS Forward Zones
→DNS
.En la sección
DNS Forward Zones
, haga clic enAdd
.En la ventana
Add DNS forward zone
, especifique el nombre de la zona de reenvío.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.Seleccione la dirección
Forward policy
.-
Haga clic en
Add
en la parte inferior de la ventana para añadir la nueva zona de reenvío.
Pasos de verificación
En la interfaz web de IdM, seleccione
Network Services
→DNS Forward Zones
→DNS
.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.
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).
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 esnone
, 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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
Haga una copia del archivo de playbook de Ansible
set-configuration.yml
. Por ejemplo:$ cp set-configuration.yml establish-global-forwarder.yml
-
Abra el archivo
establish-global-forwarder.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to establish a global forwarder in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porCreate a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800
. En la sección
forwarders
de la parteipadnsconfig
:-
Cambie el primer valor de
ip_address
por la dirección IPv4 del reenviador global:8.8.6.6
. -
Cambie el segundo valor de
ip_address
por la dirección IPv6 del reenviador global:2001:4860:4860::8800
. -
Compruebe que el valor de
port
está ajustado a53
.
-
Cambie el primer valor de
Cambie el
forward_policy
afirst
.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
-
Cambie la variable
- Guarda el archivo.
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 archivoREADME-dnsconfig.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsconfig
.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
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
-
Abra el archivo
ensure-presence-of-a-global-forwarder.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to ensure the presence of a global forwarder in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porEnsure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
. En la sección
forwarders
de la parteipadnsconfig
:-
Cambie el primer valor de
ip_address
por la dirección IPv4 del reenviador global:7.7.9.9
. -
Cambie el segundo valor de
ip_address
por la dirección IPv6 del reenviador global:2001:db8::1:0
. -
Compruebe que el valor de
port
está ajustado a53
.
-
Cambie el primer valor de
Cambie el
state
apresent
.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
-
Cambie la variable
- Guarda el archivo.
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 archivoREADME-dnsconfig.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsconfig
.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
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
-
Abra el archivo
ensure-absence-of-a-global-forwarder.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to ensure the absence of a global forwarder in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porEnsure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
. En la sección
forwarders
de la parteipadnsconfig
:-
Cambie el primer valor de
ip_address
por la dirección IPv4 del reenviador global:8.8.6.6
. -
Cambie el segundo valor de
ip_address
por la dirección IPv6 del reenviador global:2001:4860:4860::8800
. -
Compruebe que el valor de
port
está ajustado a53
.
-
Cambie el primer valor de
Compruebe que la dirección
state
está ajustada aabsent
.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
-
Cambie la variable
- Guarda el archivo.
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 archivoREADME-dnsconfig.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsconfig
.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
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
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 archivoREADME-dnsconfig.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsconfig
.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
Haga una copia del archivo de playbook de Ansible
forwarders-absent.yml
. Por ejemplo:$ cp forwarders-absent.yml ensure-presence-forwardzone.yml
-
Abra el archivo
ensure-presence-forwardzone.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to ensure the presence of a dnsforwardzone in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porEnsure presence of a dnsforwardzone for example.com to 8.8.8.8
. -
En la sección
tasks
, cambie el títuloipadnsconfig
poripadnsforwardzone
. En la sección
ipadnsforwardzone
:-
Añade la variable
ipaadmin_password
y establécela con tu contraseña de administrador de IdM. -
Añade la variable
name
y ponla enexample.com
. En la sección
forwarders
:-
Retire las líneas
ip_address
yport
. 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
-
Retire las líneas
-
Añade la variable
forwardpolicy
y ponla enfirst
. -
Añade la variable
skip_overlap_check
y ponla entrue
. -
Cambie la variable
state
porpresent
.
Este es el archivo de Ansible playbook modificado para el ejemplo actual:
-
Añade la variable
--- - 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
-
Cambie la variable
- Guarda el archivo.
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 archivoREADME-dnsforwardzone.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsforwardzone
.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
Haga una copia del archivo de playbook de Ansible
forwarders-absent.yml
. Por ejemplo:$ cp forwarders-absent.yml ensure-presence-multiple-forwarders.yml
-
Abra el archivo
ensure-presence-multiple-forwarders.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to ensure the presence of multiple forwarders in a dnsforwardzone in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porEnsure presence of 8.8.8.8 and 4.4.4.4 forwarders in dnsforwardzone for example.com
. -
En la sección
tasks
, cambie el títuloipadnsconfig
poripadnsforwardzone
. En la sección
ipadnsforwardzone
:-
Añade la variable
ipaadmin_password
y establécela con tu contraseña de administrador de IdM. -
Añade la variable
name
y ponla enexample.com
. En la sección
forwarders
:-
Retire las líneas
ip_address
yport
. 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
-
Retire las líneas
- Cambia la variable de estado a presente.
Este es el archivo de Ansible playbook modificado para el ejemplo actual:
-
Añade la variable
--- - 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
-
Cambie la variable
- Guarda el archivo.
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 archivoREADME-dnsforwardzone.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsforwardzone
.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
Haga una copia del archivo de playbook de Ansible
forwarders-absent.yml
. Por ejemplo:$ cp forwarders-absent.yml ensure-disabled-forwardzone.yml
-
Abra el archivo
ensure-disabled-forwardzone.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to ensure a dnsforwardzone is disabled in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porEnsure a dnsforwardzone for example.com is disabled
. -
En la sección
tasks
, cambie el títuloipadnsconfig
poripadnsforwardzone
. En la sección
ipadnsforwardzone
:-
Añade la variable
ipaadmin_password
y establécela con tu contraseña de administrador de IdM. -
Añade la variable
name
y ponla enexample.com
. -
Retire toda la sección
forwarders
. -
Cambie la variable
state
pordisabled
.
Este es el archivo de Ansible playbook modificado para el ejemplo actual:
-
Añade la variable
--- - 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
-
Cambie la variable
- Guarda el archivo.
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 archivoREADME-dnsforwardzone.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsforwardzone
.
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsconfig
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
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 configureserver.idm.example.com
, introduzca:[ipaserver] server.idm.example.com
Haga una copia del archivo de playbook de Ansible
forwarders-absent.yml
. Por ejemplo:$ cp forwarders-absent.yml ensure-absence-forwardzone.yml
-
Abra el archivo
ensure-absence-forwardzone.yml
para editarlo. Adapte el archivo estableciendo las siguientes variables:
-
Cambie la variable
name
para el libro de jugadas aPlaybook to ensure the absence of a dnsforwardzone in IdM DNS
. -
En la sección
tasks
, cambie elname
de la tarea porEnsure the absence of a dnsforwardzone for example.com
. -
En la sección
tasks
, cambie el títuloipadnsconfig
poripadnsforwardzone
. En la sección
ipadnsforwardzone
:-
Añade la variable
ipaadmin_password
y establécela con tu contraseña de administrador de IdM. -
Añade la variable
name
y ponla enexample.com
. -
Retire toda la sección
forwarders
. -
Deje la variable
state
comoabsent
.
Este es el archivo de Ansible playbook modificado para el ejemplo actual:
-
Añade la variable
--- - 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
-
Cambie la variable
- Guarda el archivo.
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 archivoREADME-dnsforwardzone.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsforwardzone
.
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:
- Registros DNS en IdM
- Añadir registros de recursos DNS desde la interfaz web de IdM
- Añadir registros de recursos DNS desde la CLI de IdM
- Opciones comunes de ipa dnsrecord-add
- Eliminación de registros DNS en la interfaz web de IdM
- Eliminación de un registro DNS completo en la interfaz web de IdM
- Eliminación de registros DNS en la CLI de IdM
Requisitos previos
Tu implementación de IdM contiene un servidor DNS integrado. Para obtener información sobre cómo instalar IdM con DNS integrado, consulte uno de los siguientes enlaces:
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 valorIP Address
de un registro A es una dirección IPv4, como192.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 deIP Address
es una dirección IPv6, como2001: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.
NotaTodas 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 dominioin-addr.arpa.
añadido. Por ejemplo, para la dirección de red192.0.2.0/24
, la zona inversa es2.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.
NotaTambié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
-
En la interfaz web de IdM, haga clic en
Network Services
→DNS
→DNS Zones
. - Haga clic en la zona DNS a la que desea añadir un registro DNS.
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
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
- 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
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
Option | Description |
---|---|
| Establece el tiempo de vida del disco. |
| Analiza los registros DNS en bruto y los devuelve en un formato estructurado. |
Tabla 65.2. Opciones de registro "A"
Option | Description | Examples |
---|---|---|
| Pasa un único registro A o una lista de registros A. |
|
Puede crear un registro A comodín con una dirección IP determinada. |
| |
|
Indica la dirección IP del registro. Al crear un registro, la opción para especificar el valor del registro |
|
[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"
Option | Description | Example |
---|---|---|
| Pasa un único registro AAAA (IPv6) o una lista de registros AAAA. |
|
|
Proporciona la dirección IPv6 del registro. Al crear un registro, la opción para especificar el valor del registro |
|
Tabla 65.4. Opciones de registro "PTR"
Option | Description | Example |
---|---|---|
|
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 |
|
| ||
| Proporciona el nombre del host para el registro. |
Tabla 65.5. "SRV Opciones de registro
Option | Description | Example |
---|---|---|
|
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 |
|
| ||
| 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. |
|
| 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. |
|
| Da el puerto para el servicio en el host de destino. |
|
| 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 comandoipa 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
-
En la interfaz web de IdM, haga clic en
Network Services
→DNS
→DNS Zones
. - Haga clic en la zona de la que desea eliminar un registro DNS, por ejemplo example.com..
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
- Seleccione la casilla junto al nombre del tipo de registro que desea eliminar.
Haga clic en
Delete
.Figura 65.4. Eliminación de un registro de recursos DNS
El tipo de registro seleccionado se elimina. El resto de la configuración del registro de recursos queda intacta.
Recursos adicionales
- Para obtener más información sobre la eliminación de un registro DNS completo, consulte Eliminación de un registro DNS completo en la interfaz web de IdM.
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
-
En la interfaz web de IdM, haga clic en
Network Services
→DNS
→DNS Zones
. - Haga clic en la zona de la que desea eliminar un registro DNS, por ejemplo zone.example.com..
-
En la sección
DNS Resource Records
, seleccione la casilla del registro de recursos que desea eliminar. Haga clic en Eliminar.
Figura 65.5. Borrar un registro de recursos completo
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 comandoipa dnsrecord-del --help
.
65.8. Recursos adicionales
-
Puedes utilizar el módulo
ansible-freeipa
ipadnsrecord
para añadir, modificar y eliminar registros en IdM DNS. Para obtener más información, consulte Uso de Ansible para gestionar los registros DNS en IdM.
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:
- Garantizar la presencia de registros DNS A y AAAA en IdM mediante Ansible
- Garantizar la presencia de registros DNS A y PTR en IdM mediante Ansible
- Garantizar la presencia de varios registros DNS en IdM mediante Ansible
- Garantizar la presencia de varios registros CNAME en IdM mediante Ansible
- Garantizar la presencia de un registro SRV en IdM mediante Ansible
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra el archivo ensure-A-and-AAAA-records-are-present-copy.yml para editarlo.
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 variablename
como host1, y la variablea_ip_address
como 192.168.122.123. En la variable
records
, establezca la variablename
como host1, y la variableaaaa_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
-
Establece la variable
- Guarda el archivo.
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 archivoREADME-dnsrecord.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsrecord
. -
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra el archivo ensure-dnsrecord-with-reverse-is-present-copy.yml para editarlo.
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
-
Establece la variable
- Guarda el archivo.
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 archivoREADME-dnsrecord.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsrecord
. -
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra el archivo ensure-presence-multiple-records-copy.yml para editarlo.
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 variablename
como host1. -
En la sección
records
, establezca la variablezone_name
como idm.example.com. -
En la sección
records
, ajuste la variablea_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:
-
Establezca la variable
--- - 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
-
Establece la variable
- Guarda el archivo.
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 archivoREADME-dnsrecord.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsrecord
. -
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra el archivo ensure-CNAME-record-is-present-copy.yml para editarlo.
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:
-
Establezca la variable
--- - 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
-
(Opcional) Adaptar la descripción que ofrece el
- Guarda el archivo.
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 archivoREADME-dnsrecord.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsrecord
. -
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
Navegue hasta el directorio
/usr/share/doc/ansible-freeipa/playbooks/dnsrecord
:$ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
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
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
- Abra el archivo ensure-SRV-record-is-present-copy.yml para editarlo.
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
-
Establece la variable
- Guarda el archivo.
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 archivoREADME-dnsrecord.md
Markdown disponible en el directorio/usr/share/doc/ansible-freeipa/
. El archivo también contiene las definiciones de las variables deipadnsrecord
. -
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.
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
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.
Inicie el temporizador
systemd
:# systemctl start ipa-healthcheck.timer
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.
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/
.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.
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
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
dondeid_provider=ipa
asegurar queipa_server_mode
esTrue
. - 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 deipa 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 desssctl 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 pluginsIPA SIDGEN
yipa-sidgen-task
encn=plugins,cn=config
incluyen la opciónnsslapd-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 denet 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.
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óncert_expiration_days
situada en la sección por defecto.NotaCertmonger 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.NotaEsta 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
ydogtag-ipa-ca-renew-agent-reuse
que renuevan los certificados del subsistema CA.
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
contraca.audit_signing.cert
-
ocspSigningCert cert-pki-ca
contraca.ocsp_signing.cert
-
caSigningCert cert-pki-ca
contraca.signing.cert
-
subsystemCert cert-pki-ca
contraca.subsystem.cert
-
Server-Cert cert-pki-ca
contraca.sslserver.cert
Si la Autoridad de Recuperación de Claves (KRA) está instalada:
-
transportCert cert-pki-kra
contraca.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).
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 prueba | Espacio mínimo en disco en MB |
---|---|
| 1024 |
| 512 |
| 1024 |
| 512 |
| 512 |
| 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
-
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
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.
NotaLa 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=*))
.
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.
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.
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 webRed 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.
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
Instale los paquetes necesarios:
[root@ipaserver ~]#
yum install ipa-server ipa-server-trust-ad samba-client
Autenticarse como usuario administrativo de IdM:
[root@ipaserver ~]#
kinit admin
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.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
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
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]:
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.
(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 en55000-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
Reinicie el servicio
ipa
:[root@ipaserver ~]#
ipactl restart
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
-
Abra la página web
Group Policy Management Console
. -
Haga clic con el botón derecho del ratón en
Default Domain Policy
, y seleccioneEdit
. Se abre la páginaGroup Policy Management Editor
. -
Navegue hasta
Computer Configuration
→Policies
→Windows Settings
→Security Settings
→Local Policies
→Security Options
. -
Haga doble clic en la política
Network security: Configure encryption types allowed for Kerberos
. -
Seleccione
AES256_HMAC_SHA1
y, opcionalmente,Future encryption types
. - Haga clic en Aceptar.
-
Cierre la página
Group Policy Management Editor
. -
Repita los pasos para el
Default Domain Controller Policy
. 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
- Tanto los servidores de IdM como el cliente deben ejecutarse en RHEL 8.1 o posterior.
-
El dominio IdM se prepara como se describe en Preparación del dominio IdM para instalar Samba en los miembros del dominio en la documentación de
Deploying different types of servers
.. -
Si IdM tiene una confianza configurada con AD, habilite el tipo de cifrado AES para Kerberos. Por ejemplo, utilice un objeto de política de grupo (GPO) para habilitar el tipo de cifrado AES. Para obtener más detalles, consulte Activación del cifrado AES en Active Directory mediante un G PO en la documentación de
Deploying different types of servers
.
Procedimiento
Instale el paquete
ipa-client-samba
:[root@idm_client]#
yum install ipa-client-samba
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 servicesPor 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
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: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
Habilite e inicie los servicios
smb
ywinbind
:[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
:
Autenticar y obtener un ticket de Kerberos:
$
kinit example_user
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 manualipa-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
Autenticar usando el keytab del host:
[root@idm_client]#
kinit -k
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 dominioad.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
yipaidrangesize
son necesarios en los siguientes pasos.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
es1918599999
(1918400000 200000 - 1).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.Reinicie los servicios
smb
ywinbind
:[root@idm_client]#
systemctl restart smb winbind
Pasos de verificación
Autentifíquese como usuario del nuevo dominio y obtenga un ticket Kerberos:
$
kinit example_user
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
-
Para obtener más detalles sobre cómo unir RHEL 8 a un dominio IdM, consulte la sección
Installing an Identity Management client
sección de la guíaInstalling Identity Management
.
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
- Configuración del dominio IdM. Para obtener más información, consulte Instalación de la gestión de identidades.
- Cliente IPA instalado. Para más información, consulte Instalación de paquetes ipa-client.
Procedimiento
Si alguno de sus clientes NFS sólo soporta criptografía débil, como los clientes de Red Hat Enterprise Linux 5:
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
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
Obtener un ticket Kerberos:
[root@nfs-server ~]# kinit admin
- 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.
Cree la entrada del servicio NFS:
[root@nfs-server ~]# ipa service-add nfs/nfs-server.example.com
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.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
Instale el nfs-utils paquete:
root@nfs-server ~]# yum install nfs-utils
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.Edite el archivo
/etc/exports
y añada recursos compartidos con la configuración de seguridad Kerberoskrb5p
:/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.Reinicie y habilite el servidor nfs:
[root@nfs-server ~]# systemctl restart nfs-server [root@nfs-server ~]# systemctl enable nfs-server
Vuelve a exportar los directorios compartidos:
[root@nfs-server ~]# exportfs -rav
- 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
- Configuración del dominio IdM. Para obtener más información, consulte Instalación de la gestión de identidades.
- Cliente IPA instalado. Para más información, consulte Instalación de paquetes ipa-client.
Procedimiento
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
- 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.
Instale el nfs-utils paquete:
root@nfs-client ~]# yum install nfs-utils
Obtenga un ticket Kerberos antes de ejecutar las herramientas IdM.
[root@nfs-client ~]# kinit admin
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ámetroDomain
en el archivo/etc/idmapd.conf
.Añada las siguientes entradas al archivo
/etc/fstab
para montar los recursos compartidos NFS desde el hostnfs-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
.- Cree los puntos de montaje si no existen. En nuestro caso, ambos deberían existir.
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
.Configurar SSSD para renovar los tickets de Kerberos:
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
Reinicie el SSSD:
[root@nfs-client ~]# systemctl restart sssd
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.