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/CentOS, siga las instrucciones en Instalar el VDA de Linux manualmente en Amazon Linux 2, CentOS, RHEL y Rocky Linux. Para una distribución Ubuntu, siga las instrucciones en Instalar el VDA de Linux manualmente en Ubuntu.
¿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 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, siga estos pasos:
Paso 1: Agregar el VDA de Linux como cliente NIS
Configure el cliente NIS:
yum –y install ypbind rpcbind oddjob-mkhomedir
Establezca el dominio NIS:
ypdomainname nis.domain
echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network
Agregue 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
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.
Configure los servicios NIS:
sudo systemctl start rpcbind ypbind
sudo systemctl enable rpcbind ypbind
Asegúrese de que la configuración de NIS sea correcta:
ypwhich
Valide que la información de la cuenta esté disponible desde el servidor NIS:
getent passwd nisaccount
Nota:
El nisaccount representa la cuenta NIS real en el servidor NIS. Asegúrese de que el UID, GID, directorio principal y shell de inicio de sesión estén configurados correctamente.
Paso 2: Unirse al dominio y crear un keytab de host mediante 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, entre ellos:
-
adcli -
realmd -
Winbind -
Samba
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.
Unirse al dominio y crear un keytab de host mediante Samba:
En el cliente Linux con los archivos configurados correctamente:
-
/etc/krb5.conf
-
/etc/samba/smb.conf:
Configure 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
Donde REALM es el nombre del reino de 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, agregue las dos opciones siguientes al comando anterior:
--enablekrb5kdcdns --enablekrb5realmdns
Abra /etc/samba/smb.conf y agregue 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 su controlador de dominio sea accesible y que tenga una cuenta de usuario de AD con permisos para agregar equipos al dominio:
sudo net ads join REALM -U user
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
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 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
Sustituya ad.domain.com, server.ad.example.com por el valor correspondiente. Para obtener más información, consulte la página man de Linux de sssd-ad(5).
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
Sugerencia:
Al configurar los ajustes de Linux VDA, tenga en cuenta que para SSSD no hay ajustes especiales para el cliente de 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
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 utilizando estas claves:
sudo kinit –k MACHINE\$@REALM
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 de reino de Kerberos. Asegúrese de que se utiliza el nombre del reino. 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
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
El parámetro DOMAIN indica el nombre de dominio de la 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 PAM de SSSD 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
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}
Compruebe que los tickets en la caché de credenciales de Kerberos del usuario son válidos y no han caducado:
klist