Product Documentation

Intégrer NIS avec Active Directory

Feb 26, 2018

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 du VDA Linux est obsolète et elle n'est utilisée que pour des scénarios particuliers. Pour une distribution RHEL/CentOS, suivez ces instructions. Pour une distribution Ubuntu, suivez ces instructions.

Qu’est-ce que SSSD ?

SSSD est un démon système. Sa fonction principale consiste à fournir 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. Si vous utilisez une version antérieure, suivez les instructions fournies dans Configuration du fournisseur LDAP avec Active Directory.

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
  • Version 1.3 ou ultérieure du VDA Linux

Intégrer NIS à Active Directory

Ajouter le VDA Linux en tant que client NIS

Configurez le client NIS :

commande Copier

yum –y install ypbind rpcbind oddjob-mkhomedir

Définissez le domaine NIS :

commande Copier

ypdomainname nis.domain

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

Ajoutez l'adresse IP pour le serveur et le client NIS dans /etc/hosts :

commande Copier

{NIS server IP address}   server.nis.domain nis.domain

Configurez NIS par authconfig :

commande Copier

sudo authconfig --enablenis --nisdomain=nis.domain --nisserver=server.nis.domain --enablemkhomedir --update

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

commande Copier

sudo systemctl start rpcbind ypbind

sudo systemctl enable rpcbind ypbind 

Assurez-vous que la configuration NIS est correcte :

commande Copier

ypwhich

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

commande Copier

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 du 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 :

commande Copier

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 ci-dessus :

commande Copier

--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 :

commande Copier

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.

commande Copier

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 :

  • Installer les packages sssd-ad et sssd-proxy sur la machine cliente Linux
  • apporter des modifications de configuration à plusieurs fichiers (par exemple, sssd.conf)
  • démarrer le service sssd

/etc/sssd/sssd.conf

Exemple de configuration sssd.conf (des options supplémentaires peuvent être ajoutées si nécessaire) :

Config Copier

 

[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.domain.com, server.ad.example.com par la valeur correspondante. Pour plus de détails, référez-vous à la page sssd-ad(5) - Linux man.

Définissez les autorisations et les propriétaires de fichier sur sssd.conf :

commande Copier

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 que la création du répertoire de base fonctionne avec SELinux :

commande Copier

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 vérifier 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 :

commande Copier

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

commande Copier

sudo kinit –k MACHINE\$@REALM

Les noms de machine et de domaine doivent être spécifiés en majuscules, et 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 :

commande Copier

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 :

commande Copier

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, veuillez vérifier 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 : DOMAINE\nomutilisateur
  • UPN : utilisateur@domaine.com
  • Format suffixe NetBIOS : nomutilisateur@DOMAINE

Pour vérifier que le module PAM SSSD est correctement configuré, ouvrez une session localement à l'aide d'un compte d'utilisateur de domaine qui ne s'est pas déjà ouvert une session sur la machine.

commande Copier

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 :

commande Copier

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é :      

commande Copier

klist