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 Windows AD.
El uso de 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 AD. NIS+ no es compatible. Si utiliza 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, siga las instrucciones de Instalar el VDA de Linux en RHEL y Rocky Linux manualmente. Para una distribución Ubuntu, siga las instrucciones de 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 proporcionar almacenamiento en caché y soporte sin conexión para el sistema. Proporciona módulos PAM y NSS, y en el futuro puede 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, siga estos pasos:
Paso 1: Añadir el VDA de Linux como cliente NIS
Configure el cliente NIS:
yum –y install ypbind rpcbind oddjob-mkhomedir
<!--NeedCopy-->
Establezca el dominio NIS:
ypdomainname nis.domain
echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network
<!--NeedCopy-->
Añada la dirección IP del servidor y el cliente NIS en /etc/hosts:
{NIS server IP address} server.nis.domain nis.domain
Configure NIS mediante authconfig:
sudo authconfig --enablenis --nisdomain=nis.domain --nisserver=server.nis.domain --enablemkhomedir --update
<!--NeedCopy-->
El nis.domain representa el nombre de dominio del servidor NIS. El server.nis.domain es el nombre de host del servidor NIS, que también puede ser la dirección IP del servidor NIS.
Configure los servicios NIS:
sudo systemctl start rpcbind ypbind
sudo systemctl enable rpcbind ypbind
<!--NeedCopy-->
Asegúrese de que la configuración de NIS sea correcta:
ypwhich
<!--NeedCopy-->
Valide que la información de la cuenta esté disponible desde el servidor NIS:
getent passwd nisaccount
<!--NeedCopy-->
Nota:
La nisaccount representa la cuenta NIS real en el servidor NIS. Asegúrese de que el UID, GID, el directorio principal y el shell de inicio de sesión estén configurados correctamente.
Paso 2: Unirse al dominio y crear un keytab de host usando Samba
SSSD no proporciona funciones de cliente de AD para unirse al dominio y administrar el archivo keytab del sistema. Existen algunos métodos para lograr estas funciones, que incluyen:
adclirealmdWinbindSamba
La información de esta sección describe únicamente el enfoque de Samba. Para realmd, consulte la documentación del proveedor de RHEL o CentOS. Estos pasos deben seguirse antes de configurar SSSD.
Unir el dominio y crear la clave de host (keytab) usando Samba:
En el cliente Linux con los archivos correctamente configurados:
- /etc/krb5.conf
- /etc/samba/smb.conf:
Configure la máquina para la autenticación 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, añada las dos opciones siguientes al comando anterior:
--enablekrb5kdcdns --enablekrb5realmdns
Abra /etc/samba/smb.conf y añada 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
Para unirse al dominio de Windows, su controlador de dominio debe ser accesible y debe tener una cuenta de usuario de AD con permisos para añadir 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 añadir equipos al dominio.
Paso 3: Configurar SSSD
Nota
El uso de SSSD con el demonio de caché del servicio de nombres (NSCD) puede provocar un comportamiento inesperado. Para obtener más información, consulte Uso de NSCD con SSSD.
La configuración de SSSD consta de los siguientes pasos:
- Instale los paquetes sssd-ad y sssd-proxy en la máquina cliente Linux.
- Realice cambios de configuración en varios archivos (por ejemplo, sssd.conf).
- Inicie el servicio sssd.
/etc/sssd/sssd.conf
Un ejemplo de configuración de sssd.conf (se pueden añadir 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-->
Sustituya ad.domain.com, server.ad.example.com por el valor correspondiente. Para obtener más información, consulte la sssd-ad(5) - página man de Linux.
Establezca 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:
Utilice authconfig para habilitar SSSD. Instale oddjob-mkhomedir para asegurarse 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 de Linux VDA, tenga en cuenta que para SSSD no hay ajustes especiales para el cliente Linux VDA. Para soluciones adicionales en el script ctxsetup.sh, utilice el valor predeterminado.
Paso 5: verificar la configuración de Kerberos
Para asegurarse de que Kerberos está configurado correctamente para su uso con el VDA de Linux, compruebe que el archivo keytab del sistema se ha creado y contiene claves válidas:
sudo klist -ke
<!--NeedCopy-->
Este comando muestra la lista de claves disponibles para las distintas combinaciones de nombres principales y conjuntos de cifrado. Ejecute el comando Kerberos kinit para autenticar la máquina con el controlador de dominio mediante estas claves:
sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->
Los nombres de la máquina y del dominio deben especificarse en mayúsculas. El signo de dólar ($) debe escaparse con una barra invertida (\) para evitar la sustitución de shell. En algunos entornos, el nombre de dominio DNS es diferente del nombre de dominio de Kerberos. Asegúrese de que se utiliza el nombre de dominio. Si este comando se ejecuta correctamente, no se muestra ninguna salida.
verificar que el ticket TGT para la cuenta de máquina se ha almacenado en caché mediante:
sudo klist -ke
<!--NeedCopy-->
Paso 6: verificar la autenticación de usuario
Utilice el comando getent para verificar que el formato de inicio de sesión es compatible y si el NSS funciona:
sudo getent passwd DOMAIN\\username
<!--NeedCopy-->
El parámetro DOMAIN indica el nombre de dominio de versión corta. Si se necesita otro formato de inicio de sesión, verificar primero con el comando getent.
Los formatos de inicio de sesión admitidos 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 SSSD PAM está configurado correctamente, utilice 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-->
Compruebe que se ha creado un archivo de caché de credenciales de Kerberos correspondiente para el uid devuelto por el comando:
ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
Compruebe que los tickets en la caché de credenciales de Kerberos del usuario son válidos y no han caducado:
klist
<!--NeedCopy-->