Intégrer NIS avec Active Directory
Cet article décrit comment intégrer NIS avec Windows Active Directory (AD) sur le Linux VDA à l’aide de SSSD. Le Linux VDA est considéré comme un composant de Citrix Virtual Apps and Desktops. Par conséquent, il s’intègre sans problème à l’environnement Windows Active Directory.
L’utilisation de NIS comme fournisseur d’UID et de GID au lieu d’AD requiert que les informations de compte (nom d’utilisateur et mot de passe) soient les mêmes dans AD et NIS.
Remarque :
L’authentification est toujours effectuée par le serveur Active Directory. 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 de déploiement de Linux VDA est obsolète et n’est utilisée que pour des scénarios particuliers. Pour une distribution RHEL/CentOS, suivez les instructions indiquées dans la section Installer Linux Virtual Delivery Agent pour RHEL/CentOS. Pour une distribution Ubuntu, suivez les instructions indiquées dans la section Installer Linux Virtual Delivery Agent pour Ubuntu.
Présentation de SSSD
SSSD est un démon système. Sa fonction principale consiste à offrir un accès pour l’identification et l’authentification de ressources distantes par le biais d’une infrastructure commune qui peut fournir une mise en cache et un accès en mode déconnecté au système. Il propose des modules PAM et NSS et prendra en charge à l’avenir les interfaces D-BUS qui permettront d’obtenir davantage d’informations utilisateur. Il offre également une meilleure base de données pour stocker les comptes utilisateur locaux ainsi que les données utilisateur supplémentaires.
Intégrer NIS à Active Directory
Pour intégrer NIS à AD, suivez la procédure suivante :
- Ajouter l’agent Linux VDA en tant que client NIS
- Rejoindre le domaine et créer un fichier keytab hôte avec Samba
- Configurer SSSD
- Configurer NSS/PAM
- Vérifier la configuration de Kerberos
- Vérifier l’authentification utilisateur
Ajouter l’agent Linux VDA 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 pour le serveur et le client NIS dans /etc/hosts :
{NIS server IP address} server.nis.domain nis.domain
Configurez NIS par authconfig :
sudo authconfig --enablenis --nisdomain=nis.domain --nisserver=server.nis.domain --enablemkhomedir --update
<!--NeedCopy-->
nis.domain représente le nom de domaine du serveur NIS. server.nis.domain représente 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-->
Vérifiez que les informations de compte sont disponibles à partir du serveur NIS :
getent passwd nisaccount
<!--NeedCopy-->
Remarque :
nisaccount représente le compte NIS réel sur le serveur NIS. Assurez-vous que l’UID, le GID, le répertoire de base et le shell d’ouverture de session sont correctement configurés.
Rejoindre le domaine et créer un fichier keytab hôte avec Samba
SSSD ne fournit pas de fonctions de client Active Directory pour rejoindre le domaine et gérer le fichier keytab système. Plusieurs méthodes sont disponibles, y compris :
adclirealmdWinbindSamba
Les informations contenues dans cette section décrivent l’approche Samba uniquement. Pour realmd, reportez-vous à la documentation RHEL ou CentOS du fournisseur. Ces étapes doivent être suivies avant la configuration de SSSD.
Rejoindre le domaine et créer un fichier keytab hôte avec Samba :
Sur le client Linux avec des fichiers correctement configurés :
- /etc/krb5.conf
- /etc/samba/smb.conf :
Configurez la machine pour l’authentification Kerberos et Samba :
sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
<!--NeedCopy-->
Où REALM est le nom du domaine Kerberos en majuscules et domain est le nom NetBIOS du domaine.
Si des recherches DNS sur le nom de domaine et de serveur KDC sont requises, ajoutez les options suivantes à la commande précédente :
--enablekrb5kdcdns --enablekrb5realmdns
Ouvrez /etc/samba/smb.conf et ajoutez les entrées suivantes dans 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 rejoindre le domaine Windows, votre contrôleur de domaine doit être accessible et vous devez disposer d’un compte utilisateur Active Directory avec les autorisations nécessaires pour ajouter des ordinateurs au domaine.
sudo net ads join REALM -U user
<!--NeedCopy-->
REALM est le nom de domaine Kerberos en majuscules, et user est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter les ordinateurs au domaine.
Configurer 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 à plusieurs fichiers (par exemple, sssd.conf).
- Démarrez le service sssd.
/etc/sssd/sssd.conf
Exemple de configuration sssd.conf (des options supplémentaires 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.example.com, server.ad.example.com par les valeurs correspondantes. Pour plus de détails, reportez-vous à la page sssd-ad(5) - Linux man.
Définissez les autorisations et les propriétaires de fichier sur sssd.conf :
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
Configurer NSS/PAM
RHEL/CentOS :
Utilisez authconfig pour activer SSSD. Installez oddjob-mkhomedir pour vous assurer que la création du répertoire de base 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 de Linux VDA, n’oubliez pas qu’il n’y a aucun paramètre spécial pour le client Linux VDA dans SSSD. Pour des solutions supplémentaires dans le script ctxsetup.sh, utilisez la valeur par défaut.
Vérifier la configuration de Kerberos
Pour vous assurer que Kerberos est correctement configuré pour être utilisé avec l’agent Linux VDA, 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 principaux et de suites de chiffrement. Exécutez la commande kinit Kerberos 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 domaine doivent être spécifiés en majuscules. Le signe dollar ($) doit être placé dans une séquence d’échappement avec une barre oblique inverse (\) pour empêcher le remplacement shell. Dans certains environnements, le nom de domaine DNS est différent du nom de domaine Kerberos. Assurez-vous que le nom de domaine est utilisé. Si cette commande réussit, aucun résultat n’est affiché.
Vérifiez que le ticket TGT pour le compte de machine a été mis en cache à l’aide de :
sudo klist -ke
<!--NeedCopy-->
Vérifier l’authentification utilisateur
Utilisez la commande getent pour vérifier que le format d’ouverture de session est pris en charge et que NSS fonctionne :
sudo getent passwd DOMAIN\username
<!--NeedCopy-->
Le paramètre DOMAIN indique la version courte du nom de domaine. Si un autre format d’ouverture de session est nécessaire, vérifiez en utilisant d’abord la commande getent.
Les formats d’ouverture de session pris en charge sont :
- Nom d’ouverture de session de niveau inférieur :
DOMAIN\username - Nom d’utilisateur principal (UPN) :
username@domain.com - Format du suffixe NetBIOS :
username@DOMAIN
Pour vérifier que le module PAM SSSD est correctement configuré, ouvrez une session à l’aide d’un compte d’utilisateur de domaine sur le Linux VDA. Le compte d’utilisateur de domaine n’a pas été utilisé auparavant.
sudo ssh localhost –l DOMAIN\username
id -u
<!--NeedCopy-->
Vérifiez qu’un fichier cache d’identification Kerberos correspondant a été créé pour le uid renvoyé par la commande :
ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
Vérifiez que les tickets dans le cache d’identification de Kerberos de l’utilisateur sont valides et n’ont pas expiré :
klist
<!--NeedCopy-->