Product Documentation

Configurer SSSD

Oct 31, 2016

Utilisez les informations de cet article pour configurer SSSD sur Red Hat et CentOS ; il comprend des instructions permettant de connecter une machine VDA Linux à un domaine Windows et des indications sur la configuration de l'authentification Kerberos. 

Remarque

Si vous utilisez SSSD, suivez les instructions contenues dans cet article, au lieu des informations fournies dans la sectionAjouter une machine Linux au domaine Windows.

Important

Ceci est une fonctionnalité expérimentale et elle est fournie par Citrix comme Technical Preview. La mise en place de cette fonctionnalité dans un environnement de production doit être effectuée avec précaution. 

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 utilisateurs locaux ainsi que les données utilisateur supplémentaires.

La configuration de SSSD sur RHEL et CentOS implique les étapes suivantes :

  1. Rejoindre le domaine et créer un fichier keytab hôte avec Samba
  2. Configurer SSSD
  3. Configurer NSS/PAM
  4. Vérifier la configuration de Kerberos
  5. Vérifier l'authentification utilisateur

Logiciel requis

Le fournisseur Active Directory a été introduit avec SSSD version 1.9.0. 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.2/CentOS 7.2
  • VDA Linux versions 1.3, 1.4

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 Red Hat ou CentOS. Ces étapes doivent être suivies avant la configuration de SSSD.

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 court du domaine Active Directory.

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 le package sssd-ad 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) :

commande Copier

[sssd]

config_file_version = 2

domains = ad.example.com

services = nss, pam

 

[domain/ad.example.com]

# Uncomment if you need offline logins

# cache_credentials = true

 

id_provider = ad

auth_provider = ad

access_provider = ad

ldap_id_mapping = true

ldap_schema = 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 service sssd start

sudo chkconfig sssd on

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 doit afficher 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

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 doit être le nom de domaine version courte ; 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 connecté à la machine précédemment.

commande Copier

sudo ssh 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