Integrar NIS con Active Directory
Este artículo describe cómo integrar NIS con Windows Active Directory (AD) en el VDA de Linux mediante SSSD. El VDA de Linux se considera un componente de Citrix Virtual Apps and Desktops. Como resultado, se integra perfectamente en el entorno de AD de Windows.
Usar NIS en lugar de AD como proveedor de UID y GID requiere que la información de la cuenta (combinaciones de nombre de usuario y contraseña) sea la misma en AD y NIS.
Nota:
La autenticación sigue siendo realizada por el servidor de AD. NIS+ no es compatible. Si usas NIS como proveedor de UID y GID, los atributos POSIX del servidor de Windows ya no se utilizan.
Sugerencia:
Este método representa una forma obsoleta de implementar el VDA de Linux, que se utiliza solo para casos de uso especiales. Para una distribución RHEL, sigue las instrucciones en Instalar el VDA de Linux en RHEL y Rocky Linux manualmente. Para una distribución Ubuntu, sigue las instrucciones en Instalar el VDA de Linux en Ubuntu manualmente.
¿Qué es SSSD?
SSSD es un demonio del sistema. Su función principal es proporcionar acceso para identificar y autenticar recursos remotos a través de un marco común que puede ofrecer almacenamiento en caché y soporte sin conexión para el sistema. Proporciona módulos PAM y NSS, y en el futuro podrá admitir interfaces basadas en D-BUS para información de usuario extendida. También proporciona una base de datos mejor para almacenar cuentas de usuario locales y datos de usuario extendidos.
Integrar NIS con AD
Para integrar NIS con AD, completa los siguientes pasos:
Paso 1: Agregar el VDA de Linux como cliente NIS
Configura el cliente NIS:
yum –y install ypbind rpcbind oddjob-mkhomedir
<!--NeedCopy-->
Establece el dominio NIS:
ypdomainname nis.domain
echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network
<!--NeedCopy-->
Agrega la dirección IP del servidor y cliente NIS en /etc/hosts:
{NIS server IP address} server.nis.domain nis.domain
Configura NIS mediante authconfig:
sudo authconfig --enablenis --nisdomain=nis.domain --nisserver=server.nis.domain --enablemkhomedir --update
<!--NeedCopy-->
nis.domain representa el nombre de dominio del servidor NIS. server.nis.domain es el nombre de host del servidor NIS, que también puede ser la dirección IP del servidor NIS.
- Configura los servicios NIS:
- sudo systemctl start rpcbind ypbind
sudo systemctl enable rpcbind ypbind
<!--NeedCopy-->
- Asegúrate de que la configuración de NIS sea correcta:
ypwhich
<!--NeedCopy-->
Valida que la información de la cuenta esté disponible desde el servidor NIS:
getent passwd nisaccount
<!--NeedCopy-->
Nota:
nisaccount representa la cuenta NIS real en el servidor NIS. Asegúrate de que el UID, GID, el directorio de inicio y el shell de inicio de sesión estén configurados correctamente.
Paso 2: Unir el dominio y crear un keytab de host usando Samba
SSSD no proporciona funciones de cliente de AD para unir el dominio y administrar el archivo keytab del sistema. Hay varios métodos para lograr estas funciones, entre ellos:
adclirealmdWinbindSamba
La información de esta sección describe únicamente el enfoque de Samba. Para realmd, consulta la documentación del proveedor de RHEL o CentOS. Estos pasos deben seguirse antes de configurar SSSD.
Unir el dominio y crear un keytab de host usando Samba:
En el cliente Linux con los archivos configurados correctamente:
- /etc/krb5.conf
- /etc/samba/smb.conf:
Configura la máquina para la autenticación de Samba y Kerberos:
sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
<!--NeedCopy-->
Donde REALM es el nombre del reino Kerberos en mayúsculas y domain es el nombre NetBIOS del dominio.
Si se requiere la búsqueda basada en DNS del servidor KDC y el nombre del reino, agrega las dos opciones siguientes al comando anterior:
--enablekrb5kdcdns --enablekrb5realmdns
Abre /etc/samba/smb.conf y agrega las siguientes entradas en la sección [Global], pero después de la sección generada por la herramienta authconfig:
kerberos method = secrets and keytab
winbind offline logon = no
Unirse al dominio de Windows requiere que tu controlador de dominio sea accesible y que tengas una cuenta de usuario de AD con permisos para agregar equipos al dominio:
sudo net ads join REALM -U user
<!--NeedCopy-->
REALM es el nombre del reino Kerberos en mayúsculas y user es un usuario de dominio que tiene permisos para agregar equipos al dominio.
Paso 3: Configurar SSSD
Nota
Usar SSSD con el demonio de caché del servicio de nombres (NSCD) puede provocar un comportamiento inesperado. Para obtener más información, consulta Using NSCD with SSSD.
La configuración de SSSD consta de los siguientes pasos:
- Instala los paquetes sssd-ad y sssd-proxy en la máquina cliente Linux.
- Realiza cambios de configuración en varios archivos (por ejemplo, sssd.conf).
- Inicia el servicio sssd.
/etc/sssd/sssd.conf
Un ejemplo de configuración de sssd.conf (se pueden agregar más opciones según sea necesario):
[sssd]
config_file_version = 2
domains = EXAMPLE
services = nss, pam
[domain/EXAMPLE]
# Uncomment if you need offline logins
# cache_credentials = true
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
id_provider = proxy
proxy_lib_name = nis
auth_provider = ad
access_provider = ad
- # Should be specified as the long version of the Active Directory domain.
- ad_domain = EXAMPLE.COM
# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# Uncomment if service discovery is not working
# ad_server = server.ad.example.com
# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
<!--NeedCopy-->
Reemplaza ad.domain.com, server.ad.example.com con el valor correspondiente. Para obtener más detalles, consulta la página man de Linux de sssd-ad(5).
Establece la propiedad y los permisos del archivo en sssd.conf:
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
Paso 4: Configurar NSS/PAM
RHEL/CentOS:
Usa authconfig para habilitar SSSD. Instala oddjob-mkhomedir para asegurarte de que la creación del directorio de inicio sea compatible con SELinux:
authconfig --enablesssd --enablesssdauth --enablemkhomedir --update
sudo systemctl start sssd
sudo systemctl enable sssd
<!--NeedCopy-->
Sugerencia:
Al configurar los ajustes del VDA de Linux, ten en cuenta que para SSSD no hay ajustes especiales para el cliente VDA de Linux. Para soluciones adicionales en el script ctxsetup.sh, usa el valor predeterminado.
Paso 5: Verificar la configuración de Kerberos
Para asegurarte de que Kerberos esté configurado correctamente para su uso con el VDA de Linux, verifica que el archivo keytab del sistema se haya creado y contenga claves válidas:
sudo klist -ke
<!--NeedCopy-->
Este comando muestra la lista de claves disponibles para las diversas combinaciones de nombres principales y conjuntos de cifrado. Ejecuta el comando Kerberos kinit para autenticar la máquina con el controlador de dominio usando estas claves:
sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->
Los nombres de la máquina y del reino deben especificarse en mayúsculas. El signo de dólar ($) debe escaparse con una barra invertida (\) para evitar la sustitución del shell. En algunos entornos, el nombre de dominio DNS es diferente del nombre del reino Kerberos. Asegúrate de que se utilice el nombre del reino. Si este comando se ejecuta correctamente, no se muestra ninguna salida.
Verifica que el ticket TGT para la cuenta de la máquina se haya almacenado en caché usando:
sudo klist -ke
<!--NeedCopy-->
Paso 6: Verificar la autenticación de usuario
Usa el comando getent para verificar que el formato de inicio de sesión sea compatible y si el NSS funciona:
sudo getent passwd DOMAIN\\username
<!--NeedCopy-->
El parámetro DOMAIN indica el nombre de dominio en versión corta. Si se necesita otro formato de inicio de sesión, verifica primero usando el comando getent.
Los formatos de inicio de sesión compatibles son:
- Nombre de inicio de sesión de nivel inferior:
DOMAIN\username - UPN:
username@domain.com - Formato de sufijo NetBIOS:
username@DOMAIN
Para verificar que el módulo PAM de SSSD esté configurado correctamente, usa una cuenta de usuario de dominio para iniciar sesión en el VDA de Linux. La cuenta de usuario de dominio no se ha utilizado antes.
sudo ssh localhost –l DOMAIN\\username
id -u
<!--NeedCopy-->
Verifica que se haya creado un archivo de caché de credenciales Kerberos correspondiente para el uid devuelto por el comando:
ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
Verifica que los tickets en la caché de credenciales Kerberos del usuario sean válidos y no hayan caducado:
klist
<!--NeedCopy-->