Dominando Red Hat Identity Manager (IDM): Una Guía Completa para Administradores y Profesionales de TI

¿Qué es RedHat Identity Manager?

Red Hat Identity Manager o RH IDM es una solución empresarial de gestión de identidades y acceso, diseñada para ayudar a las organizaciones a controlar quién tiene acceso a los recursos de la red y a qué pueden acceder. Ofrece funciones para la gestión centralizada de usuarios, autenticación, autorización y se integra bien con sistemas existentes como LDAP y Microsoft Active Directory. Es útil para mejorar la seguridad, simplificar el cumplimiento de normativas y optimizar la administración de usuarios en entornos empresariales.

Características clave de RedHat Identity Manager

Las características clave de Red Hat Identity Manager son:

1. Gestión Centralizada de Identidades: Permite la administración centralizada de usuarios, grupos y roles, facilitando la gestión de acceso y políticas en una organización.
2. Integración con LDAP y Active Directory: Ofrece compatibilidad y sincronización con servicios de directorio estándar como LDAP y Microsoft Active Directory, lo que permite una gestión de identidades unificada en entornos híbridos.
3. Autenticación y Autorización: Soporta métodos de autenticación robustos, incluyendo la autenticación de múltiples factores (MFA) y Single Sign-On (SSO), aumentando la seguridad y la eficiencia del acceso a los sistemas.
4. Control de Acceso Basado en Roles (RBAC): Proporciona un marco flexible para definir políticas de acceso basadas en roles, lo que facilita la asignación de permisos según las responsabilidades del usuario.
5. Seguridad y Cumplimiento: Implementa características avanzadas de seguridad, como el cifrado de datos y la auditoría, para proteger la información sensible y cumplir con los estándares de cumplimiento.
6. Interfaz de Usuario Amigable: Incluye una interfaz gráfica de usuario (GUI) intuitiva para la administración, así como herramientas de línea de comandos para operaciones más técnicas.
7. Automatización y Scripts: Permite la automatización de tareas repetitivas y la personalización de procesos a través de scripts y APIs, mejorando la eficiencia operativa.
8. Escalabilidad y Rendimiento: Diseñado para escalar y manejar eficientemente un gran número de usuarios y transacciones, lo que lo hace adecuado para organizaciones de todos los tamaños.
9. Soporte y Comunidad: Como parte del ecosistema de Red Hat, cuenta con un fuerte soporte empresarial y una comunidad activa que contribuye a su desarrollo y mejora continua.

Estas características hacen del Red Hat Identity Manager una solución robusta y flexible para la gestión de identidades y accesos en entornos empresariales, ayudando a las organizaciones a mejorar la seguridad, el cumplimiento y la eficiencia operativa.

¿Qué diferencias hay entre RedHat Identity Manager y RedHat Directory Server?

IDM (Identity Management) y Red Hat Directory Server son soluciones de gestión de identidades y directorios, pero tienen diferencias clave en cuanto a funcionalidades, uso y arquitectura.

IDM (Identity Management)

1. Generalmente se refiere a FreeIPA: IDM a menudo se refiere a FreeIPA, una solución de gestión de identidades de código abierto. FreeIPA se centra en la gestión de políticas de seguridad centralizadas para usuarios y grupos, sistemas y servicios.
2. Integración con Linux: FreeIPA está diseñado principalmente para entornos Linux y se integra bien con sistemas basados en Linux.
3. Funcionalidades: Proporciona autenticación centralizada, gestión de políticas de acceso, gestión de identidades de usuarios y hosts, y también puede manejar DNS y certificados SSL/TLS.
4. Interoperabilidad con Active Directory: FreeIPA puede integrarse con Microsoft Active Directory, permitiendo cierta interoperabilidad en entornos mixtos.

Red Hat Directory Server

1. Enfocado en LDAP (Lightweight Directory Access Protocol): Red Hat Directory Server es un servidor de directorio empresarial que utiliza LDAP. Está diseñado para manejar grandes volúmenes de datos de directorio y numerosas operaciones de directorio.
2. Gestión de Datos de Directorio: Ideal para almacenar y organizar información de usuario, como credenciales, información de contacto, y relaciones de grupo.
3. Compatibilidad Multiplataforma: Aunque es un producto de Red Hat, puede ser utilizado en una variedad de entornos de sistema operativo.
4. Escalabilidad y Rendimiento: Está optimizado para un alto rendimiento y escalabilidad, maneja grandes volúmenes de entradas y transacciones de directorio.

Diferencias Clave

• Uso: IDM/FreeIPA es más adecuado para la gestión integral de identidades y políticas de seguridad en entornos Linux, mientras que Red Hat Directory Server es más un repositorio especializado para datos de directorio en un formato altamente escalable y eficiente.
• Integración y Funcionalidades: IDM ofrece una gama más amplia de funcionalidades de gestión de identidades y se integra bien con otros sistemas como Active Directory, mientras que Red Hat Directory Server se centra más en el rendimiento y la escalabilidad como un servidor LDAP.

RedHat recomienda un producto u otro en función del caso de uso.

Instalación y Configuración Inicial

Requisitos del Sistema

Antes de proceder a la instalación de RedHat Identity Manager conviene conocer los requisitos del sistema:

Para instalar Red Hat Identity Manager, es importante considerar varios requisitos del sistema:

• RAM y Espacio de Swap:
  • Para 10,000 usuarios y 100 grupos: al menos 4 GB de RAM y 4 GB de espacio de swap.
  • Para 100,000 usuarios y 50,000 grupos: al menos 16 GB de RAM y 4 GB de espacio de swap.

• Configuración del Sistema: Se debe instalar en un sistema limpio, sin configuraciones personalizadas para servicios como DNS, Kerberos, Apache o Directory Server.
• Requisitos de IPv6: El protocolo IPv6 debe estar habilitado en el kernel y localhost (::1) debe poder utilizarlo.
• Tipos de Cifrado Soportados: Incluye varios tipos de cifrado AES y Camellia. Los tipos de cifrado RC4 están deshabilitados por defecto. Además, la encriptación DES y 3DES ha sido eliminada por razones de seguridad.
• Políticas Criptográficas: Utiliza la política criptográfica DEFAULT del sistema, que soporta protocolos seguros y parámetros de encriptación específicos.
• Cumplimiento de FIPS: Es posible instalar un servidor IdM en modo FIPS (Federal Information Processing Standard) con RHEL 8.3.0 o posterior.
• Soporte para Confianza Cruzada con FIPS: Se requiere RHEL 8.4.0 o posterior para establecer confianza cruzada con un dominio de Active Directory mientras el modo FIPS está habilitado.
• Servicio de hora: Usa chronyd para mantener sincronizados los hosts de IdM con una fuente de tiempo central.
• Nombre de Host y Requisitos DNS: El nombre del host debe ser un nombre de dominio completamente calificado y debe cumplir con ciertos estándares para garantizar la funcionalidad del sistema.

Suscripción necesaria de RedHat

Para instalar Red Hat Identity Manager, es probable que necesites configurar los repositorios de yum o dnf apropiados. Red Hat Identity Manager generalmente se instala en sistemas que ejecutan Red Hat Enterprise Linux (RHEL), y para acceder a los paquetes necesarios, debes tener acceso a los repositorios de Red Hat.

Los pasos generales son:

1. Suscripción a Red Hat: Asegúrate de que tu sistema esté suscrito a Red Hat Subscription Management. Esto es necesario para acceder a los repositorios de Red Hat.
2. Habilitar Repositorios: Usa los comandos yum o dnf para habilitar los repositorios requeridos. Los repositorios específicos pueden variar según la versión de RHEL que estés utilizando, pero generalmente incluirán repositorios como rhel-8-server-rpms, rhel-8-server-extras-rpms, y otros relevantes para Identity Management. Por ejemplo, podrías usar un comando como:

   sudo subscription-manager repos --enable=<nombre_del_repositorio>

3. Actualizar el Sistema: Antes de la instalación, es buena práctica actualizar tu sistema para asegurarte de que todas las dependencias estén actualizadas:

   sudo dnf update

4. Instalar el Paquete: Una vez que los repositorios están habilitados y tu sistema está actualizado, puedes instalar Red Hat Identity Manager utilizando yum o dnf. Por ejemplo:

   sudo dnf install ipa-server

Reglas de firewall

Configurar correctamente las reglas de firewall es esencial para garantizar tanto la funcionalidad como la seguridad de Red Hat Identity Manager (RH IDM). Las reglas exactas pueden variar según tu configuración específica y los servicios que estés utilizando, pero aquí te proporciono una guía general de los puertos que generalmente necesitan estar abiertos en un servidor RH IDM.

IdM Clients -> IdM Server

IdM Server IdM Server (i.e. Replica)

Instalación de RedHat Identity Manager

El proceso de instalación de Red Hat Identity Manager implica varios pasos, que se pueden realizar de manera interactiva o no interactiva:

Instalación Interactiva

1. Ejecutar la utilidad ipa-server-install.
2. Configurar el servicio DNS integrado respondiendo yes.
3. Proporcionar configuraciones requeridas (nombre de host del servidor, nombre de dominio, nombre del reino) y establecer contraseñas para el superusuario del Directory Server y el administrador de IdM.
4. Configurar los forwardrs DNS del servidor, si se desea.
5. Determinar si se necesitan zonas de reversa DNS y crearlas si es necesario.
6. Confirmar y finalizar la configuración del servidor.

Instalación No Interactiva

Para una instalación no interactiva, se utilizan opciones de línea de comandos para proporcionar la información requerida, como el nombre del reino (realm name), las contraseñas y la configuración del DNS. Ejemplo de comando:

# ipa-server-install --realm IDM.EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended --setup-dns --forwarder 192.0.2.1 --no-reverse

Si ya tenemos un servidor de DNS configurado, no tendremos que especificar los parámetros de DNS:

 ipa-server-install --realm IDM.EXAMPLE.COM --ds-password admin-password --admin-password admin_password --unattended 

Esta modalidad permite que el proceso de instalación seleccione opciones predeterminadas para el nombre de host y el nombre de dominio, y también se pueden configurar opciones adicionales para DNS y zonas de reversa.

Aclarando el significado de «nombre del reino»:

El «nombre del reino» (realm name) en el contexto de Red Hat Identity Manager y otros sistemas que utilizan Kerberos (un protocolo de autenticación de red) se refiere al nombre de dominio Kerberos. Un reino Kerberos es una red o un subconjunto de una red, que es administrada como una unidad con un único servidor Kerberos.

El nombre del reino generalmente se configura en mayúsculas y suele ser una versión en mayúsculas del nombre de dominio completo (FQDN) de la red. Por ejemplo, si el nombre de dominio de tu red es «ejemplo.com», el nombre del reino Kerberos sería «EJEMPLO.COM».

Este nombre es esencial en la configuración de Kerberos, ya que define el espacio en el que se autenticarán y autorizarán los usuarios y servicios. Es importante elegirlo cuidadosamente, ya que una vez establecido, no se puede cambiar fácilmente sin reconfigurar o reinstalar el sistema de autenticación.

Tareas post-instalación

La configuración post-instalación de Red Hat Identity Manager es un paso crucial para asegurar que el sistema esté correctamente configurado y listo para su uso en un entorno de producción. Aunque los detalles específicos pueden variar según la versión y el entorno, aquí hay algunos aspectos generales que suelen incluirse en la configuración post-instalación:

Verificar la instalación

Asegúrate de que todos los servicios de Identity Manager estén funcionando correctamente. Esto incluye servicios como Kerberos, DNS, y el servidor de directorio.

1. Verificar el Estado del Servidor de Directorio (LDAP):

   systemctl status dirsrv@NOMBRE_INSTANCIA

Sustituye NOMBRE_INSTANCIA con el nombre de tu instancia de servidor de directorio.

2. Verificar el Estado de Kerberos (KDC):

   systemctl status krb5kdc

3. Verificar el Estado del Servicio de Administración de Red Hat Identity Manager:

   systemctl status ipa

4. Verificar el Estado del Servicio DNS (si se ha instalado con DNS integrado):

   systemctl status named-pkcs11

5. Verificar la Conectividad LDAP:

   ldapsearch -Y GSSAPI -h localhost -b "dc=example,dc=com"

Sustituye "dc=example,dc=com" con tu base de búsqueda LDAP adecuada.

6. Verificar Autenticación Kerberos:

   kinit admin

Luego, puedes usar klist para listar los tickets de Kerberos.

7. Revisar Registros de Instalación:
   Los registros de instalación pueden proporcionar información valiosa sobre el estado de la instalación.

   cat /var/log/ipaserver-install.log

8. Verificar la Configuración del Firewall:
   Asegúrate de que el firewall esté configurado para permitir el tráfico necesario.

   firewall-cmd --list-all

Configuración del DNS

Si instalaste Red Hat Identity Manager con el servicio DNS integrado, deberás configurar registros DNS adicionales según sea necesario, incluidos registros A, PTR y SRV. Como ejemplo, podríamos basarnos en la siguiente configuración:

1. Agregar un Registro A (Dirección):
   Este registro asocia un nombre de dominio con una dirección IP.

   ipa dnsrecord-add example.com host1 --a-ip-address=192.168.1.10

Este comando añade un registro A para host1.example.com apuntando a 192.168.1.10.

2. Agregar un Registro PTR (Puntero):
   El registro PTR se utiliza para la resolución de nombres inversa (de IP a nombre de dominio).

   ipa dnsrecord-add 1.168.192.in-addr.arpa 10 --ptr-hostname=host1.example.com

Este comando añade un registro PTR para la dirección IP 192.168.1.10, asociándola con host1.example.com.

3. Agregar Registros SRV:
   Los registros SRV se utilizan para definir la ubicación de servidores para servicios específicos.

   ipa dnsrecord-add example.com _ldap._tcp --srv-rec="0 100 389 host1.example.com."

Este comando añade un registro SRV para el servicio LDAP en host1.example.com en el puerto 389.

4. Verificar los Registros DNS:
   Después de agregar los registros, es una buena práctica verificar que están correctamente configurados.

   ipa dnsrecord-show example.com host1
   ipa dnsrecord-show 1.168.192.in-addr.arpa 10

5. Actualizar el Servicio DNS (si es necesario):
   En algunos casos, puede ser necesario reiniciar el servicio DNS para que los cambios surtan efecto.

   systemctl restart named-pkcs11

Estos comandos asumen que estás utilizando el DNS integrado de Red Hat Identity Manager y que tienes privilegios de administrador en el sistema. Debes reemplazar example.com, host1, 192.168.1.10, y otros valores del ejemplo con los nombres de dominio, nombres de host y direcciones IP reales de tu entorno.

Crear Usuarios y Grupos

Configura las cuentas de usuario y los grupos. Esto implica definir roles y permisos para gestionar el acceso a los recursos. Ejemplo de configuración:

Crear un Usuario

1. Crear un Nuevo Usuario:

   ipa user-add jdoe --first=John --last=Doe --password

Esto crea un usuario con nombre jdoe, nombre de pila John y apellido Doe. Se pedirá que establezcas una contraseña para el nuevo usuario.

2. Establecer o Cambiar la Contraseña del Usuario:

   ipa passwd jdoe

Este comando permite cambiar la contraseña del usuario jdoe.

Crear un Grupo

1. Crear un Nuevo Grupo:

   ipa group-add developers --desc="Development Team"

Esto crea un grupo llamado developers con la descripción «Development Team».

2. Añadir un Usuario a un Grupo:

   ipa group-add-member developers --users=jdoe

Esto añade el usuario jdoe al grupo developers.

Verificar Creaciones

1. Ver Información del Usuario:

   ipa user-show jdoe

Esto muestra la información del usuario jdoe.

2. Ver Miembros del Grupo:

   ipa group-show developers

Esto muestra los detalles del grupo developers, incluyendo sus miembros.

Configuración de Políticas de Seguridad

La configuración de políticas de seguridad en Red Hat Identity Manager involucra establecer parámetros para contraseñas, acceso y restricciones generales de seguridad. Ejemplos:

Configuración de Políticas de Contraseña

1. Establecer una Política de Contraseña Global:

   ipa pwpolicy-mod --minlength=12 --minclasses=3 --maxfail=5 --failinterval=600 --lockouttime=600

Este comando configura la política de contraseña global para exigir una longitud mínima de 12 caracteres, al menos 3 clases de caracteres diferentes, un máximo de 5 intentos fallidos, un intervalo de fallo de 600 segundos y un tiempo de bloqueo de 600 segundos.

2. Crear una Política de Contraseña para un Grupo Específico:

   ipa pwpolicy-add developers --minlength=15 --minclasses=4

Esto establece una política de contraseña específica para el grupo developers con requisitos más estrictos.

Configuración de Políticas de Acceso

1. Crear una Nueva Política de Acceso Basada en Host:

   ipa hbacrule-add Allow-SSH --servicecat=all --hostcat=all --usercat=all

Este comando crea una regla HBAC (Host-Based Access Control) llamada Allow-SSH que permite acceso a todos los servicios, usuarios y hosts.

2. Añadir Servicios a la Regla HBAC:

   ipa hbacrule-add-service Allow-SSH --hbacsvcs=sshd

Esto añade el servicio sshd (SSH daemon) a la regla Allow-SSH.

3. Política de rotación de contraseñas:

Para configurar una política de caducidad de contraseñas, usarías un comando como el siguiente:

ipa pwpolicy-mod [GROUP] --maxlife [DAYS]

Donde [GROUP] es el nombre del grupo al que se aplicará la política y [DAYS] es el número de días después de los cuales se requerirá que los usuarios cambien sus contraseñas.

Podemos verificar la política con el siguiente comando:

ipa pwpolicy-show [GROUP]

Configuración de Políticas de Autenticación

1. Configurar la Autenticación de Dos Factores (2FA):

   ipa config-mod --otp=True

Este comando activa la opción de autenticación de dos factores (One-Time Password – OTP) en el sistema.

2. Asignar 2FA a un Usuario Específico:

   ipa user-mod jdoe --otp=Yes

Esto activa la autenticación de dos factores para el usuario jdoe.

Estos comandos son ejemplos básicos y deben ser ajustados según las necesidades y políticas de seguridad específicas de tu organización. Además, asegúrate de tener los privilegios adecuados para ejecutar estos comandos.

Integración con Sistemas Externos

La integración de Red Hat Identity Manager con sistemas externos es una parte esencial de su implementación en entornos empresariales, donde es común que las organizaciones utilicen una variedad de plataformas y servicios. La integración puede abarcar desde la autenticación centralizada hasta la sincronización de directorios y la gestión de identidades. A continuación, se detallan algunos aspectos clave de esta integración:

• Integración con Microsoft Active Directory:
  • Confianza entre Dominios: Permite que usuarios de Active Directory se autentiquen en sistemas gestionados por Red Hat Identity Manager y viceversa. Esto se logra configurando una relación de confianza bidireccional.
  • Sincronización de Directorios: Se pueden sincronizar cuentas de usuario y otros objetos de directorio entre Active Directory y Red Hat Identity Manager para mantener la coherencia entre ambos sistemas.

• Integración con Servicios de Autenticación de Terceros:
  • LDAP Externos: Red Hat Identity Manager puede integrarse con otros servicios de directorio LDAP, permitiendo la autenticación y la gestión de identidades a través de múltiples fuentes.
  • Sistemas de Autenticación de Terceros: Puede integrarse con sistemas de autenticación de terceros, como proveedores de identidad basados en SAML o OAuth, para permitir el inicio de sesión único (SSO).

• Integración con Sistemas de Gestión de Infraestructura:
  • Herramientas de Orquestación y Automatización: Integración con herramientas como Ansible para la automatización de tareas relacionadas con la gestión de identidades.
  • Plataformas en la Nube: Configuración para trabajar con plataformas en la nube, como AWS, Azure o Google Cloud, para gestionar identidades y accesos en entornos de nube híbrida.

• Integración con Sistemas de Control de Acceso:
  • Sistemas de Gestión de Políticas de Acceso: Integración con soluciones de gestión de acceso y autorización para aplicar políticas de seguridad a través de diferentes plataformas.

• APIs y Herramientas de Desarrollo:
  • Interfaz de Programación de Aplicaciones (API): Ofrece APIs que permiten a los desarrolladores integrar la gestión de identidades de Red Hat Identity Manager en sus aplicaciones y servicios.
  • SDKs y Herramientas de Desarrollo: Proporciona kits de desarrollo de software (SDKs) para facilitar la integración en diferentes lenguajes de programación.

• Cumplimiento y Auditoría:
  • Integración con Sistemas de Registro y Monitorización: Permite la integración con sistemas de registro y monitorización para el seguimiento de actividades y el cumplimiento de normativas.

Para realizar estas integraciones, es fundamental planificar cuidadosamente, comprender los requisitos de ambos sistemas y realizar pruebas exhaustivas para asegurar que la integración funcione como se espera y mantenga la seguridad y la integridad de los datos.

Configuración de Autenticación de Múltiples Factores (MFA)

La Configuración de Autenticación de Múltiples Factores (MFA) en Red Hat Identity Manager aumenta significativamente la seguridad al requerir más de una forma de verificación para acceder a los recursos del sistema. La MFA puede incluir algo que el usuario conoce (como una contraseña), algo que el usuario tiene (como un token de seguridad o teléfono móvil), y algo que el usuario es (como una huella digital). A continuación, se describen los pasos generales para configurar MFA en Red Hat Identity Manager:

Habilitar MFA en el Servidor

1. Configurar la Autenticación de Dos Factores Globalmente:
   Para habilitar la MFA en todo el sistema, se debe modificar la configuración global. Esto se puede hacer con el comando:

   ipa config-mod --otp=True

Este comando activa la opción de OTP (One-Time Password).

2. Configurar Servicios de Autenticación Externos:
   Si se utilizan servicios de autenticación externos, como TOTP (Time-based One-Time Password) o servicios basados en hardware, estos deben ser configurados e integrados adecuadamente.

Configurar MFA para Usuarios Individuales

1. Habilitar MFA para un Usuario Específico:
   Puedes especificar que ciertos usuarios requieran MFA para el inicio de sesión. Por ejemplo:

   ipa user-mod nombre_usuario --otp=True

Esto habilita la autenticación de dos factores para el usuario especificado.

2. Registrar Dispositivos de Autenticación para Usuarios:
   Los usuarios deben registrar sus dispositivos o métodos de autenticación, como tokens de hardware, aplicaciones de autenticación móvil, o dispositivos U2F.

Configurar Políticas de Acceso con MFA

1. Crear Reglas de Control de Acceso Basadas en Host (HBAC) que Requieren MFA:
   Puedes crear reglas HBAC que requieran MFA para ciertos hosts o servicios. Por ejemplo:

   ipa hbacrule-add Rule-MFA --servicecat=all --hostcat=all --usercat=all
   ipa hbacrule-add-service Rule-MFA --hbacsvcs=sshd
   ipa hbacrule-mod Rule-MFA --accessruletype=allow --usercat=all --hostcat=all --sourcehostcat=all --servicecat=all --ruletype=allow

2. Aplicar la Política a Grupos o Usuarios Específicos:
   Aplica la regla a grupos o usuarios específicos para garantizar que solo los usuarios autorizados y con MFA puedan acceder a los recursos.

Pruebas y Validación

1. Probar la Configuración de MFA:
   Es esencial probar la configuración con varios usuarios y métodos de autenticación para asegurarse de que la MFA funcione según lo esperado.
2. Monitorear y Ajustar la Configuración:
   Monitorea el rendimiento y la usabilidad del sistema MFA y haz ajustes según sea necesario.

La implementación de MFA requiere una planificación cuidadosa y consideración de los métodos de autenticación disponibles y la experiencia del usuario. La documentación específica de Red Hat y los recursos de la comunidad pueden proporcionar guías detalladas y mejores prácticas para configurar MFA en Red Hat Identity Manager.

Auditoría y Registro

Este apartado implica configurar y utilizar herramientas para monitorear, registrar y auditar las actividades y eventos del sistema. Esto es crucial para la seguridad, el cumplimiento de normativas y la resolución de problemas. Los siguientes son los aspectos clave de la auditoría y el registro en Red Hat Identity Manager:

Configuración de Registro (Logging)

1. Modificar la Configuración de Registro de LDAP:

   ipa config-mod --ldapdebug=256

Este comando ajusta el nivel de registro de LDAP.

2. Ver Registros de LDAP:

   tail -f /var/log/dirsrv/slapd-INSTANCE/access

Sustituye INSTANCE con el nombre de tu instancia LDAP.

3. Ver Registros de Kerberos (KDC):

   tail -f /var/log/krb5kdc.log

Auditoría de Acciones de Usuario

1. Ver Registros de Acceso y Cambios:

   ipa search --criteria="acción específica"

Buscar eventos específicos en los registros de auditoría.

Integración con Sistemas de Monitoreo Externos

1. Configurar el Envío de Registros a un Sistema Centralizado:
   Para syslog, puedes editar el archivo de configuración /etc/rsyslog.conf o crear un archivo en /etc/rsyslog.d/ y agregar líneas como:

   *.* @hostname_servidor_log:puerto

Esto enviará todos los registros a un servidor syslog centralizado.

2. Reiniciar el Servicio de Syslog para Aplicar Cambios:

   systemctl restart rsyslog

Cumplimiento y Reportes

1. Exportar Registros para Análisis:
   Puedes usar comandos como grep, awk, o herramientas de línea de comandos para extraer y exportar datos de los archivos de registro para análisis y reportes.

   grep "criterio" /var/log/nombre_del_archivo.log > archivo_reporte.log

Mantenimiento y Verificación de Registros

1. Verificar Configuraciones Actuales de Registro:

   ipa config-show

Esto mostrará la configuración actual, incluyendo configuraciones de registro.

2. Rotación y Gestión de Archivos de Registro:
   La configuración de rotación de registros generalmente se realiza editando archivos de configuración en /etc/logrotate.d/.

Estos comandos y configuraciones son ejemplos generales y deben ser adaptados a las necesidades específicas de cada entorno.

Copia de Seguridad y Recuperación

Esta función es vital para la continuidad del negocio y la integridad de los datos:

Creación de Copias de Seguridad

1. Hacer una Copia de Seguridad del Servidor de Identidades:
   El comando ipa-backup se utiliza para crear una copia de seguridad del servidor. Este proceso respalda los datos de LDAP, los certificados y otros datos de configuración.

   ipa-backup

Esto crea una copia de seguridad completa del servidor de identidades.

2. Opciones de Copia de Seguridad:
   Puedes especificar opciones para realizar copias de seguridad solo de datos específicos:

• Copia de Seguridad de Datos en Línea: Para realizar una copia de seguridad sin detener el servidor.
  bash ipa-backup --online
• Copia de Seguridad de Datos y Configuración del Servidor: Excluye los certificados CA.
  bash ipa-backup --data

2. Ubicación de la Copia de Seguridad:
   Las copias de seguridad se almacenan en /var/lib/ipa/backup/. Asegúrate de transferir estos archivos a una ubicación segura.

Restauración de Datos

1. Restaurar un Servidor de Identidades:
   Para restaurar un servidor de identidades, utiliza el comando ipa-restore. Debes especificar la ruta del archivo de copia de seguridad.

   ipa-restore /var/lib/ipa/backup/ipa-backup-2020-12-31-10-00-00

Reemplaza la ruta del archivo con la ruta de tu archivo de copia de seguridad específico.

Prácticas Recomendadas

1. Programar Copias de Seguridad Regulares:
   Utiliza herramientas como cron para programar copias de seguridad periódicas.

   0 3 * * * /usr/sbin/ipa-backup --online > /var/log/ipa-backup.log 2>&1

Esto programa una copia de seguridad diaria a las 3 AM.

2. Verificar las Copias de Seguridad:
   Regularmente verifica la integridad de las copias de seguridad y realiza pruebas de restauración.
3. Almacenamiento Seguro y Redundante:
   Almacena las copias de seguridad en ubicaciones seguras y preferiblemente en múltiples ubicaciones físicas o en la nube para prevenir la pérdida de datos.

Gestión de Identidades

Creación y Administración de Usuarios

La creación y administración de usuarios en Red Hat Identity Manager (RH IDM) se pueden realizar a través de la interfaz de línea de comandos (CLI) o mediante la interfaz web.

Para poder ejecutar los comandos que veremos a continuación, primero nos tenemos que conectar al servidor de IDM con SSH y autentificarnos:

kinit admin

Aquí, admin es el usuario administrativo por defecto en IDM. Se te pedirá ingresar la contraseña.

Comandos Básicos para la Gestión de Usuarios

1. Crear un Nuevo Usuario

   ipa user-add <username> --first=<nombre> --last=<apellido> --password

Este comando crea un nuevo usuario. Debes reemplazar <username>, <nombre>, y <apellido> con los detalles del nuevo usuario. El flag --password permite establecer una contraseña inicial que deberá ser cambiada en el primer inicio de sesión.

2. Establecer o Cambiar la Contraseña de un Usuario

   ipa passwd <username>

Cambia la contraseña del usuario especificado.

3. Modificar Atributos de un Usuario Existente

   ipa user-mod <username> --<atributo>=<valor>

Aquí puedes modificar distintos atributos del usuario, como dirección de correo electrónico, número de teléfono, etc. Sustituye <atributo> y <valor> con el atributo que deseas cambiar y su nuevo valor.

4. Buscar Usuarios

   ipa user-find --<criterio>=<valor>

Este comando se utiliza para buscar usuarios en función de diversos criterios como nombre de usuario, nombre, apellido, etc.

5. Mostrar Información de un Usuario

   ipa user-show <username>

Muestra la información detallada de un usuario.

6. Desactivar un Usuario

   ipa user-disable <username>

Este comando desactiva la cuenta de usuario, impidiendo su acceso al sistema.

7. Activar un Usuario

   ipa user-enable <username>

Reactiva una cuenta de usuario previamente desactivada.

8. Eliminar un Usuario

   ipa user-del <username>

Borra la cuenta de un usuario.

Administración de Grupos y Roles

La administración de grupos y roles en Red Hat Identity Manager (RH IDM) es crucial para una gestión eficiente y segura de los accesos y políticas dentro de una organización. Al igual que con los usuarios, la gestión de grupos y roles se puede realizar mediante la interfaz de línea de comandos (CLI). Aquí te proporciono un resumen de los comandos más comunes para administrar grupos y roles.

Administración de Grupos

1. Crear un Nuevo Grupo

   ipa group-add <nombre_grupo> --desc="<descripción>"

Crea un nuevo grupo con el nombre y descripción especificados.

2. Añadir un Usuario a un Grupo

   ipa group-add-member <nombre_grupo> --users=<usuario>

Añade un usuario existente al grupo especificado.

3. Listar Todos los Grupos

   ipa group-find

Muestra todos los grupos disponibles.

4. Mostrar Información de Grupo

   ipa group-show <nombre_grupo>

Muestra detalles sobre un grupo específico.

5. Eliminar un Grupo

   ipa group-del <nombre_grupo>

Elimina el grupo especificado.

Administración de Roles

1. Crear un Nuevo Rol

   ipa role-add <nombre_rol> --desc="<descripción>"

Crea un nuevo rol con un nombre y descripción.

2. Añadir un Privilegio a un Rol

   ipa role-add-privilege <nombre_rol> --privileges=<nombre_privilegio>

Añade un privilegio específico al rol. Los privilegios son conjuntos de permisos.

3. Añadir un Usuario o Grupo a un Rol

   ipa role-add-member <nombre_rol> --users=<usuario>
   ipa role-add-member <nombre_rol> --groups=<grupo>

Asigna el rol a un usuario o grupo específico.

4. Listar Todos los Roles

   ipa role-find

Muestra todos los roles disponibles.

5. Mostrar Información de Rol

   ipa role-show <nombre_rol>

Proporciona detalles sobre un rol específico.

6. Eliminar un Rol

   ipa role-del <nombre_rol>

Elimina el rol especificado.

Configuración de Control de Acceso Basado en Host en Red Hat Identity Manager para Usuarios Específicos en Servidores Oracle

Para restringir el acceso de usuarios a servidores específicos en un entorno que utiliza Red Hat Identity Manager (IDM), puedes implementar políticas de acceso basadas en Host-Based Access Control (HBAC). A continuación, veremos un ejemplo en el que el usuario «oracle» solamente va a poder hacer login por SSH a los servidores oraclesrv01, oraclesrv02 y oraclesrv03:

Paso 1: Crear un Grupo de Servidores

1. Agrupa los Servidores: Primero, agrupa los servidores que tienen bases de datos Oracle. Puedes hacer esto creando un nuevo grupo de host en IDM y agregando a este grupo todos los servidores Oracle. Por ejemplo, podrías crear un grupo llamado oracle-servers.

ipa hostgroup-add oracle-servers --desc="Oracle Database Servers"
ipa hostgroup-add-member oracle-servers --hosts=oraclesrv01
ipa hostgroup-add-member oracle-servers --hosts=oraclesrv02
ipa hostgroup-add-member oracle-servers --hosts=oraclesrv03

El nombre de los hosts debe coincidir, exactamente, con el dado de alta en IDM. Lo podemos hacer de diferentes maneras:

• Lista de Hosts Registrados: Una vez que hayas iniciado sesión, puedes listar todos los hosts registrados en IDM utilizando el comando ipa host-find. Este comando mostrará una lista de todos los hosts, incluyendo sus nombres completos.

ipa host-find

Este comando mostrará una lista de todos los hosts junto con algunos detalles básicos.

• Buscar un Host Específico: Si estás buscando un host específico y conoces parte de su nombre, puedes utilizar un filtro con el comando ipa host-find. Por ejemplo, si estás buscando hosts que incluyan «oracle» en su nombre, puedes usar:

ipa host-find --criteria=oracle

Esto filtrará los resultados para mostrar solo los hosts que coincidan con tu criterio de búsqueda.

• Ver Detalles de un Host Específico: Para obtener información más detallada sobre un host específico, puedes usar el comando ipa host-show seguido del nombre del host. Por ejemplo:

ipa host-show oraclesrv01

Este comando te proporcionará información detallada sobre el host oraclesrv01.

Paso 2: Crear una Regla HBAC

2. Crear una Regla HBAC: Luego, necesitas crear una regla de acceso basada en host (HBAC) en IDM que defina qué usuarios o grupos pueden acceder a qué grupos de servidores. En este caso, querrás crear una regla que permita al usuario «oracle» (o a un grupo de usuarios que incluya «oracle») acceder solo a los servidores en el grupo oracle-servers.

ipa hbacrule-add allow_oracle_to_oracle_servers --desc="Access for Oracle user to Oracle servers"
ipa hbacrule-add-user allow_oracle_to_oracle_servers --users=oracle
ipa hbacrule-add-host allow_oracle_to_oracle_servers --hostgroups=oracle-servers
ipa hbacrule-add-service allow_oracle_to_oracle_servers --hbacsvcs=ssh

Paso 3: Configurar la Regla HBAC

3. Configuración de la Regla: Al configurar la regla HBAC, especifica los siguientes componentes:
   • Usuarios/Grupos de Usuarios: El usuario «oracle» o un grupo que lo contenga.
   • Grupos de Host: oracle-servers.
   • Servicios: Generalmente «ssh» y cualquier otro servicio necesario para el acceso.
   • Permitir o Denegar Acceso: Configura la regla para permitir el acceso.

En algunos casos, puede ser necesario reiniciar servicios específicos para que los cambios tengan efecto. Por ejemplo, si haces cambios relacionados con la autenticación o la autorización, podría ser necesario reiniciar servicios como SSSD (systemctl restart sssd) en los servidores cliente.

Añadir el usuario oracle a otro grupo de servidores adicional

Para permitir que el usuario «oracle» acceda también a los servidores que ejecutan aplicaciones conectadas a bases de datos Oracle pero que no alojan las bases de datos en sí, necesitarás configurar reglas adicionales en Red Hat Identity Manager (IDM). El proceso implicará la creación de otro grupo de hosts para estos servidores y la actualización o creación de reglas HBAC para reflejar este acceso extendido.

• Creamos el nuevo grupo de hosts en IDM

ipa hostgroup-add oracle-app-servers --desc="Oracle Application Servers"
ipa hostgroup-add-member oracle-app-servers --hosts=[nombre-del-servidor]

• Creamos las nuevas reglas RBAC

ipa hbacrule-add allow_oracle_to_app_servers --desc="Access for Oracle user to Oracle Application servers"
ipa hbacrule-add-user allow_oracle_to_app_servers --users=oracle
ipa hbacrule-add-host allow_oracle_to_app_servers --hostgroups=oracle-app-servers
ipa hbacrule-add-service allow_oracle_to_app_servers --hbacsvcs=ssh

¿Dónde se almacenan los datos de RH IDM?

Red Hat Identity Management (IDM), que es una implementación de FreeIPA, gestiona y almacena los datos de los usuarios en su propia base de datos interna, la cual se basa en una combinación de tecnologías, incluyendo un servidor LDAP y una base de datos Kerberos. No es necesario configurar un servidor LDAP o Active Directory externo, ya que IDM proporciona estas funcionalidades de forma integrada.

Aquí hay un desglose de cómo IDM maneja el almacenamiento de datos:

1. Servidor LDAP (389 Directory Server): IDM utiliza el 389 Directory Server, un servidor LDAP de código abierto, para almacenar la mayoría de los datos relacionados con usuarios, grupos, políticas y otros objetos de directorio. Este servidor es el núcleo de la gestión de identidades en IDM, proporcionando un repositorio centralizado y un protocolo estándar para el acceso a la información del directorio.
2. Kerberos: IDM también incluye un servidor Kerberos, que es responsable de la autenticación de usuarios. Los detalles de autenticación, como las contraseñas y los tickets de Kerberos, se almacenan y gestionan a través de este componente.
3. Certificados y PKI: IDM incluye una infraestructura de clave pública (PKI) para la gestión de certificados digitales. Esta parte es manejada por Dogtag Certificate System, que se integra con el 389 Directory Server y el servidor Kerberos.
4. Sistema de Base de Datos Integrado: Aunque los detalles específicos de la base de datos no son generalmente manejados directamente por los administradores de IDM, el sistema utiliza una base de datos integrada para almacenar información relacionada con su configuración y operación. Esta base de datos es parte de la implementación de 389 Directory Server y Dogtag Certificate System.
5. Integración con Active Directory: Aunque IDM puede funcionar de manera autónoma, también está diseñado para integrarse con entornos existentes de Active Directory (AD) si es necesario. Esto permite la coexistencia y la sincronización entre los entornos IDM y AD, facilitando la gestión de identidades en entornos híbridos.

En resumen, IDM es una solución completa que incluye su propio almacenamiento y gestión de datos de identidad, eliminando la necesidad de configurar y mantener servidores LDAP o Active Directory externos para este propósito.

Integración con LDAP y Active Directory

La integración de Red Hat Identity Manager (RH IDM) con LDAP y Active Directory (AD) es una característica fundamental para las organizaciones que operan en entornos mixtos y buscan unificar la gestión de identidades y accesos. Esta integración permite a las empresas aprovechar las ventajas de una administración centralizada de usuarios, incluso cuando se utilizan diferentes sistemas operativos y servicios.

Integración con LDAP

Conceptos Clave:

• LDAP (Lightweight Directory Access Protocol) es un protocolo estándar para acceder y mantener servicios de directorio distribuidos, como los directorios de usuarios.
• RH IDM utiliza un servidor LDAP integrado para almacenar información de usuarios, grupos y otros objetos.

• Implementación:
  • La integración se logra sincronizando los datos entre el servidor LDAP y RH IDM.
  • Puedes configurar RH IDM para autenticar usuarios almacenados en un directorio LDAP externo o importar usuarios y grupos de un servidor LDAP a RH IDM.

• Beneficios:
  • Permite la gestión centralizada de identidades y accesos, incluso en entornos con múltiples sistemas operativos y aplicaciones.
  • Facilita la coherencia de las políticas de seguridad y acceso en toda la organización.

Configuración de la conexión LDAP

Damos por hecho que ya tenemos configurado un servidor de LDAP.

1. Establecimiento de la Conexión:
   • Ejemplo: En el archivo ipa-server.conf, establece parámetros como ldap_uri = ldap://ldap.ejemplo.com, bind_dn = cn=Manager,dc=ejemplo,dc=com.
2. Mapeo de Atributos:
   • Ejemplo: En /etc/ipa/ldap.attrmap.cfg, define memberOf: memberOf para mapear el atributo de pertenencia a un grupo.
3. Configuración de Sincronización:
   • Ejemplo: Usa ipa-ldap-updater con un archivo de configuración personalizado que especifique qué atributos sincronizar, por ejemplo, users: sn, givenName, mail.
4. Pruebas de Conexión:
   • Ejemplo: Utiliza ldapsearch -x -b "dc=ejemplo,dc=com" para probar la conectividad y verificar la estructura del directorio LDAP.
5. Configuración de la autentificación:
   • Configura el servidor LDAP para aceptar solicitudes de autenticación de RH IDM, ajustando parámetros en el archivo de configuración del servidor LDAP, como authz-regexp.

Comandos útiles:

• Ejemplo de ipa-ldap-updater: ipa-ldap-updater custom_sync_config.py para aplicar una configuración de sincronización personalizada.
• Ejemplo de ipa user-add: ipa user-add jdoe --first=John --last=Doe --email=jdoe@ejemplo.com.
• Ejemplo de ldapsearch: ldapsearch -x -b "dc=ejemplo,dc=com" "(uid=jdoe)" para buscar a un usuario específico.

Veámos un ejemplo de configuración específico para integrar RH IDM con múltiples servidores de LDAP

1. Archivo de Configuración de SSSD (/etc/sssd/sssd.conf): Este es el archivo principal para configurar SSSD. Necesitas especificar cada dominio LDAP que SSSD debe consultar. Aquí un ejemplo básico:

[sssd]
services = nss, pam
domains = ldap1, ldap2

[domain/ldap1]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap1.example.com
ldap_search_base = dc=example,dc=com

[domain/ldap2]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap2.example.com
ldap_search_base = dc=example2,dc=com

En este archivo, se configuran dos dominios LDAP diferentes, cada uno con su propio URI y base de búsqueda.

2. Archivo de Configuración de LDAP (/etc/ldap/ldap.conf): Este archivo se utiliza para configurar las opciones del cliente LDAP. Aquí puedes especificar los certificados y opciones de cifrado para asegurar la comunicación con los servidores LDAP.

TLS_CACERT /etc/ssl/certs/ca-certificates.crt
BASE dc=example,dc=com
URI ldap://ldap1.example.com ldap://ldap2.example.com

3. Archivos de Configuración de Aplicaciones Específicas: Dependiendo de las aplicaciones que necesiten integrarse con los servidores LDAP, es posible que tengas que configurar archivos adicionales. Por ejemplo, si estás utilizando Apache o Nginx para autenticación basada en web, tendrás que configurar los módulos correspondientes con la información del servidor LDAP.

Integración con Active Directory

Conceptos Clave:

• Active Directory es un servicio de directorio de Microsoft utilizado principalmente en entornos Windows para gestionar políticas, autenticación y autorización.
• RH IDM puede integrarse con AD para permitir a los usuarios de AD autenticarse en sistemas Linux y viceversa.

• Implementación:
  • La integración se realiza a través de una relación de confianza entre RH IDM y AD.
  • Se configura un mecanismo de sincronización para que los usuarios de AD puedan acceder a recursos en sistemas Linux gestionados por RH IDM y, en algunos casos, al revés.

• Beneficios:
  • Proporciona una solución única de inicio de sesión (Single Sign-On, SSO) y una gestión de identidades unificada para usuarios en sistemas Linux y Windows.
  • Mejora la seguridad y simplifica la administración de usuarios y accesos en entornos heterogéneos.

Sincronización de RH IDM con Active Directory

La sincronización entre Red Hat Identity Manager (RH IDM) y Active Directory (AD) se puede realizar mediante una serie de pasos detallados, apoyados por comandos específicos. Aquí te proporciono un desglose de los pasos con ejemplos de comandos que podrían ser utilizados en este proceso:

Establecimiento de una Relación de Confianza

• Configurar una Relación de Confianza Bidireccional:
  • Comando Ejemplo: Para agregar un dominio AD como un dominio de confianza en RH IDM:
    bash ipa trust-add --type=ad ad.example.com --admin admin_user --password
  • Este comando inicia la configuración de una relación de confianza con el dominio AD ad.example.com, utilizando la cuenta de administrador admin_user.

Sincronización de Usuarios y Grupos

• Configuración de la Sincronización:
  • Comandos y Configuraciones: A menudo, la sincronización se maneja automáticamente una vez que la relación de confianza está establecida. La configuración específica puede depender de las necesidades de tu organización y de la versión específica de RH IDM y AD.

Configuración de SSO y Kerberos

• Ajuste de Configuración de Kerberos:
  • Archivo de Configuración: Edita /etc/krb5.conf para configurar los reinos y kdc de AD.
  • Ejemplo:
    

[libdefaults]
default_realm = AD.EXAMPLE.COM

Mapeo de Atributos y Políticas

El mapeo de atributos y políticas en la sincronización entre Red Hat Identity Manager (RH IDM) y Active Directory (AD) es un aspecto crucial para garantizar una gestión coherente y efectiva de las identidades de usuario y grupo en entornos mixtos. Este proceso implica definir cómo los atributos de usuario y grupo en AD se corresponden y sincronizan con los atributos en RH IDM.

Mapeo de Atributos

El mapeo de atributos se refiere a la correlación de los campos de datos de usuario y grupo entre AD y RH IDM. Por ejemplo, el atributo mail en AD debe mapearse al atributo correspondiente en RH IDM para que los correos electrónicos de los usuarios se sincronicen correctamente.

• Ejemplo de Mapeo de Atributos:
  • En AD, un usuario tiene atributos como sAMAccountName, mail, givenName, y sn.
  • Estos atributos deben mapearse a los atributos correspondientes en RH IDM, como uid, mail, givenname, y sn.

• Configuración:
  • Esta configuración se realiza a menudo a través de la interfaz de administración de RH IDM o mediante scripts de configuración personalizados.
  • No hay un comando específico en RH IDM para el mapeo de atributos, ya que generalmente se configura durante la fase de instalación o mediante la modificación directa de archivos de configuración o la utilización de interfaces de gestión.

Políticas

Las políticas se refieren a las reglas y configuraciones que determinan cómo se manejan los usuarios y grupos dentro de la organización. Esto incluye políticas de contraseñas, permisos, y roles.

• Ejemplo de Políticas:
  • Políticas de Contraseñas: Asegúrate de que las políticas de complejidad y caducidad de contraseñas en RH IDM coincidan o se complementen con las de AD.
  • Roles y Permisos: Define roles en RH IDM que reflejen las responsabilidades y niveles de acceso de los usuarios en AD.

• Configuración:
  • Las políticas suelen configurarse a través de la interfaz de administración de RH IDM o mediante la utilización de comandos específicos. Por ejemplo:
    • Para definir una política de contraseña: ipa pwpolicy-mod --minlen=8 --minclasses=3
    • Para asignar roles a un usuario: ipa user-add-role jdoe --roles=admin

Integración y Sincronización

• Integración Continua: El mapeo de atributos y las políticas deben revisarse y actualizarse regularmente para garantizar que la integración entre RH IDM y AD siga siendo efectiva y segura.
• Automatización y Scripting: En entornos grandes, puede ser beneficioso automatizar aspectos del mapeo y la gestión de políticas mediante scripts.

Herramientas que ayudan con el mapeo de atributos y políticas

Aunque no existen comandos específicos de Red Hat Identity Manager (RH IDM) o Active Directory (AD) para el mapeo directo de atributos y políticas, hay varios comandos y herramientas que se utilizan en el proceso de configuración y sincronización. Algunos ejemplos:

En Red Hat Identity Manager

• Gestión de Políticas de Contraseñas:
  • Modificar una política de contraseña existente:
    bash ipa pwpolicy-mod --minlen=12 --maxfail=5 mi_politica
    Este comando ajusta la política de contraseña llamada mi_politica, estableciendo una longitud mínima de contraseña de 12 caracteres y un máximo de 5 intentos fallidos.

• Asignación de Roles y Permisos:
  • Asignar un rol a un usuario:
    bash ipa user-add-role jdoe --roles=rol_administrador
    Aquí, el usuario jdoe recibe el rol rol_administrador.

En Active Directory

• Consultar Atributos de Usuario con PowerShell:
  • Obtener atributos de un usuario específico:
    powershell Get-ADUser jdoe -Properties *
    Este comando en PowerShell lista todos los atributos del usuario jdoe en AD.

Herramientas y Scripts de Automatización

• Scripts de Sincronización Personalizados:
  • Un script personalizado podría utilizarse para leer atributos de AD y aplicar cambios correspondientes en RH IDM. Estos scripts a menudo se escriben en lenguajes como Python o Perl y utilizan APIs o módulos para interactuar con AD y RH IDM.

Herramientas LDAP para Exploración y Mapeo

• Uso de ldapsearch para Explorar Atributos:
  • Ejemplo para consultar atributos LDAP en un servidor RH IDM:
    bash ldapsearch -x -b "dc=miorganizacion,dc=com" "(uid=jdoe)"
    Este comando busca información sobre el usuario jdoe en la base de datos LDAP de RH IDM.

Pruebas y Validación

• Verificación de Usuarios Sincronizados:
  • Comando Ejemplo: Para verificar un usuario sincronizado de AD en RH IDM:
    bash ipa user-show jdoe
  • Este comando muestra la información de jdoe, asumiendo que este usuario ha sido sincronizado desde AD.

Cifrado y Protección de Datos

El cifrado y la protección de datos son aspectos fundamentales de la seguridad en Red Hat Identity Manager (RH IDM), una solución de gestión de identidades y accesos. RH IDM implementa múltiples capas de seguridad para garantizar la protección de datos sensibles, incluyendo información de usuarios, políticas y credenciales. A continuación, se detallan algunos de los aspectos clave relacionados con el cifrado y la protección de datos en RH IDM:

Cifrado de Datos en Reposo

• Almacenamiento Seguro de Credenciales:
  • Las contraseñas y otros datos sensibles de los usuarios se almacenan en forma cifrada en la base de datos de RH IDM.
  • RH IDM utiliza algoritmos de hash fuertes para almacenar contraseñas de forma segura.

• Cifrado del Sistema de Archivos:
  • Se recomienda implementar el cifrado a nivel de sistema de archivos para proteger los datos almacenados, utilizando herramientas como LUKS (Linux Unified Key Setup) en Linux.

Cifrado de Datos en Tránsito

• Comunicaciones Seguras con SSL/TLS:
  • Todas las comunicaciones entre el cliente y el servidor RH IDM deben estar protegidas mediante SSL/TLS para garantizar la confidencialidad e integridad de los datos transmitidos.
  • Esto incluye la autenticación LDAP, la interfaz web y las conexiones de sincronización con otros sistemas como Active Directory.

• Configuración de Certificados:
  • RH IDM permite y gestiona la configuración de certificados SSL/TLS para asegurar las conexiones.
  • Los certificados pueden ser auto-firmados o emitidos por una autoridad de certificación (CA) confiable.

Ejemplo para Apache en /etc/httpd/conf.d/ssl.conf:

SSLCertificateFile /ruta/a/mi_certificado.crt
SSLCertificateKeyFile /ruta/a/mi_clave.key

Autenticación y Autorización

• Políticas de Contraseñas Fuertes:
  • RH IDM permite configurar políticas de contraseñas que exigen características como longitud mínima, complejidad y caducidad.

• Autenticación Multifactor (MFA):
  • Para una seguridad adicional, RH IDM admite la configuración de autenticación multifactor.
  • Este tema ya ha sido tratado anteriormente en este documento

• Control de Acceso Basado en Roles (RBAC):
  • RH IDM utiliza RBAC para garantizar que los usuarios tengan solo el nivel de acceso necesario para realizar sus funciones.
  • Este tema ya ha sido tratado anteriormente en este documento

Auditoría y Cumplimiento

1. Registros de Auditoría:

• RH IDM proporciona registros detallados de auditoría que incluyen información sobre accesos, modificaciones y transacciones de los usuarios.
• Estos registros son fundamentales para el cumplimiento de normativas y la investigación de incidentes de seguridad.
• Ver el apartado «Auditoría y Registro» para más detalles.

Respaldo y Recuperación

• Procedimientos de Respaldo Seguro:
  • Es esencial implementar una estrategia de respaldo y recuperación que incluya el cifrado de los datos de respaldo para protegerlos contra accesos no autorizados.
  • Ver el apartado «Creación de Copias de Seguridad» para más detalles.

Consideraciones de Configuración y Gestión

• Actualizaciones Regulares y Parches de Seguridad: Mantener el sistema actualizado con los últimos parches de seguridad es crucial para proteger contra vulnerabilidades conocidas.
• Configuración Cuidadosa: Una configuración incorrecta puede exponer datos sensibles, por lo que es esencial seguir las mejores prácticas y las recomendaciones de la documentación de RH IDM.

Acceso a la interfaz gráfica de administración de RedHat Identity Manager

Hasta ahora, hemos visto la configuración de diferentes aspectos de IDM a través de la línea de comandos, pero también podemos realizar tareas de administración a través de su interfaz gráfica.

Pasos para Acceder a la Interfaz Gráfica de RH IDM

• Asegúrate de que el Servicio RH IDM esté en Funcionamiento:
  • Antes de intentar acceder a la GUI, verifica que el servicio RH IDM esté activo en el servidor. Esto se puede hacer mediante la línea de comandos con un comando como:
    bash systemctl status ipa

• Conoce la Dirección del Servidor:
  • Debes conocer la dirección IP o el nombre de dominio completo (FQDN) del servidor donde está instalado RH IDM. Por ejemplo, idm.ejemplo.com.

• Usar un Navegador Web:
  • Abre un navegador web en tu computadora.

• Introduce la URL de RH IDM:
  • Escribe la URL del servidor RH IDM en la barra de direcciones del navegador. La URL generalmente es de la forma https://<FQDN_de_RH_IDM>, por ejemplo, https://idm.ejemplo.com.
  • Si estás utilizando un certificado autofirmado, es posible que el navegador advierta sobre un problema de seguridad del certificado. Dependiendo de tu configuración, puedes necesitar añadir una excepción de seguridad para continuar.

• Iniciar Sesión:
  • Se te presentará una pantalla de inicio de sesión. Ingresa tus credenciales de RH IDM. Estas serán las credenciales del administrador o de cualquier otro usuario con permisos para acceder a la GUI.

• Navegar por la Interfaz:
  • Una vez que hayas iniciado sesión, podrás navegar por la interfaz gráfica para gestionar usuarios, grupos, políticas, etc.

Consideraciones de Seguridad

• Conexión Segura: Asegúrate de que estás utilizando HTTPS para una conexión segura.
• Firewall y Red: Si no puedes acceder a la GUI, verifica que no haya reglas de firewall bloqueando el acceso al puerto utilizado por RH IDM (generalmente el puerto 443 para HTTPS).
• Certificados SSL/TLS: Si has configurado RH IDM con un certificado SSL/TLS emitido por una autoridad de certificación, asegúrate de que el certificado esté correctamente instalado y configurado.

Conexión desde un cliente al servidor de IDM

Configurar un cliente para usar Red Hat Identity Manager (RH IDM) es un proceso que implica instalar ciertos paquetes de software en el cliente, inscribir el cliente en RH IDM, y posiblemente ajustar algunas configuraciones adicionales. Aquí te guío a través de los pasos básicos para configurar un cliente Linux para usar RH IDM:

1. Preparación del Cliente

Antes de comenzar, asegúrate de que el cliente tenga una conexión de red estable al servidor RH IDM y que el nombre de dominio del cliente esté correctamente configurado.

2. Instalar los Paquetes Necesarios

1. Actualiza el Sistema:

• Es una buena práctica actualizar todos los paquetes existentes a la última versión disponible.
  bash sudo yum update

1. Instalar Paquetes de IPA:

• Instala los paquetes necesarios para la inscripción del cliente.
  bash sudo yum install ipa-client

3. Inscribir el Cliente en RH IDM

Utiliza el comando ipa-client-install para inscribir el cliente en el servidor RH IDM.

• Ejecutar el Comando de Inscripción:

   sudo ipa-client-install --principal=admin --password=<AdminPassword> --server=<idm_server_fqdn> --domain=<idm_domain> --mkhomedir

• --principal y --password son las credenciales del administrador de RH IDM.
• --server es el nombre de dominio completo del servidor RH IDM.
• --domain es el dominio de RH IDM.
• --mkhomedir es una opción para crear automáticamente un directorio home para los usuarios al iniciar sesión.

• Seguir las Instrucciones en Pantalla:
  • El script te guiará a través de varios pasos y te pedirá confirmación para algunas configuraciones.

4. Configuraciones Adicionales

• Configurar la Autenticación Automática:

Configurar la autenticación automática en un cliente Red Hat Identity Manager (RH IDM) implica ajustar la configuración de dos componentes clave en Linux: PAM (Pluggable Authentication Modules) y NSS (Name Service Switch). Estos ajustes permiten que el sistema del cliente autentique a los usuarios utilizando las credenciales almacenadas en RH IDM y proporcionen acceso a la información del directorio de usuarios y grupos. Aquí te muestro cómo hacerlo:

Configurar PAM para la Autenticación

PAM gestiona cómo las aplicaciones del sistema autentican a los usuarios. Cuando configuras un cliente con RH IDM, generalmente el proceso de inscripción configura PAM automáticamente para usar RH IDM para la autenticación. Sin embargo, puedes necesitar hacer ajustes manuales en algunos casos.

• Archivos de Configuración de PAM:
  • Los archivos en /etc/pam.d/ contienen la configuración de PAM para diferentes servicios y aplicaciones. Por ejemplo, el archivo /etc/pam.d/system-auth suele configurarse para la autenticación de usuarios en todo el sistema.

Ejemplo de Configuración de PAM:

• Un fragmento típico en un archivo de configuración de PAM para usar RH IDM puede verse así:
  bash auth required pam_sss.so account required pam_sss.so password requisite pam_sss.so session optional pam_mkhomedir.so umask=0077 session required pam_sss.so
• Aquí, pam_sss.so se refiere al módulo de PAM para SSSD (System Security Services Daemon), que se utiliza para conectar con RH IDM.

Configurar NSS para el Acceso a Información de Directorios

NSS permite que el sistema del cliente busque información sobre usuarios y grupos en RH IDM.

• Archivo de Configuración NSS:
  • Edita el archivo /etc/nsswitch.conf para incluir sss en las entradas relevantes como passwd, shadow, y group. Esto indica que NSS debe usar SSSD para obtener información de directorio.
  • Ejemplo:
    passwd: files sss shadow: files sss group: files sss

Instalar y Configurar SSSD

SSSD es el servicio que interactúa directamente con RH IDM. Aunque la instalación del cliente RH IDM generalmente configura SSSD, es posible que debas hacer ajustes manuales.

• Archivo de Configuración de SSSD:
  • Revisa y, si es necesario, edita el archivo /etc/sssd/sssd.conf para asegurarte de que esté correctamente configurado para tu entorno RH IDM.
  • Asegúrate de que los permisos del archivo sssd.conf sean correctos (generalmente 600) para mantener la seguridad.

• Reiniciar el Servicio SSSD:
  • Después de realizar cambios en la configuración, reinicia el servicio SSSD:
    bash systemctl restart sssd

Probar la Configuración

• Verificación:
  • Verifica que la autenticación y la obtención de información de usuario funcionen correctamente. Puedes probar esto intentando iniciar sesión con un usuario de RH IDM o utilizando comandos como getent passwd <username>.

Ejemplo práctico de conectividad de un usuario utilizando IDM

Imaginemos un escenario en el que un usuario necesita conectarse a un servidor Linux que está configurado para autenticarse a través de Red Hat Identity Manager (RH IDM). En este ejemplo, el usuario se llama «jdoe», y el servidor al que intenta acceder se llama «server01.ejemplo.com».

Paso 1: Preparación

• Usuario: «jdoe», un usuario ya existente en RH IDM.
• Servidor: «server01.ejemplo.com», un servidor Linux inscrito en RH IDM.

Paso 2: Conectarse al Servidor

Usando SSH

• Desde el Terminal del Cliente:
  • El usuario «jdoe» abre su terminal o aplicación de línea de comandos.
  • Ejecuta el siguiente comando para iniciar una sesión SSH en «server01.ejemplo.com»:
    bash ssh jdoe@server01.ejemplo.com
  • Se le pedirá a «jdoe» que ingrese su contraseña. Esta es la contraseña asociada con su cuenta de RH IDM.

• Autenticación:
  • El servidor «server01.ejemplo.com» utiliza RH IDM para verificar las credenciales de «jdoe».
  • Si la autenticación es exitosa, «jdoe» obtiene acceso al servidor.

Usando Interfaz Web (Opcional)

Si «server01.ejemplo.com» ofrece acceso a través de una interfaz web y está configurado para autenticarse mediante RH IDM:

• Abrir Navegador Web:
  • «jdoe» abre un navegador y navega a la dirección web de «server01.ejemplo.com».

• Ingreso de Credenciales:
  • En la página de inicio de sesión, «jdoe» introduce su nombre de usuario y contraseña de RH IDM.

• Acceso Concedido:
  • Tras verificar las credenciales con RH IDM, «server01.ejemplo.com» otorga acceso a «jdoe».

Paso 3: Trabajo en el Servidor

• jdoe ahora puede realizar las tareas para las que tiene permisos en el servidor. Esto puede incluir ejecutar comandos, acceder a archivos, utilizar aplicaciones, etc.

Paso 4: Cierre de Sesión

• Una vez que «jdoe» haya completado sus tareas, puede cerrar la sesión. En el caso de SSH, esto se hace simplemente con el comando exit.

¿Y si no quiero que todos los usuarios se autentifiquen con IDM, cómo los excluyo?

Estos ejemplos implicarán ajustes en el archivo de configuración de SSSD y posiblemente en la configuración de PAM.

1. Configuración de SSSD

El archivo principal de configuración para SSSD es /etc/sssd/sssd.conf. Aquí es donde definirás qué usuarios o grupos pueden autenticarse usando IDM.

Ejemplo: Restringir la autenticación a un grupo específico.

[domain/default]
...
access_provider = simple
simple_allow_groups = grupo_idm

En este ejemplo, solo los miembros del grupo grupo_idm podrán autenticarse mediante IDM. Asegúrate de reemplazar grupo_idm con el nombre del grupo real en IDM.

Si quisiéramos incluir más de un grupo, la sintaxis sería:

[domain/default]
...
access_provider = simple
simple_allow_groups = grupo_idm1,grupo_idm2,grupo_idm3

2. Configuración PAM (Pluggable Authentication Modules)

PAM se configura mediante varios archivos en el directorio /etc/pam.d/. Cada servicio tiene su propio archivo de configuración de PAM.

Ejemplo: Modificar la configuración de PAM para SSH (/etc/pam.d/sshd)

# Para permitir acceso solo a miembros de un grupo específico
auth required pam_succeed_if.so user ingroup grupo_idm

Esta línea asegura que solo los usuarios que pertenecen al grupo grupo_idm puedan autenticarse a través de SSH.

Si quisiéramos añadir más grupos:

# Permitir acceso a miembros de grupo_idm1
auth required pam_succeed_if.so user ingroup grupo_idm1

# Permitir acceso a miembros de grupo_idm2
auth required pam_succeed_if.so user ingroup grupo_idm2

# Permitir acceso a miembros de grupo_idm3
auth required pam_succeed_if.so user ingroup grupo_idm3

3. Comandos Útiles

• Verificar la configuración de SSSD: Después de modificar sssd.conf, debes reiniciar el servicio SSSD:

  sudo systemctl restart sssd

• Verificar el acceso de un usuario: Puedes usar el siguiente comando para probar si un usuario puede autenticarse:

  id nombre_de_usuario

Este comando muestra información del usuario y sus grupos, lo que puede ayudar a verificar si está configurado correctamente para usar IDM.

• Revisar registros: Si encuentras problemas, puedes revisar los registros de SSSD:

  sudo less /var/log/sssd/sssd_DOMAIN.log

Cambia DOMAIN por el nombre de tu dominio.

Notas Importantes

• Antes de hacer cualquier cambio, asegúrate de tener una copia de seguridad de los archivos de configuración.
• Estos cambios pueden afectar la manera en que los usuarios acceden al sistema, así que procede con precaución.
• Es posible que necesites ajustar estos ejemplos a tu entorno específico y a las políticas de tu organización.

Permitir que todos los usuarios se puedan autentificar con SSH pero unos utilicen IDM y otros el fichero /etc/passwd

Para configurar la autenticación SSH en un sistema Linux de manera que algunos usuarios se autentiquen a través de RedHat Identity Manager (IDM) y otros mediante el archivo /etc/passwd nativo del sistema, debes configurar PAM (Pluggable Authentication Modules) y posiblemente ajustar la configuración de SSSD.

Aquí hay un enfoque para lograr esto:

Configuración de PAM para SSH

El archivo de configuración de PAM para SSH generalmente se encuentra en /etc/pam.d/sshd. Necesitarás ajustarlo para soportar ambos métodos de autenticación.

1. Permitir la Autenticación Local y de IDM:

• Asegúrate de que la configuración de PAM permita la autenticación tanto a través del IDM como del sistema local.
• Esto generalmente se logra mediante la inclusión de módulos de autenticación estándar, como pam_unix.so para la autenticación local y pam_sss.so para la autenticación a través de SSSD (que se comunica con IDM).

1. Ejemplo de Configuración PAM:

   # Autenticación estándar con /etc/passwd
   auth sufficient pam_unix.so nullok try_first_pass

   # Autenticación a través de SSSD (IDM)
   auth sufficient pam_sss.so use_first_pass

En esta configuración, sufficient significa que si una de las líneas tiene éxito en la autenticación, no se requerirán las siguientes.

Configuración de SSSD

Si aún no lo has hecho, asegúrate de que SSSD esté configurado para autenticar a través de IDM.

1. Archivo de Configuración de SSSD (/etc/sssd/sssd.conf):

• Configura el dominio y los parámetros de autenticación según tus requisitos de IDM.

1. Reiniciar SSSD:

• Después de cualquier cambio en la configuración de SSSD, debes reiniciar el servicio: sudo systemctl restart sssd

Ubicación y Mantenimiento de los LOGS de IDM

Red Hat Identity Manager guarda sus registros (logs) en varias ubicaciones. Los logs son esenciales para el monitoreo, la auditoría y la resolución de problemas en cualquier entorno de servidor:

1. Directory Server Logs: Normalmente, se encuentran en /var/log/dirsrv/slapd-INSTANCE/, donde INSTANCE es el nombre de la instancia de tu servidor de directorio. Dentro de este directorio, encontrarás varios tipos de archivos de log, como access, errors, audit.
2. Kerberos Logs: Si Red Hat Identity Manager está configurado para utilizar Kerberos para la autenticación, los logs de Kerberos generalmente se encuentran en /var/log/krb5kdc.log.
3. Certificados y PKI Logs: Estos suelen ubicarse en /var/log/pki/pki-tomcat, especialmente si estás utilizando un subsistema de PKI integrado.

Para el mantenimiento de los logs podemo implementar una política de logrotate como la siguiente:

/var/log/dirsrv/slapd-INSTANCE/*.log {
    daily
    rotate 10
    compress
    missingok
    notifempty
    create 0600 dirsrv dirsrv
    postrotate
        /bin/systemctl reload dirsrv@INSTANCE.service > /dev/null 2>/dev/null || true
    endscript
}

En este ejemplo:

• daily: Rota los logs diariamente.
• rotate 10: Guarda 10 archivos de log antiguos antes de eliminarlos.
• compress: Comprime los archivos de log rotados.
• missingok: No lanza un error si el archivo de log no existe.
• notifempty: No rota el log si está vacío.
• create 0600 dirsrv dirsrv: Crea un nuevo archivo de log con los permisos y propietario especificados.
• postrotate/endscript: Recarga el servicio después de la rotación para asegurar que los logs se escriban en el nuevo archivo.

Es importante ajustar estos parámetros según las necesidades específicas de cada entorno.

Configuración de un cluster activo-activo de RedHat IDM

Configurar un entorno de alta disponibilidad (HA) para Red Hat Identity Management (IDM) con un clúster activo-activo y balanceadores de carga es una tarea avanzada y compleja. Veamos un ejemplo de una posible configuración:

Preparación del Entorno

1. Instalación de IDM en el Nodo Primario:

• Instala IDM en el primer servidor (nodo1).
  bash ipa-server-install --setup-dns --setup-ca --hostname=node1.example.com --realm=EXAMPLE.COM --domain=example.com

1. ipa-server-install: Este es el comando principal que inicia la instalación y configuración de un servidor IDM/FreeIPA.
2. –setup-dns: Esta opción indica que el servidor de nombres de dominio (DNS) debe ser instalado y configurado junto con el servidor IDM. El DNS es crucial para la localización de servicios y la resolución de nombres dentro de la red. Al configurar el DNS, el servidor IDM puede gestionar automáticamente los registros DNS necesarios para sus servicios.
3. –setup-ca: Este parámetro indica que se debe configurar una Autoridad de Certificación (CA) en el servidor. La CA es responsable de emitir y gestionar certificados de seguridad. Estos certificados son utilizados para la autenticación segura y la comunicación encriptada dentro del dominio IDM.
4. –hostname=node1.example.com: Especifica el nombre de host completamente calificado (FQDN) del servidor IDM que se está instalando. En este caso, es node1.example.com. Es importante que este nombre de host esté correctamente configurado en el sistema y en el DNS.
5. –realm=EXAMPLE.COM: Define el nombre del realm Kerberos para la instalación. En Kerberos, un realm es un dominio de autenticación, similar a un dominio DNS pero utilizado para propósitos de autenticación segura. Aquí, el realm se establece como EXAMPLE.COM.
6. –domain=example.com: Este parámetro establece el nombre del dominio DNS que el servidor IDM gestionará. En este ejemplo, el dominio es example.com. Este parámetro es importante porque define el ámbito en el que el servidor IDM operará y gestionará los registros DNS y la información de autenticación.

• Instala IDM en el segundo servidor (nodo2) como una réplica.
  bash ipa-replica-install --setup-ca --setup-dns --hostname=node2.example.com --principal=admin@EXAMPLE.COM

1. ipa-replica-install: Este es el comando principal utilizado para iniciar la instalación de una réplica IDM.
2. –setup-ca: Esta opción indica que se debe configurar una Autoridad de Certificación (CA) en la réplica. Una CA es responsable de emitir y gestionar certificados de seguridad. Al incluir esta opción, la réplica será capaz de emitir y manejar certificados de forma independiente, lo cual es importante para la seguridad y la autenticación dentro del dominio IDM.
3. –setup-dns: Este parámetro indica que el servicio de DNS (Sistema de Nombres de Dominio) debe ser configurado en la réplica. IDM utiliza DNS para localizar servicios y para la resolución de nombres en la red. Al configurar DNS en la réplica, se asegura que la resolución de nombres y los servicios relacionados con DNS sean altamente disponibles y redundantes.
4. –hostname=node2.example.com: Especifica el nombre de host completamente calificado (FQDN) de la réplica que se está instalando. En este caso, el FQDN es node2.example.com. Es crucial que este nombre de host se haya configurado correctamente en el sistema y en DNS antes de ejecutar este comando.
5. –principal=admin@EXAMPLE.COM: Indica la cuenta de usuario principal (en este caso, admin) que se utilizará para realizar la instalación. Este usuario debe tener privilegios administrativos en el sistema IDM. El @EXAMPLE.COM es el dominio Kerberos asociado con la instalación de IDM. Esta cuenta se utilizará para autenticarse en el sistema IDM existente y obtener la información necesaria para configurar la réplica.

Configuración de Réplica

2. Verificación de la Réplica:

• En cada nodo, verifica la replicación:
  bash ipa-replica-manage list

Configuración del Balanceador de Carga

No hay que configurar ningún balanceador de carga a nivel de comunicacones. Lo que hay que hacer es configurar el cliente de IDM para que apunte a todos los servidores de IDM. Lo veremos a continuación en el procedimiento de montaje de un servidor de IDM con alta disponibilidad.

Prueba piloto – Montaje de un servidor y un cliente de IDM

Ahora que ya hemos visto toda la teoría, es hora de montar un proyecto piloto con Identity Manager. La estructura del proyecto va a ser la siguiente:

• Dominio/REALM: idmtest.local
• 192.168.85.137 idmsrv01.idmtest.local: Es el servidor de IDM
• 192.168.85.139 idmclntdns01.idmtest.local: Contiene el servidor DNS y el cliente de IDM

El piloto está montado en servidores Linux RedHat 9.

Configuración de IPs dominio

Antes de comenzar a instalar el software de IDM, vamos a asegurarnos de que los servidores tienen IP fija y pertenecen a un dominio.

• En el fichero /etc/NetworkManager/NetworkManager.conf añadimos la dirvectiva:

[main]
dns=none

Esto es para que no se sobreescriba el fichero /etc/resolv.conf en cada reboot.

• Configuramos las IPs fijas y el default gateway:

[root@idmclntdns01 ~]# nmcli con mod ens160 ipv4.addresses 192.168.85.139/24
[root@idmclntdns01 ~]# nmcli con mod ens160 ipv4.gateway 192.168.85.2
[root@idmclntdns01 ~]# nmcli con mod ens160 ipv4.method manual

• Configuramos el hostname con el dominio incluido:

[root@idmclntdns01 ~]# cat /etc/sysconfig/network
HOSTNAME=idmclntdns01.idmtest.local
GATEWAY=192.168.85.2
[root@idmclntdns01 ~]# 

[root@idmclntdns01 ~]# grep idm /etc/hosts
192.168.85.139 idmclntdns01.idmtest.local idmclntdns01
[root@idmclntdns01 ~]# 

• Configuramos el DNS por defecto para que apunte al default gateway:

[root@idmclntdns01 ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.85.2
[root@idmclntdns01 ~]# 

Repetimos los mismos pasos con el servidor idmsrv01 pero modificando la IP.

Instalación del servidor de DNS

IDM requiere que todos los servidores tengan un domino y para ello utiliza un servidor de DNS. Así que vamos a configurar el servicio named.

• Creamos la zona en el fichero /etc/named.conf

zone "idmtest.local" IN {
        type master;
        file forward.idmtestlocal.db;
        allow-update { none; };
};

• Configuramos los nombres de DNS para esa zona:

En el fichero /etc/named.conf definimos la zona:
zone "idmtest.local" IN {
	type master;
	file "forward.idmtestlocal.db";
	allow-update { none; };
};


y los DNSs de Google para resolver dominios de Internet:

forwarders {
        8.8.8.8;
        1.1.1.1;
    };


###################


[root@idmclntdns01 ~]# cat /etc/named.conf 
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

acl redsegura {
        192.168.85/24;
        localhost;
        localnets;
};

options {
	listen-on port 53 { 192.168.85.139; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	secroots-file	"/var/named/data/named.secroots";
	recursing-file	"/var/named/data/named.recursing";
	allow-query     { redsegura; };

	/* 
	 - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
	 - If you are building a RECURSIVE (caching) DNS server, you need to enable 
	   recursion. 
	 - If your recursive DNS server has a public IP address, you MUST enable access 
	   control to limit queries to your legitimate users. Failing to do so will
	   cause your server to become part of large scale DNS amplification 
	   attacks. Implementing BCP38 within your network would greatly
	   reduce such attack surface 
	*/
	recursion yes;

	dnssec-validation yes;

	managed-keys-directory "/var/named/dynamic";
	geoip-directory "/usr/share/GeoIP";

	pid-file "/run/named/named.pid";
	session-keyfile "/run/named/session.key";

	forwarders {
        	8.8.8.8;
        	1.1.1.1;
    	};

	/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
	include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
	type hint;
	file "named.ca";
};

zone "idmtest.local" IN {
	type master;
	file "forward.idmtestlocal.db";
	allow-update { none; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

[root@idmclntdns01 ~]# 


###################

[root@idmclntdns01 ~]# cat /var/named/forward.idmtestlocal.db 
$TTL    604800
@       IN      SOA     idmsrv.idmtest.local. admin.idmtest.local. (
                             2023121201         ; Serial
                             604800             ; Refresh
                             86400              ; Retry
                             2419200            ; Expire
                             604800 )           ; Negative Cache TTL
;
@       IN      NS      idmsrv.idmtest.local.
@       IN      A       192.168.85.137
idmsrv01 IN     A       192.168.85.137
;idmsrv02 IN     A       192.168.85.138
idmclntdns01 IN A       192.168.85.139

; Servicio de LDAP de IDM
_ldap._tcp.idmtest.local. IN SRV 0 5 389 idmsrv01.idmtest.local.
[root@idmclntdns01 ~]# 

Una vez configurado el servidor de DNS, lo utilizaremos en todos los servidores editando el fichero /etc/resolv.conf:

[root@idmclntdns01 ~]# cat /etc/resolv.conf 
search idmtest.local
nameserver 192.168.85.139
[root@idmclntdns01 ~]# 

Instalación del servidor de IDM en el servidor idmsrv01

Ejecutaremos los comandos que ya hemos visto anteriormente:

dnf install ipa-server ipa-server-dns -y

Configuraremos el servicio de IDM:

ipa-server-install --realm=IDMTEST.LOCAL --domain=idmtest.local --ds-password=ContraseñaSecreta --admin-password=ContraseñaSecreta --unattended

La salida completa del comando es la siguiente:

[root@idmsrv01 ~]# ipa-server-install --realm=IDMTEST.LOCAL --domain=idmtest.local --ds-password=ContraseñaSecreta--admin-password=ContraseñaSecreta --unattended

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the IPA Server.
Version 4.10.2

This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the NTP client (chronyd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)
  * Configure SID generation
  * Configure the KDC to enable PKINIT

Trust is configured but no NetBIOS domain name found, setting it now.

The IPA Master Server will be configured with:
Hostname:       idmsrv01.idmtest.local
IP address(es): 192.168.85.137
Domain name:    idmtest.local
Realm name:     IDMTEST.LOCAL

The CA will be configured with:
Subject DN:   CN=Certificate Authority,O=IDMTEST.LOCAL
Subject base: O=IDMTEST.LOCAL
Chaining:     self-signed

Disabled p11-kit-proxy
Synchronizing time
No SRV records of NTP servers found and no NTP server or pool address was provided.
Using default chrony configuration.
Attempting to sync time with chronyc.
Time synchronization was successful.
Configuring directory server (dirsrv). Estimated time: 30 seconds
  [1/43]: creating directory server instance
Validate installation settings ...
Create file system structures ...
Perform SELinux labeling ...
Create database backend: dc=idmtest,dc=local ...
Perform post-installation tasks ...
  [2/43]: tune ldbm plugin
  [3/43]: adding default schema
  [4/43]: enabling memberof plugin
  [5/43]: enabling winsync plugin
  [6/43]: configure password logging
  [7/43]: configuring replication version plugin
  [8/43]: enabling IPA enrollment plugin
  [9/43]: configuring uniqueness plugin
  [10/43]: configuring uuid plugin
  [11/43]: configuring modrdn plugin
  [12/43]: configuring DNS plugin
  [13/43]: enabling entryUSN plugin
  [14/43]: configuring lockout plugin
  [15/43]: configuring graceperiod plugin
  [16/43]: configuring topology plugin
  [17/43]: creating indices
  [18/43]: enabling referential integrity plugin
  [19/43]: configuring certmap.conf
  [20/43]: configure new location for managed entries
  [21/43]: configure dirsrv ccache and keytab
  [22/43]: enabling SASL mapping fallback
  [23/43]: restarting directory server
  [24/43]: adding sasl mappings to the directory
  [25/43]: adding default layout
  [26/43]: adding delegation layout
  [27/43]: creating container for managed entries
  [28/43]: configuring user private groups
  [29/43]: configuring netgroups from hostgroups
  [30/43]: creating default Sudo bind user
  [31/43]: creating default Auto Member layout
  [32/43]: adding range check plugin
  [33/43]: creating default HBAC rule allow_all
  [34/43]: adding entries for topology management
  [35/43]: initializing group membership
  [36/43]: adding master entry
  [37/43]: initializing domain level
  [38/43]: configuring Posix uid/gid generation
  [39/43]: adding replication acis
  [40/43]: activating sidgen plugin
  [41/43]: activating extdom plugin
  [42/43]: configuring directory to start on boot
  [43/43]: restarting directory server
Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc)
  [1/11]: adding kerberos container to the directory
  [2/11]: configuring KDC
  [3/11]: initialize kerberos container
  [4/11]: adding default ACIs
  [5/11]: creating a keytab for the directory
  [6/11]: creating a keytab for the machine
  [7/11]: adding the password extension to the directory
  [8/11]: creating anonymous principal
  [9/11]: starting the KDC
  [10/11]: configuring KDC to start on boot
  [11/11]: enable PAC ticket signature support
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
  [1/2]: starting kadmin 
  [2/2]: configuring kadmin to start on boot
Done configuring kadmin.
Configuring ipa-custodia
  [1/5]: Making sure custodia container exists
  [2/5]: Generating ipa-custodia config file
  [3/5]: Generating ipa-custodia keys
  [4/5]: starting ipa-custodia 
  [5/5]: configuring ipa-custodia to start on boot
Done configuring ipa-custodia.
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
  [1/30]: configuring certificate server instance
  [2/30]: stopping certificate server instance to update CS.cfg
  [3/30]: backing up CS.cfg
  [4/30]: Add ipa-pki-wait-running
  [5/30]: secure AJP connector
  [6/30]: reindex attributes
  [7/30]: exporting Dogtag certificate store pin
  [8/30]: disabling nonces
  [9/30]: set up CRL publishing
  [10/30]: enable PKIX certificate path discovery and validation
  [11/30]: authorizing RA to modify profiles
  [12/30]: authorizing RA to manage lightweight CAs
  [13/30]: Ensure lightweight CAs container exists
  [14/30]: Ensuring backward compatibility
  [15/30]: starting certificate server instance
  [16/30]: configure certmonger for renewals
  [17/30]: requesting RA certificate from CA
  [18/30]: publishing the CA certificate
  [19/30]: adding RA agent as a trusted user
  [20/30]: configure certificate renewals
  [21/30]: Configure HTTP to proxy connections
  [22/30]: updating IPA configuration
  [23/30]: enabling CA instance
  [24/30]: importing IPA certificate profiles
  [25/30]: migrating certificate profiles to LDAP
  [26/30]: adding default CA ACL
  [27/30]: adding 'ipa' CA entry
  [28/30]: Recording random serial number state
  [29/30]: configuring certmonger renewal for lightweight CAs
  [30/30]: deploying ACME service
Done configuring certificate server (pki-tomcatd).
Configuring directory server (dirsrv)
  [1/3]: configuring TLS for DS instance
  [2/3]: adding CA certificate entry
  [3/3]: restarting directory server
Done configuring directory server (dirsrv).
Configuring ipa-otpd
  [1/2]: starting ipa-otpd 
  [2/2]: configuring ipa-otpd to start on boot
Done configuring ipa-otpd.
Configuring the web interface (httpd)
  [1/22]: stopping httpd
  [2/22]: backing up ssl.conf
  [3/22]: disabling nss.conf
  [4/22]: configuring mod_ssl certificate paths
  [5/22]: setting mod_ssl protocol list
  [6/22]: configuring mod_ssl log directory
  [7/22]: disabling mod_ssl OCSP
  [8/22]: adding URL rewriting rules
  [9/22]: configuring httpd
Nothing to do for configure_httpd_wsgi_conf
  [10/22]: setting up httpd keytab
  [11/22]: configuring Gssproxy
  [12/22]: setting up ssl
  [13/22]: configure certmonger for renewals
  [14/22]: publish CA cert
  [15/22]: clean up any existing httpd ccaches
  [16/22]: enable ccache sweep
  [17/22]: configuring SELinux for httpd
  [18/22]: create KDC proxy config
  [19/22]: enable KDC proxy
  [20/22]: starting httpd
  [21/22]: configuring httpd to start on boot
  [22/22]: enabling oddjobd
Done configuring the web interface (httpd).
Configuring Kerberos KDC (krb5kdc)
  [1/1]: installing X509 Certificate for PKINIT
Done configuring Kerberos KDC (krb5kdc).
Applying LDAP updates
Upgrading IPA:. Estimated time: 1 minute 30 seconds
  [1/10]: stopping directory server
  [2/10]: saving configuration
  [3/10]: disabling listeners
  [4/10]: enabling DS global lock
  [5/10]: disabling Schema Compat
  [6/10]: starting directory server
  [7/10]: upgrading server
  [8/10]: stopping directory server
  [9/10]: restoring configuration
  [10/10]: starting directory server
Done.
Restarting the KDC
Configuring SID generation
  [1/8]: adding RID bases
  [2/8]: creating samba domain object
  [3/8]: adding admin(group) SIDs
  [4/8]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [5/8]: activating sidgen task
  [6/8]: restarting Directory Server to take MS PAC and LDAP plugins changes into account
  [7/8]: adding fallback group
  [8/8]: adding SIDs to existing users and groups
This step may take considerable amount of time, please wait..
Done.
Configuring client side components
This program will set up IPA client.
Version 4.10.2

Using existing certificate '/etc/ipa/ca.crt'.
Client hostname: idmsrv01.idmtest.local
Realm: IDMTEST.LOCAL
DNS Domain: idmtest.local
IPA Server: idmsrv01.idmtest.local
BaseDN: dc=idmtest,dc=local

Configured /etc/sssd/sssd.conf
Systemwide CA database updated.
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Could not update DNS SSHFP records.
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config.d/04-ipa.conf
Configuring idmtest.local as NIS domain.
Client configuration complete.
The ipa-client-install command was successful

Please add records in this file to your DNS system: /tmp/ipa.system.records.bxjfrjou.db
==============================================================================
Setup complete

Next steps:
	1. You must make sure these network ports are open:
		TCP Ports:
		  * 80, 443: HTTP/HTTPS
		  * 389, 636: LDAP/LDAPS
		  * 88, 464: kerberos
		UDP Ports:
		  * 88, 464: kerberos
		  * 123: ntp

	2. You can now obtain a kerberos ticket using the command: 'kinit admin'
	   This ticket will allow you to use the IPA tools (e.g., ipa user-add)
	   and the web user interface.

Be sure to back up the CA certificates stored in /root/cacert.p12
These files are required to create replicas. The password for these
files is the Directory Manager password
The ipa-server-install command was successful
[root@idmsrv01 ~]# 

Comprobamos que llegamos a la consola de administración del servidor de IDM

IDM también se puede administrar en modo gráfico desde la consola de administración. Para el caso del servidor que acabamos de configurar, abriremos un navegador y accederemos a la URL: https://idmsrv01.idmtest.local/ipa/ui/

Instalación del cliente de IDM en el servidor idmclntdns01

Lo primero que tenemos que hacer es instalar el software cliente de IDM:

dnf install -y ipa-client

El siguiente paso es configurar el cliente de IDM:

ipa-client-install --server=idmsrv01.idmtest.local --domain=idmtest.local --realm=IDMTEST.LOCAL --principal=admin --password=ContraseñaSecreta --mkhomedir

La salida completa del comando es:

[root@idmclntdns01 ~]# ipa-client-install --server=idmsrv01.idmtest.local --domain=idmtest.local --realm=IDMTEST.LOCAL --principal=admin --password=ContraseñaSecreta --mkhomedir
This program will set up IPA client.
Version 4.10.2

Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes
Do you want to configure chrony with NTP server or pool address? [no]: 
Client hostname: idmclntdns01.idmtest.local
Realm: IDMTEST.LOCAL
DNS Domain: idmtest.local
IPA Server: idmsrv01.idmtest.local
BaseDN: dc=idmtest,dc=local

Continue to configure the system with these values? [no]: yes
Synchronizing time
No SRV records of NTP servers found and no NTP server or pool address was provided.
Using default chrony configuration.
Attempting to sync time with chronyc.
Time synchronization was successful.
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=IDMTEST.LOCAL
    Issuer:      CN=Certificate Authority,O=IDMTEST.LOCAL
    Valid From:  2023-12-12 07:19:47
    Valid Until: 2043-12-12 07:19:47

Enrolled in IPA realm IDMTEST.LOCAL
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Systemwide CA database updated.
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Could not update DNS SSHFP records.
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config.d/04-ipa.conf
Configuring idmtest.local as NIS domain.
Configured /etc/krb5.conf for IPA realm IDMTEST.LOCAL
Client configuration complete.
The ipa-client-install command was successful
[root@idmclntdns01 ~]# 

Creamos un usuario de pruebas

Nos conectamos al servidor de IDM desde el cliente y creamos un usuario de pruebas:

[root@idmclntdns01 ~]# kinit admin
Password for admin@IDMTEST.LOCAL: 
[root@idmclntdns01 ~]# ipa user-add dmartz --first=David --last=Martinez --password
Password: 
Enter Password again to verify: 
-------------------
Added user "dmartz"
-------------------
  User login: dmartz
  First name: David
  Last name: Martinez
  Full name: David Martinez
  Display name: David Martinez
  Initials: DM
  Home directory: /home/dmartz
  GECOS: David Martinez
  Login shell: /bin/sh
  Principal name: dmartz@IDMTEST.LOCAL
  Principal alias: dmartz@IDMTEST.LOCAL
  User password expiration: 20231212074630Z
  Email address: dmartz@idmtest.local
  UID: 1049000003
  GID: 1049000003
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True
[root@idmclntdns01 ~]# 

Validamos que el usuario no existe en la configuración local del sistema:

[root@idmclntdns01 ~]# grep dmartz /etc/passwd
[root@idmclntdns01 ~]# 

Pero podemos hacer login:

[root@idmclntdns01 ~]# id dmartz
uid=1049000003(dmartz) gid=1049000003(dmartz) groups=1049000003(dmartz)
[root@idmclntdns01 ~]# su - dmartz
Creating home directory for dmartz.
[dmartz@idmclntdns01 ~]$ pwd
/home/dmartz
[dmartz@idmclntdns01 ~]$ 

Prueba piloto – Montaje de un sevidor de IDM con alta disponibilidad

Ahora estamos en el punto en el que tenemos configurado un servidor de IDM y un cliente pero, ¿qué ocurre si cae el servidor principal de IDM? Pues que nos quedamos sin servicio. Así que vamos a configurar otro servidor de IDM que sea el backup del primero en caso de problemas.

El segundo servidor se llama idmsrv02.idmtest.local y vamos a seguir los mismos pasos de instalación que hemos seguido con el primero y lo vamos a dar de alta en el servidor de DNS.

[root@idmclntdns01 ~]# nslookup idmsrv02.idmtest.local
Server:		192.168.85.139
Address:	192.168.85.139#53

Name:	idmsrv02.idmtest.local
Address: 192.168.85.138

[root@idmclntdns01 ~]# 

Configuración de la réplica

Desde el segundo nodo (idmsrv02), ejecutamos el siguiente comando:

ipa-replica-install --principal admin --admin-password=ContraseñaSecreta --server=idmsrv01.idmtest.local --domain=idmtest.local --realm=IDMTEST.LOCAL

La salida del comando completo es:

[root@idmsrv02 ~]# ipa-replica-install --principal admin --admin-password=ContraseñaSecreta --server=idmsrv01.idmtest.local --domain=idmtest.local --realm=IDMTEST.LOCAL
Configuring client side components
This program will set up IPA client.
Version 4.10.2

Client hostname: idmsrv02.idmtest.local
Realm: IDMTEST.LOCAL
DNS Domain: idmtest.local
IPA Server: idmsrv01.idmtest.local
BaseDN: dc=idmtest,dc=local

Synchronizing time
No SRV records of NTP servers found and no NTP server or pool address was provided.
Using default chrony configuration.
Attempting to sync time with chronyc.
Time synchronization was successful.
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=IDMTEST.LOCAL
    Issuer:      CN=Certificate Authority,O=IDMTEST.LOCAL
    Valid From:  2023-12-12 07:19:47
    Valid Until: 2043-12-12 07:19:47

Enrolled in IPA realm IDMTEST.LOCAL
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Systemwide CA database updated.
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Could not update DNS SSHFP records.
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config.d/04-ipa.conf
Configuring idmtest.local as NIS domain.
Configured /etc/krb5.conf for IPA realm IDMTEST.LOCAL
Client configuration complete.
The ipa-client-install command was successful

Unable to resolve the IP address 192.168.85.137 to a host name, check /etc/hosts and DNS name resolution
Run connection check to master
Connection check OK
Disabled p11-kit-proxy
Configuring directory server (dirsrv). Estimated time: 30 seconds
  [1/40]: creating directory server instance
Validate installation settings ...
Create file system structures ...
Perform SELinux labeling ...
Create database backend: dc=idmtest,dc=local ...
Perform post-installation tasks ...
  [2/40]: tune ldbm plugin
  [3/40]: adding default schema
  [4/40]: enabling memberof plugin
  [5/40]: enabling winsync plugin
  [6/40]: configure password logging
  [7/40]: configuring replication version plugin
  [8/40]: enabling IPA enrollment plugin
  [9/40]: configuring uniqueness plugin
  [10/40]: configuring uuid plugin
  [11/40]: configuring modrdn plugin
  [12/40]: configuring DNS plugin
  [13/40]: enabling entryUSN plugin
  [14/40]: configuring lockout plugin
  [15/40]: configuring graceperiod plugin
  [16/40]: configuring topology plugin
  [17/40]: creating indices
  [18/40]: enabling referential integrity plugin
  [19/40]: configuring certmap.conf
  [20/40]: configure new location for managed entries
  [21/40]: configure dirsrv ccache and keytab
  [22/40]: enabling SASL mapping fallback
  [23/40]: restarting directory server
  [24/40]: creating DS keytab
  [25/40]: ignore time skew for initial replication
  [26/40]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 8 seconds elapsed
Update succeeded

  [27/40]: prevent time skew after initial replication
  [28/40]: adding sasl mappings to the directory
  [29/40]: updating schema
  [30/40]: setting Auto Member configuration
  [31/40]: enabling S4U2Proxy delegation
  [32/40]: initializing group membership
  [33/40]: adding master entry
  [34/40]: initializing domain level
  [35/40]: configuring Posix uid/gid generation
  [36/40]: adding replication acis
  [37/40]: activating sidgen plugin
  [38/40]: activating extdom plugin
  [39/40]: configuring directory to start on boot
  [40/40]: restarting directory server
Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc)
  [1/6]: configuring KDC
  [2/6]: adding the password extension to the directory
  [3/6]: creating anonymous principal
  [4/6]: starting the KDC
  [5/6]: configuring KDC to start on boot
  [6/6]: enable PAC ticket signature support
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
  [1/2]: starting kadmin 
  [2/2]: configuring kadmin to start on boot
Done configuring kadmin.
Configuring directory server (dirsrv)
  [1/3]: configuring TLS for DS instance
  [2/3]: importing CA certificates from LDAP
  [3/3]: restarting directory server
Done configuring directory server (dirsrv).
Configuring the web interface (httpd)
  [1/22]: stopping httpd
  [2/22]: backing up ssl.conf
  [3/22]: disabling nss.conf
  [4/22]: configuring mod_ssl certificate paths
  [5/22]: setting mod_ssl protocol list
  [6/22]: configuring mod_ssl log directory
  [7/22]: disabling mod_ssl OCSP
  [8/22]: adding URL rewriting rules
  [9/22]: configuring httpd
Nothing to do for configure_httpd_wsgi_conf
  [10/22]: setting up httpd keytab
  [11/22]: configuring Gssproxy
  [12/22]: setting up ssl
  [13/22]: configure certmonger for renewals
  [14/22]: publish CA cert
  [15/22]: clean up any existing httpd ccaches
  [16/22]: enable ccache sweep
  [17/22]: configuring SELinux for httpd
  [18/22]: create KDC proxy config
  [19/22]: enable KDC proxy
  [20/22]: starting httpd
  [21/22]: configuring httpd to start on boot
  [22/22]: enabling oddjobd
Done configuring the web interface (httpd).
Configuring ipa-otpd
  [1/2]: starting ipa-otpd 
  [2/2]: configuring ipa-otpd to start on boot
Done configuring ipa-otpd.
Custodia uses 'idmsrv01.idmtest.local' as master peer.
Configuring ipa-custodia
  [1/4]: Generating ipa-custodia config file
  [2/4]: Generating ipa-custodia keys
  [3/4]: starting ipa-custodia 
  [4/4]: configuring ipa-custodia to start on boot
Done configuring ipa-custodia.
Configuring certificate server (pki-tomcatd)
  [1/2]: configure certmonger for renewals
  [2/2]: Importing RA key
Done configuring certificate server (pki-tomcatd).
Configuring Kerberos KDC (krb5kdc)
  [1/1]: installing X509 Certificate for PKINIT
Done configuring Kerberos KDC (krb5kdc).
Applying LDAP updates
Upgrading IPA:. Estimated time: 1 minute 30 seconds
  [1/10]: stopping directory server
  [2/10]: saving configuration
  [3/10]: disabling listeners
  [4/10]: enabling DS global lock
  [5/10]: disabling Schema Compat
  [6/10]: starting directory server
  [7/10]: upgrading server
  [8/10]: stopping directory server
  [9/10]: restoring configuration
  [10/10]: starting directory server
Done.
Finalize replication settings
Restarting the KDC
Configuring SID generation
  [1/7]: adding RID bases
RID bases already set, nothing to do
  [2/7]: creating samba domain object
Samba domain object already exists
  [3/7]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [4/7]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [5/7]: activating sidgen task
  [6/7]: restarting Directory Server to take MS PAC and LDAP plugins changes into account
  [7/7]: adding fallback group
Fallback group already set, nothing to do
Done.

WARNING: The CA service is only installed on one server (idmsrv01.idmtest.local).
It is strongly recommended to install it on another server.
Run ipa-ca-install(1) on another master to accomplish this.

The ipa-replica-install command was successful
[root@idmsrv02 ~]# 

Comprobamos el estado de la réplica:

[root@idmsrv02 ~]# ipa-replica-manage list
Directory Manager password: 

idmsrv01.idmtest.local: master
idmsrv02.idmtest.local: master
[root@idmsrv02 ~]# 

Configuración del cliente de IDM para que utilice los dos servidores para la alta disponibilidad

Para que el cliente utilice los dos servidores de IDM (principal y réplica), tendremos que volver a instalarlo especificando ambos servidores:

# ipa-client-install --uninstall
# ipa-client-install --server=idmsrv01.idmtest.local --server=idmsrv02.idmtest.local --domain=idmtest.local --realm=IDMTEST.LOCAL --principal=admin --password=ContraseñaSecreta --mkhomedir --force-join

La desinstalación del cliente es obligatoria y rebotará el sistema.

La salida completa del comando es:

[root@idmclntdns01 ~]# ipa-client-install --server=idmsrv01.idmtest.local --server=idmsrv02.idmtest.local --domain=idmtest.local --realm=IDMTEST.LOCAL --principal=admin --password=ContraseñaSecreta --mkhomedir --force-join
This program will set up IPA client.
Version 4.10.2

Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes
Do you want to configure chrony with NTP server or pool address? [no]: 
Client hostname: idmclntdns01.idmtest.local
Realm: IDMTEST.LOCAL
DNS Domain: idmtest.local
IPA Server: idmsrv01.idmtest.local, idmsrv02.idmtest.local
BaseDN: dc=idmtest,dc=local

Continue to configure the system with these values? [no]: yes
Synchronizing time
No SRV records of NTP servers found and no NTP server or pool address was provided.
Using default chrony configuration.
Attempting to sync time with chronyc.
Time synchronization was successful.
Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=IDMTEST.LOCAL
    Issuer:      CN=Certificate Authority,O=IDMTEST.LOCAL
    Valid From:  2023-12-12 07:19:47
    Valid Until: 2043-12-12 07:19:47

Enrolled in IPA realm IDMTEST.LOCAL
Created /etc/ipa/default.conf
Configured /etc/sssd/sssd.conf
Systemwide CA database updated.
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Could not update DNS SSHFP records.
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config.d/04-ipa.conf
Configuring idmtest.local as NIS domain.
Configured /etc/krb5.conf for IPA realm IDMTEST.LOCAL
Client configuration complete.
The ipa-client-install command was successful
[root@idmclntdns01 ~]# 

[root@idmclntdns01 ~]# ipa config-show
  Maximum username length: 32
  Maximum hostname length: 64
  Home directory base: /home
  Default shell: /bin/sh
  Default users group: ipausers
  Default e-mail domain: idmtest.local
  Search time limit: 2
  Search size limit: 100
  User search fields: uid,givenname,sn,telephonenumber,ou,title
  Group search fields: cn,description
  Enable migration mode: False
  Certificate Subject base: O=IDMTEST.LOCAL
  Password Expiration Notification (days): 4
  Password plugin features: AllowNThash, KDC:Disable Last Success
  SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
  Default SELinux user: unconfined_u:s0-s0:c0.c1023
  Default PAC types: MS-PAC, nfs:NONE
  IPA masters: idmsrv01.idmtest.local, idmsrv02.idmtest.local
  IPA master capable of PKINIT: idmsrv01.idmtest.local, idmsrv02.idmtest.local
  IPA CA servers: idmsrv01.idmtest.local
  IPA CA renewal master: idmsrv01.idmtest.local
[root@idmclntdns01 ~]# 

Pruebas de funcionamiento de la alta disponibilidad

El primer paso es comprobar que se sigue accediendo al usuario que habíamos creado durante la instalación del piloto sin alta disponibilidad y con los dos servidores arrancados:

[root@idmclntdns01 ~]# kinit
Password for admin@IDMTEST.LOCAL: 
[root@idmclntdns01 ~]# id dmartz
uid=1049000003(dmartz) gid=1049000003(dmartz) groups=1049000003(dmartz)
[root@idmclntdns01 ~]# 

Ahora voy a parar el servidor de réplica:

[root@idmsrv02 ~]# shutdown -h now

[root@idmsrv01 ~]# ipa-replica-manage list -v idmsrv02.idmtest.local
Failed to get data from 'idmsrv02.idmtest.local': cannot connect to 'ldaps://idmsrv02.idmtest.local:636': Transport endpoint is not connected
[root@idmsrv01 ~]# 

Desde el cliente de IDM seguimos teniendo acceso al usuario de pruebas:

[root@idmclntdns01 ~]# id dmartz
uid=1049000003(dmartz) gid=1049000003(dmartz) groups=1049000003(dmartz)
[root@idmclntdns01 ~]# 

El siguiente paso es arrancar el servidor idmsrv02, parar el idmsrv01 y volver a realizar la misma comprobación. Ya os digo que funciona correctamente.

[root@idmsrv02 ~]# ipa-replica-manage list -v idmsrv01.idmtest.local
Directory Manager password: 

Failed to get data from 'idmsrv01.idmtest.local': cannot connect to 'ldaps://idmsrv01.idmtest.local:636': Transport endpoint is not connected
[root@idmsrv02 ~]# 

[root@idmclntdns01 ~]# kinit admin
Password for admin@IDMTEST.LOCAL: 
[root@idmclntdns01 ~]# id dmartz
uid=1049000003(dmartz) gid=1049000003(dmartz) groups=1049000003(dmartz)
[root@idmclntdns01 ~]#

Por lo tanto, la alta disponibilidad está funcionando correctamente.

Para finalizar, quiero hacer una última prueba, que es dar de alta un nuevo usuario de IDM, arrancar el servidor primario y comprobar que se ha sincornizado correctamente:

[root@idmsrv01 ~]# ipactl stop
Stopping ipa-otpd Service
Stopping pki-tomcatd Service
Stopping ipa-custodia Service
Stopping httpd Service
Stopping kadmin Service
Stopping krb5kdc Service
Stopping Directory Service
ipa: INFO: The ipactl command was successful
[root@idmsrv01 ~]# 

[root@idmsrv02 ~]# ipa user-add alex16 --first=Alex16 --last=Martinez --password
Password: 
Enter Password again to verify: 
-------------------
Added user "alex16"
-------------------
  User login: alex16
  First name: Alex16
  Last name: Martinez
  Full name: Alex16 Martinez
  Display name: Alex16 Martinez
  Initials: AM
  Home directory: /home/alex16
  GECOS: Alex16 Martinez
  Login shell: /bin/sh
  Principal name: alex16@IDMTEST.LOCAL
  Principal alias: alex16@IDMTEST.LOCAL
  User password expiration: 20231212102656Z
  Email address: alex16@idmtest.local
  UID: 1049100501
  GID: 1049100501
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True
[root@idmsrv02 ~]# 

[root@idmclntdns01 ~]# id alex16
uid=1049100501(alex16) gid=1049100501(alex16) groups=1049100501(alex16)
[root@idmclntdns01 ~]# 

Problemas encontrados

Al intentar dar de alta un usuario desde el servidor secundario cuando el primario estaba parado, ha surgido un problema de limitación de UIDs y no dejaba dar de alta el nuevo usuario:

[root@idmsrv02 ~]# ipa user-add alex14 --first=Alex --last=Martinez --password
Password: 
Enter Password again to verify: 
ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed.
[root@idmsrv02 ~]# 

Así que he vuelto a arrancar el primario para ajustar el número máximo de UIDs permitidos:

# Verificar la configuración actual de rangos de IDs
ldapsearch -x -D "cn=Directory Manager" -W -b "cn=distributed numeric assignment plugin,cn=plugins,cn=config"

# Ejemplo de comando para modificar el rango de IDs
ldapmodify -x -D "cn=Directory Manager" -W

# Reiniciar los servicios de IDM
ipactl restart

Luego he vuelto a parar el nodo primario para continuar con las pruebas de alta disponibilidad y ya ha funcionado correctamente.

Marcha atrás de la instalación del cliente de IDM

Supongamos que estamos en un entorno de producción donde estamos registrando en IDM un servidor que ya está prestando servicios a los usuarios. La parte de registro en IDM ha funcionado correctamente, sin emgargo, las pruebas de funcionamiento de las aplicaciones de este servidor no están yendo bien y los funcionales solicitan una marcha atrás. ¿Cómo podemos hacer la marcha atrás?

1. Desinscripción del Cliente IDM

Primero, necesitas desinscribir el cliente del servidor IDM. Esto se puede hacer con el comando ipa-client-install con la opción --uninstall. Como usuario root o con privilegios de sudo, ejecuta:

ipa-client-install --uninstall

Este comando eliminará la configuración de IDM del cliente, incluidos los certificados y la configuración de Kerberos y SSSD (System Security Services Daemon).

2. Verificación de la Configuración de Autenticación

Después de desinstalar el cliente IDM, verifica la configuración de autenticación del sistema. Dependiendo de cómo estaba configurado el sistema antes de unirse a IDM, es posible que necesites restaurar configuraciones anteriores. Esto puede incluir:

• Restaurar /etc/nsswitch.conf a su estado anterior para la resolución de nombres de usuarios y grupos.
• Reconfigurar PAM (Pluggable Authentication Modules) si se modificó para integrarse con IDM. (Ver la guía de PAM.D para su marcha atrás).

3. Restaurar los ficheros de coonfiguración de SSSD

• /etc/sssd/sssd.conf: Este es el archivo principal de configuración de SSSD. Contiene información sobre los dominios y servicios que SSSD debe manejar, incluida la integración con IDM.
• Directorio /etc/sssd/conf.d/: En algunos casos, pueden existir archivos adicionales de configuración de SSSD en este directorio.

4. Restaurar el fichero de configuración de Kerberos

/etc/krb5.conf: Este archivo es modificado para configurar el cliente Kerberos, que se utiliza para la autenticación en IDM.

5. Restaurar los ficheros de configuración de DNS

• /etc/resolv.conf: Puede modificarse para usar los servidores DNS asociados con el servidor IDM.
• /etc/hosts: A veces se actualiza con entradas relevantes para IDM.

6. Restaurar la configuración de certificados

• Directorio /etc/pki/ca-trust/source/anchors/: Se pueden agregar certificados de confianza del servidor IDM aquí.
• /etc/ipa: Este directorio contiene certificados y otros archivos relacionados con la inscripción en IDM.

7. Servicios del sistema

Archivos de systemd o init: Pueden modificarse para garantizar que los servicios relacionados con IDM se inicien en el arranque del sistema.

8. Restauración de Servicios y Aplicaciones

Si se realizaron cambios específicos en los servicios o aplicaciones para integrarlos con IDM, estos cambios también pueden necesitar ser revertidos. Esto puede incluir:

• Restablecer configuraciones específicas de la aplicación que fueron modificadas para usar la autenticación o el directorio de IDM.
• Reiniciar servicios para asegurarte de que estén utilizando la configuración actualizada.

9. Verificaciones Adicionales y Pruebas

Realiza las siguientes verificaciones:

• Asegúrate de que todos los servicios y aplicaciones estén funcionando según lo esperado.
• Comprueba que los usuarios y grupos locales se resuelven correctamente.
• Si se utilizaba Kerberos con IDM, verifica que la configuración de Kerberos haya sido removida o restaurada a su estado previo.

10. Investigación y Documentación

Mientras realizas estos pasos, es importante:

• Investigar la causa raíz del problema con la aplicación para evitar problemas similares en el futuro.
• Documentar los pasos realizados durante la reversión para futuras referencias.

11. Consideraciones de Seguridad

Finalmente, ten en cuenta las implicaciones de seguridad al deshacer la integración con IDM, especialmente si estás revirtiendo a un método de autenticación menos seguro.

Si encuentras problemas específicos durante este proceso o necesitas asistencia adicional, podría ser útil consultar la documentación oficial de Red Hat o buscar el apoyo de un profesional con experiencia en IDM y administración de sistemas Linux.

Uso de IDM como almacén de certificados SSL

Podemos utilizar RedHat IDM para almacenar todos nuestros certificados SSL. Para usarlos, simplemente nos lo descargaremos desde la consola. Veamos un ejemplo:

• Genero un certificado

[root@idmsrv01 SSL]# openssl req -new -newkey rsa:2048 -keyout idmsrv01.key -sha256 -nodes -out idmsrv01.csr
..+.+...........+....+......+........+......+.+......+..+.+......+......+...+..+....+.....+.........+.+......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.+....+.....+...+.........+...+...............+.............+.........+.........+.....+....+.....+...+....+.....+......+....+...+...+..+.......+......+...+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.........+.+...+.....+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.......+.+...+.................+.........+...+.......+...+..+.........+...................+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*...............+....+........+.........+.....................+...+.+...+..+...+......+............+....+...........+...+....+...+........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.....+..+.+..+.............+......+.........+..+....+........+.............+.........+...........+..........+...+..+..........+.....+.......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:ES
State or Province Name (full name) []:Barcelona
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:DXC
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:idmsrv01.idmtest.local
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
[root@idmsrv01 SSL]# 

[root@idmsrv01 SSL]# ls -la
total 8
drwxr-xr-x.  2 root root   46 Feb 21 10:46 .
dr-xr-xr-x. 19 root root  246 Feb 21 10:33 ..
-rw-r--r--.  1 root root 1005 Feb 21 10:46 idmsrv01.csr
-rw-------.  1 root root 1704 Feb 21 10:45 idmsrv01.key
[root@idmsrv01 SSL]# 

• Importo el fichero CSR en los servidores de IDM

[root@idmsrv01 SSL]# ipa cert-request idmsrv01.csr --principal=host/idmsrv01.idmtest.local
  Issuing CA: ipa
  Certificate: MIIEvzCCAyegAwIBAgIBDjANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKDA1JRE1URVNULkxPQ0FMMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMjQwMjIxMDk0NjUwWhcNMjYwMjIxMDk0NjUwWjA5MRYwFAYDVQQKDA1JRE1URVNULkxPQ0FMMR8wHQYDVQQDDBZpZG1zcnYwMS5pZG10ZXN0LmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6It+29r2Nq4vjaQQIVIscWAafRYnYOEcq9qyU/Ho32cb+q9gDMOYigstguwxYV+/a6qyqTNf1fQvDx5r3GRTcimp08v8S8H6JH65jj60JS0jyaQ5+p0kyH4wEd2xGV1vjCA0hUgsEL6t9LCpX2s/tXdb3vzo9p5Fq6bnzFOmYLtoRvTN4+lcPkJEHKVL/we5MwsEyq0ljCxQ+gZ4xEmhC0RrMRZCMxkailflvCUOOPHgucekZQVplsIbMTOHl7t1oqhIvZnbCvqRrIOnD1aHh7TmtLfVRSTV0VSD2+t/KeDculMyXCtztgVZlUSicLecN5sl8hgoyywcERtNdNg7eQIDAQABo4IBUTCCAU0wHwYDVR0jBBgwFoAU5Uw1c12Nzus2FXFtE/39qW0cDGcwPwYIKwYBBQUHAQEEMzAxMC8GCCsGAQUFBzABhiNodHRwOi8vaXBhLWNhLmlkbXRlc3QubG9jYWwvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMHgGA1UdHwRxMG8wbaA1oDOGMWh0dHA6Ly9pcGEtY2EuaWRtdGVzdC5sb2NhbC9pcGEvY3JsL01hc3RlckNSTC5iaW6iNKQyMDAxDjAMBgNVBAoMBWlwYWNhMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHQYDVR0OBBYEFP0Nt9/5L0Ev6/6/c0bWD9BYPSJrMCEGA1UdEQQaMBiCFmlkbXNydjAxLmlkbXRlc3QubG9jYWwwDQYJKoZIhvcNAQELBQADggGBAK/AJyz7BrAEUpob3II1K4mwYvUJgaXZ3lCv2J01TEH85LPdOWAThuyf+xQKVJA2i2ufn0OUmtV5WItTFdQXCRI43z3unSdYVg8UKCL+lpGFMJDYm43XKCK287lCRKZHhVO7UXtkLXEg3+fairrpsI0gvUfSiBvnYjaemW0DnHq2AgY89cvygX2o87H1H2yHeQ4Z1v5SxvuHw9TXfq8FO+69PAjA7RpgQ/bi6wT2mU/k8LVE0ZM0qfJGJ96MYKN+IdDHvdCAb/1uYBhsaa7fAbWDfbLPzLqE0/SnXpVmHfB8seuOgY5XnWwCbgzjXZJN4XNVgRsGmKpadQs/Ijx4Fk2J6nCfNKxPBFoU5jYivJa4ux0R0rSx//nXczjxpPcZVpEBRhzyNprtrIg8sVzi4WNPm5fNRihE7V8OCQ/kBos/Uxf0U4499Jldm9uru8CjbOEnJg3YJmYwCzGrXEYS2EsuKujogv8QHJqnZQZlvFV0VYqVWwZw++S7LjuZ2w/evw==
  Subject: CN=idmsrv01.idmtest.local,O=IDMTEST.LOCAL
  Subject DNS name: idmsrv01.idmtest.local
  Issuer: CN=Certificate Authority,O=IDMTEST.LOCAL
  Not Before: Wed Feb 21 09:46:50 2024 UTC
  Not After: Sat Feb 21 09:46:50 2026 UTC
  Serial number: 14
  Serial number (hex): 0xE
[root@idmsrv01 SSL]# 

Desde la consola de IDM podemos ver todos los certificados almacenados y descargarlos.

Más información en la documentación oficial de RedHat.

David Martínez Perales

Mi pasión por la tecnología me lleva constantemente a explorar las últimas tendencias y aplicaciones, buscando siempre formas de implementar soluciones innovadoras que mejoren la eficiencia. En puerto53.com comparto contenido valioso para ayudar a otros profesionales y entusiastas de la informática a navegar y dominar el complejo mundo de la tecnología. Mi especialidad en Linux RedHat.

Más sobre mí en el este enlace,