Intégrer NIS avec Active Directory

Cet article décrit 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 XenApp et XenDesktop. 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.

Qu’est-ce que 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.

Logiciel requis

Le fournisseur Active Directory a été introduit avec la version 1.9.0 de SSSD.

Les environnements suivants ont été testés et vérifiés lors de l’utilisation des instructions figurant dans cet article :

  • RHEL 7.3 ou version ultérieure
  • CentOS 7.3 ou version ultérieure

Intégrer NIS à Active Directory

Pour intégrer NIS à AD, suivez la procédure suivante :

  1. Ajouter l’agent Linux VDA en tant que client NIS
  2. Rejoindre le domaine et créer un fichier keytab hôte avec Samba
  3. Configurer SSSD
  4. Configurer NSS/PAM
  5. Vérifier la configuration de Kerberos
  6. 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

Définissez le domaine NIS :

ypdomainname nis.domain
echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network

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

nis.domain représente le nom de domaine du serveur NIS. The 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

Assurez-vous que la configuration NIS est correcte :

ypwhich

Vérifiez que les informations de compte sont disponibles à partir du serveur NIS :

getent passwd nisaccount

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 :

  • adcli
  • realmd
  • Winbind
  • Samba

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

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

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

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 lower-case version of the long version of the Active Directory domain.
ad_domain = ad.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

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

Conseil :

Lors de la configuration des paramètres de VDA Linux, n’oubliez pas qu’il n’y a aucun paramètre spécial pour le client VDA Linux 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 Linux VDA, vérifiez que le fichier keytab système a été créé et contient des clés valides :

sudo klist -ke

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 kinitKerberos pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :

sudo kinit –k MACHINE\$@REALM

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

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

Le paramètre DOMAIN indique la version courte du nom de domaine. Si un autre format d’ouverture de session depuis Citrix Receiver 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 VDA Linux. Le compte d’utilisateur de domaine n’a pas été utilisé auparavant.

sudo localhost –l DOMAIN\\username
id -u

Vérifiez qu’un fichier cache d’identification Kerberos correspondant a été créé pour le uid renvoyé par la commande :

ls /tmp/krb5cc_{uid}

Vérifiez que les tickets dans le cache d’identification de Kerberos de l’utilisateur sont valides et n’ont pas expiré :

klist

Intégrer NIS avec Active Directory