Adición de RHEL o cualquier otra máquina de Linux directamente a Microsoft Active Directory

La gestión del acceso a los sistemas en su red puede ser un desafío. He visto a administradores que crean cada usuario en todas las máquinas, otros que comparten cuentas mediante claves SSH o incluso contraseñas, y otros que usan enlaces de LDAP (algunas veces con la infraestructura de Active Directory actual y, otras, con un dominio separado) que los obligan a escribir consultas de LDAP para filtrar el acceso.

Todos estos métodos dificultan la gestión del acceso a las máquinas y requieren que se informe a los administradores cuando alguien se retira de un equipo o se une a él. Con las cuentas compartidas, registrarse es prácticamente inútil, ya que todos tienen el mismo nombre de usuario. Es probable que yo no sea el único que tuvo malas experiencias cuando el departamento de recursos humanos informa a los equipos técnicos los cambios en un equipo. Sin embargo, hay una solución para todo esto que funciona bien y se integra en las configuraciones empresariales comunes.

La mayoría de las empresas que he visto tienen algún tipo de sistema de planificación de recursos empresariales (ERP) que crea, deshabilita o elimina de manera automática las cuentas de usuario en Microsoft Active Directory (AD), de manera que se pueda aprovechar el trabajo que hacen otras personas. Por ejemplo, SSSD puede conectarse directamente a AD.

Si alguna vez configuró un servidor de autenticación para Linux que tenía una relación de confianza con AD, SSSD se comunicó con sus servidores de AD. Observe el funcionamiento de una relación de confianza: el servidor de autenticación que configuró devuelve una referencia a los servidores de AD, lo que hace que SSSD consulte sus servidores de AD directamente. En la configuración que sigue, se omite la necesidad de tener un servidor de autenticación adicional y se configura SSSD para que vaya directamente a AD primero.

A continuación, debe resolverse la manera de controlar el acceso. Aquí es donde entra en acción el control de acceso basado en funciones (RBAC), que permite que deje de asignar el acceso a los usuarios y comience a asignarlo a las funciones. Una vez que establezca los grupos, podrá asignar un nuevo miembro a un equipo, que ya formará parte de la función con acceso adecuado a un grupo de servidores. Además, RBAC elimina las solicitudes de tipo "Me acaban de contratar y necesito el mismo acceso que X", las cuales toman como referencia a una persona que se fue de la empresa hace meses y cuyo acceso se eliminó por completo.

En lugar de eso, una vez que agrega el nuevo usuario al grupo de su equipo, obtiene el acceso que necesita. También se evita que alguien que dejó la empresa hace más de un año todavía pueda acceder a todos los servidores porque nadie informó a los administradores de su partida. Esto no sucede con RBAC, debido a que cuando el sistema de ERP actualiza su cuenta de AD de forma automática, la persona pierde el acceso por completo.

Antes, la gestión de AD desde sistemas operativos que no fueran Windows implicaba todo un desafío. Sin embargo, Microsoft lanzó Windows Admin Center, que permite que acceda a Active Directory Users and Computers directamente desde todo explorador que se ejecute en cualquier sistema operativo. También otorga acceso a varias otras herramientas de gestión de Windows. Cuando lo instala en un servidor de Windows, no tiene que preocuparse por los límites de sesión ni por los problemas con RemoteApp. Simplemente inicia un explorador y accede a la interfaz web.

Configure sus grupos de AD para el control de acceso basado en funciones

El esquema de nombres de su empresa puede diferir de los ejemplos de este artículo. De todas maneras, lo que importa no son los nombres de los grupos, sino el uso previsto de cada grupo.

Dado que SSSD no sincroniza los grupos de AD, sino que solo obtiene una lista de aquellos de los que el usuario es miembro durante el proceso de inicio de sesión, los grupos faltantes no impiden que esta configuración funcione. Sin embargo, si tiene varios equipos con permisos delegados dentro de AD, se recomienda crear todos los grupos para evitar que se establezcan en la unidad organizativa (OU) incorrecta y le otorguen control sobre el acceso al equipo equivocado.

Acceso a máquinas específicas

Cree dos grupos dentro de Active Directory para cada máquina. Ambos grupos deben incluir el nombre corto de la máquina. 

Un grupo es para el acceso SSH específico de la máquina (denominado Machine_SSH_Access en el resto del artículo).

El otro proporciona acceso sudo específico de la máquina (denominado Machine_SUDO_Access en el resto del artículo).

Ejemplos de formatos de grupo:

<DOMAIN> Linux <hostname> ssh access
<DOMAIN> Linux <hostname> sudo access

• <hostname>es el nombre corto de la máquina.
• <DOMAIN>es el nombre corto de su dominio y es opcional.

Acceso a todas las máquinas

Cree dos grupos dentro de Active Directory para el acceso global a las máquinas.

Uno de los grupos será para el acceso SSH a todas las máquinas (denominado Global_SSH_Access en el resto del artículo).

El otro será para el acceso sudo a todas las máquinas (denominado Global_SUDO_Access en el resto del artículo).

Ejemplos de formatos de grupo:

<DOMAIN> Linux ssh access
<DOMAIN> Linux sudo access

<DOMAIN>es el nombre corto de su dominio y es opcional.

Anidamiento

El anidamiento dentro de los grupos de AD se encuentra permitido. Para crear un grupo con acceso a varias máquinas, no necesita cambiar la configuración de las máquinas de RHEL, sino que puede hacer que el nuevo grupo sea miembro de aquel con acceso a las máquinas específicas. Este enfoque le permite controlar el acceso directamente desde AD.

Ejemplo de anidamiento:

• CONTOSO Linux Webserver1 ssh access
  • CONTOSO Linux Webservers ssh access
    • CONTOSO Web Developers
      • Usuario1
      • Usuario2

Este anidamiento le permite asignar funciones (CONTOSO Web Developers) a los grupos de máquinas (CONTOSO Linux Webservers ssh access) en lugar de usuarios a los sistemas específicos.

Adición de la máquina de Linux a un dominio

Si su entorno tiene RC4 habilitado actualmente, siga el aviso de seguridad de Microsoft y desactívelo ahora.

Para agregar una máquina de Linux a un dominio:

1. Instale los paquetes requeridos:

$ sudo dnf install -y chrony krb5-workstation \
samba-common-tools oddjob-mkhomedir samba-common \
sssd authselect

2. Para agregar la cadena de autoridad de certificación (CA) de su dominio, cree /etc/sssd/pki/sssd_auth_ca_db.pem y escríbala. No necesita incluir el certificado para los controladores de dominio (DC) en sí mismos, sino que puede comenzar con aquel que firmó los certificados de estos.
3. Agregue la cadena de CA a los anclajes de confianza del sistema:

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

4. Configure SSSD editando /etc/sssd/sssd.conf o /etc/sssd/conf.d/<DOMAIN>.conf y haga coincidir las siguientes líneas.

La edición de /etc/sssd/conf.d/<DOMAIN>.conf es el método moderno que se prefiere, pero la edición de /etc/sssd/sssd.conf también funciona.

[domain/<DOMAIN>]
access_provider = simple
auth_provider = ad
chpass_provider = ad
id_provider = ad
dyndns_update = true
override_homedir = /home/%u
override_shell = /bin/bash
default_shell = /bin/bash
ldap_idmap_range_size = 4000000
cache_credentials = true
simple_allow_groups = Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access, Machine_SUDO_Access
ignore_group_members = true
ad_gpo_access_control = disabled
ad_enable_gc = false
ad_use_ldaps = true
[sssd]
services = nss, pam
config_file_version = 2
domains = <DOMAIN>

• <DOMAIN>es el nombre completamente calificado de su dominio (FQDN) en MAYÚSCULAS. Si no escribe todo en mayúsculas, pueden producirse problemas de autenticación.
• ldap_idmap_range_size es opcional. Resulta necesario si tiene un entorno de AD de gran tamaño. Si cambia este valor, el hash del UID también lo hará, de manera que no debe modificarlo una vez que la máquina esté unida al dominio y debe asegurarse de usar el mismo valor en todas las máquinas.
• Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access y Machine_SUDO_Access son los grupos de AD que creó anteriormente para el RBAC.

5. Establezca los permisos para el archivo que acaba de escribir: /etc/sssd/sssd.conf o /etc/sssd/conf.d/<DOMAIN>.conf:

$ sudo chmod 400 /etc/sssd/sssd.conf

o

$ sudo chmod 400 /etc/sssd/conf.d/*.conf

6. Configure KRB5 editando /etc/krb5.conf y haga coincidir estas líneas:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = true
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = <DOMAIN>
[realms]
[domain_realm]

No necesita especificar nada en [realms] ni [domain_realm]. SSSD obtiene esa información automáticamente desde el DNS.

7. Configure el acceso SUDO mediante la creación de un archivo en /etc/sudoers.d:

$ sudo visudo -f /etc/sudoers.d/<DOMAIN>

Especifique el acceso sudo predeterminado para los miembros de los grupos sudo de AD. El nombre del archivo puede ser el que desee; no es necesario que sea DOMAIN.

Debe escapar cualquier espacio con una barra invertida (\). Por ejemplo, "Linux sudo access" debe escribirse "Linux\ sudo\ access".

%Global_SUDO_Access  ALL=(ALL) ALL
%Machine_SUDO_Access  ALL=(ALL) ALL

Global_SUDO_Access y Machine_SUDO_Access son los grupos de AD que creó para el RBAC. El signo de porcentaje (%) antes del nombre del grupo indica que se trata de un grupo.

Cualquier otro acceso sudo que desee otorgar a los grupos de AD se puede definir de igual modo en el mismo archivo o en otros separados.

8. Asegúrese de que el nombre de host de la máquina esté establecido en el nombre de dominio completamente calificado (FQDN). El nombre de host de la máquina no puede ser el nombre corto:

$ sudo hostnamectl set-hostname $(hostname -f)

9. Una la máquina con alguno de los siguientes comandos (adcli es compatible con SMBv1 y SMBv2). Para configurar la información del sistema operativo dentro de AD durante la unión, use el siguiente comando:

$ source /etc/os-release
$ sudo adcli join -U <join_user> --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

También puede llevar a cabo la unión sin configurar la información del sistema operativo:

$ sudo adcli join -U <join_user>

<join_user> es la cuenta de AD que se usará para agregar la máquina al dominio. La contraseña que solicita adcli no se almacena. Los permisos delegados describen los permisos que se requieren para efectuar la unión.

10. Habilite e inicie SSSD y oddjobd:

$ sudo systemctl enable sssd oddjobd
$ sudo systemctl restart sssd oddjobd

11. Habilite el inicio de sesión con AD:

$ sudo authselect select sssd with-mkhomedir --force

Si su cuenta pertenece a alguno de los grupos que creó, ahora podrá iniciar sesión en la máquina. No necesita especificar el dominio. Se usa el dominio especificado como default_realm en /etc/krb5.conf. GNOME puede requerir el reinicio del sistema, pero generalmente sshd acepta los cambios sin necesidad de ello.

Mantenga actualizada la información del sistema operativo

De manera predeterminada, el objeto de la computadora no tiene permiso para actualizar su propia información del sistema operativo. Asegúrese de ingresar a Active Directory Users and Computers (ADUAC) y otorgar a SELF la capacidad de escribir cada uno de los campos del sistema operativo en los objetos de la computadora (puede hacerlo en el nivel de la unidad organizativa). Una vez agregado, actualice el objeto de AD con la información más reciente del sistema operativo:

$ source /etc/os-release
$ sudo /usr/sbin/adcli update --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

Esto se puede agregar como un trabajo cron o como un servicio systemd. Por ejemplo:

[Unit]
Description=Updates AD with current OS information
After=sssd.service
[Service]
Type=oneshot
EnvironmentFile=/etc/os-release
ExecStart=/usr/sbin/adcli update --os-name="${NAME}" --os-version="${VERSION}" --os-service-pack="${VERSION_ID}"
[Install]
WantedBy=multi-user.target

Habilite la autenticación con tarjeta inteligente

En esta sección, se supone que la autenticación con tarjeta inteligente ya funciona en sus máquinas de Windows. Si no es así, configúrela antes de continuar.

1. Escriba la cadena de certificados para su dominio en /etc/sssd/pki/sssd_auth_ca_db.pem. No necesita incluir el certificado para los controladores de dominio (DC) en sí mismos, sino que puede comenzar con aquel que firmó los certificados de estos.
2. Agregue el certificado a la lista de CA de confianza de la máquina:

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

3. Edite /etc/sssd/sssd.conf o /etc/sssd/conf.d/<DOMAIN>.conf, dependiendo del archivo que utilizó cuando su dominio se unió al sistema, y agregue la siguiente línea dentro de la sección [domain/<DOMAIN>]. Esta entrada le indica a SSSD la ubicación donde debe buscar el certificado de usuario. Windows usa el atributo userCertificate, de modo que si usamos el mismo atributo, una única tarjeta inteligente funciona tanto en Linux como en Windows.

ldap_user_certificate = userCertificate;binary

Agregue estas líneas al final del mismo archivo de configuración:

[pam]
pam_cert_auth = true

4. Edite /etc/krb5.conf y agregue las siguientes líneas en [realms] remplazando <DOMAIN>por el FQDN de su dominio TODO EN MAYÚSCULAS. Esto sirve para resolver una falta de coincidencia que puede ocurrir porque Windows no distingue entre mayúsculas y minúsculas, mientras que Linux sí lo hace.

<DOMAIN> = {
pkinit_anchors = DIR:/etc/sssd/pki
  pkinit_kdc_hostname = <DOMAIN>
}

5. Use uno de los siguientes comandos para habilitar la autenticación con tarjeta inteligente en el módulo de autenticación conectable (PAM):

• authselect enable-feature with-smartcard: permite la autenticación con tarjeta inteligente como opción.
• authselect enable-feature with-smartcard-required: requiere la autenticación con tarjeta inteligente. De manera predeterminada, sshd no llama a PAM cuando la autenticación se realiza con claves SSH.
• authselect enable-feature with-smartcard-lock-on-removal: requiere autenticación con tarjeta inteligente y bloquea la máquina cuando se extrae la tarjeta.

Habilite el acceso SSH con el certificado de tarjeta inteligente

En RHEL 8 y versiones posteriores, puede habilitar el acceso SSH con una tarjeta inteligente.

1. Compruebe que el certificado de la tarjeta inteligente se lea correctamente desde AD:

sss_ssh_authorizedkeys ${USER}

Si no se devuelve una clave pública, compruebe que la autenticación con tarjeta inteligente esté configurada correctamente.

2. Edite /etc/ssh/sshd_config para agregar estas líneas:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

3. Reinicie sshd:

$ sudo systemctl restart sshd

Para iniciar sesión desde un cliente mediante SSH, use la opción PKCS11Provider=/usr/lib64/opensc-pkcs11.so. Si la tarjeta inteligente coincide con una clave pública para el usuario, se le solicitará el PIN o la contraseña de la tarjeta:

$ ssh -o PKCS11Provider=/usr/lib64/opensc-pkcs11.so <host>

Información adicional

Ahora tiene una máquina que está unida a un dominio y cuenta con control de acceso basado en funciones sobre quién puede iniciar sesión o ejecutar comandos con privilegios. La gestión se simplifica rápidamente porque puede aprovechar el trabajo que llevan a cabo otras personas. Estos son algunos aspectos que debe tener en cuenta:

• La deshabilitación de un usuario dentro de AD bloquea inmediatamente su acceso a la máquina. Al igual que con Windows, cualquier persona que ya inició sesión permanecerá conectada.
• La modificación de los grupos del usuario se actualiza durante el inicio de sesión, tal como sucede en Windows. Esto se hace antes de comprobar si tienen permiso para iniciar sesión.
• SSSD reconoce los sitios. Si los configura dentro de AD Sites and Services, SSSD se conectará al DC adecuado.
• SSSD rota la contraseña de la máquina de manera automática.
• SSSD crea y gestiona automáticamente los registros del DNS de una máquina si las actualizaciones dinámicas (seguras o no seguras) se encuentran habilitadas.

Por lo general, desaconsejo el uso de herramientas de Windows para gestionar sistemas Linux, y viceversa, porque suelen perderse funciones importantes, pueden generarse fallos de seguridad o existen formas mucho más sencillas de realizar la misma tarea con una herramienta propia de cada uno de ellos. Sin embargo, con AD es diferente. Los desarrolladores de SSSD han trabajado mucho para que sea compatible con AD, lo cual facilita aún más su trabajo.