Intégrer NIS avec Active Directory
Cet article explique comment intégrer NIS avec Windows Active Directory (AD) sur le VDA Linux à l’aide de SSSD. Le VDA Linux est considéré comme un composant de Citrix Virtual Apps and Desktops. Par conséquent, il s’intègre parfaitement à l’environnement AD Windows.
L’utilisation de NIS au lieu d’AD comme fournisseur d’UID et de GID exige que les informations de compte (combinaisons nom d’utilisateur et mot de passe) soient identiques dans AD et NIS.
Remarque :
L’authentification est toujours effectuée par le serveur AD. NIS+ n’est pas pris en charge. Si vous utilisez NIS comme fournisseur d’UID et de GID, les attributs POSIX du serveur Windows ne sont plus utilisés.
Conseil :
Cette méthode représente une manière obsolète de déployer le VDA Linux, qui n’est utilisée que pour des cas d’utilisation spécifiques. Pour une distribution RHEL, suivez les instructions de Installer le VDA Linux sur RHEL et Rocky Linux manuellement. Pour une distribution Ubuntu, suivez les instructions de Installer le VDA Linux sur Ubuntu manuellement.
Qu’est-ce que SSSD ?
SSSD est un démon système. Sa fonction principale est de fournir un accès pour identifier et authentifier les ressources distantes via un cadre commun qui peut offrir une mise en cache et un support hors ligne pour le système. Il fournit à la fois des modules PAM et NSS, et pourra à l’avenir prendre en charge des interfaces basées sur D-BUS pour des informations utilisateur étendues. Il offre également une meilleure base de données pour stocker les comptes utilisateur locaux et les données utilisateur étendues.
Intégrer NIS avec AD
Pour intégrer NIS avec AD, suivez les étapes suivantes :
Étape 1 : Ajouter le VDA Linux en tant que client NIS
Configurez le client NIS :
yum –y install ypbind rpcbind oddjob-mkhomedir
<!--NeedCopy-->
Définissez le domaine NIS :
ypdomainname nis.domain
echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network
<!--NeedCopy-->
Ajoutez l’adresse IP du serveur et du client NIS dans /etc/hosts :
{NIS server IP address} server.nis.domain nis.domain
Configurez NIS via authconfig :
sudo authconfig --enablenis --nisdomain=nis.domain --nisserver=server.nis.domain --enablemkhomedir --update
<!--NeedCopy-->
Le nis.domain représente le nom de domaine du serveur NIS. Le server.nis.domain est le nom d’hôte du serveur NIS, qui peut également être l’adresse IP du serveur NIS.
- Configurez les services NIS :
- sudo systemctl start rpcbind ypbind
sudo systemctl enable rpcbind ypbind
<!--NeedCopy-->
- Assurez-vous que la configuration NIS est correcte :
ypwhich
<!--NeedCopy-->
Validez que les informations de compte sont disponibles depuis le serveur NIS :
getent passwd nisaccount
<!--NeedCopy-->
Remarque :
Le nisaccount représente le compte NIS réel sur le serveur NIS. Assurez-vous que l’UID, le GID, le répertoire personnel et le shell de connexion sont correctement configurés.
Étape 2 : Joindre le domaine et créer un keytab d’hôte à l’aide de Samba
SSSD ne fournit pas de fonctions client AD pour joindre le domaine et gérer le fichier keytab système. Il existe plusieurs méthodes pour réaliser ces fonctions, notamment :
adclirealmdWinbindSamba
Les informations de cette section décrivent uniquement l’approche Samba. Pour realmd, consultez la documentation du fournisseur RHEL ou CentOS. Ces étapes doivent être suivies avant de configurer SSSD.
Joindre le domaine et créer un keytab d’hôte à l’aide de Samba :
Sur le client Linux avec les fichiers correctement configurés :
- /etc/krb5.conf
- /etc/samba/smb.conf:
Configurez la machine pour l’authentification Samba et Kerberos :
sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
<!--NeedCopy-->
Où REALM est le nom du royaume Kerberos en majuscules et domain est le nom NetBIOS du domaine.
Si une recherche basée sur DNS du serveur KDC et du nom de royaume est requise, ajoutez les deux options suivantes à la commande précédente :
--enablekrb5kdcdns --enablekrb5realmdns
Ouvrez /etc/samba/smb.conf et ajoutez les entrées suivantes sous la section [Global], mais après la section générée par l’outil authconfig :
kerberos method = secrets and keytab
winbind offline logon = no
Pour joindre le domaine Windows, votre contrôleur de domaine doit être accessible et vous devez disposer d’un compte utilisateur AD avec les autorisations nécessaires pour ajouter des ordinateurs au domaine :
sudo net ads join REALM -U user
<!--NeedCopy-->
REALM est le nom du royaume Kerberos en majuscules et user est un utilisateur de domaine qui a les autorisations d’ajouter des ordinateurs au domaine.
Étape 3 : Configurer SSSD
Remarque
L’utilisation de SSSD avec le démon de cache de service de noms (NSCD) peut entraîner un comportement inattendu. Pour plus d’informations, consultez Using NSCD with SSSD.
La configuration de SSSD comprend les étapes suivantes :
- Installez les packages sssd-ad et sssd-proxy sur la machine cliente Linux.
- Apportez des modifications de configuration à divers fichiers (par exemple, sssd.conf).
- Démarrez le service sssd.
/etc/sssd/sssd.conf
Un exemple de configuration sssd.conf (d’autres options peuvent être ajoutées si nécessaire) :
[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-->
Remplacez ad.domain.com, server.ad.example.com par la valeur correspondante. Pour plus de détails, consultez la page de manuel Linux sssd-ad(5).
Définissez la propriété et les autorisations du fichier sur sssd.conf :
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
Étape 4 : Configurer NSS/PAM
RHEL/CentOS :
Utilisez authconfig pour activer SSSD. Installez oddjob-mkhomedir pour vous assurer que la création du répertoire personnel est compatible avec SELinux :
authconfig --enablesssd --enablesssdauth --enablemkhomedir --update
sudo systemctl start sssd
sudo systemctl enable sssd
<!--NeedCopy-->
Conseil :
Lors de la configuration des paramètres du VDA Linux, considérez que pour SSSD, il n’y a pas de paramètres spéciaux pour le client VDA Linux. Pour les solutions supplémentaires dans le script ctxsetup.sh, utilisez la valeur par défaut.
Étape 5 : Vérifier la configuration Kerberos
Pour vous assurer que Kerberos est correctement configuré pour être utilisé avec le VDA Linux, vérifiez que le fichier keytab système a été créé et contient des clés valides :
sudo klist -ke
<!--NeedCopy-->
Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms de principal et de suites de chiffrement. Exécutez la commande Kerberos kinit pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :
sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->
Les noms de machine et de royaume doivent être spécifiés en majuscules. Le signe dollar ($) doit être échappé avec une barre oblique inverse (\) pour éviter la substitution de shell. Dans certains environnements, le nom de domaine DNS est différent du nom de royaume Kerberos. Assurez-vous que le nom de royaume est utilisé. Si cette commande réussit, aucune sortie n’est affichée.
Vérifiez que le ticket TGT pour le compte machine a été mis en cache à l’aide de :
sudo klist -ke
<!--NeedCopy-->
Étape 6 : Vérifier l’authentification de l’utilisateur
Utilisez la commande getent pour vérifier que le format de connexion est pris en charge et si le NSS fonctionne :
sudo getent passwd DOMAIN\\username
<!--NeedCopy-->
Le paramètre DOMAIN indique le nom de domaine en version courte. Si un autre format de connexion est nécessaire, vérifiez d’abord à l’aide de la commande getent.
Les formats de connexion pris en charge sont :
- Nom de connexion de niveau inférieur :
DOMAIN\username - UPN :
username@domain.com - Format de suffixe NetBIOS :
username@DOMAIN
Pour vérifier que le module PAM SSSD est correctement configuré, utilisez un compte utilisateur de domaine pour vous connecter au VDA Linux. Le compte utilisateur de domaine n’a pas été utilisé auparavant.
sudo ssh localhost –l DOMAIN\\username
id -u
<!--NeedCopy-->
Vérifiez qu’un fichier de cache d’informations d’identification Kerberos correspondant a été créé pour l’uid renvoyé par la commande :
ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
Vérifiez que les tickets dans le cache d’informations d’identification Kerberos de l’utilisateur sont valides et n’ont pas expiré :
klist
<!--NeedCopy-->