Connecter les systèmes Ubuntu à Active Directory en utilisant SSSD

Introduction

L’intégration des systèmes Ubuntu à Windows Active Directory (AD) peut simplifier l’authentification des utilisateurs et la gestion des identités sur un réseau. Ce guide détaille comment utiliser le System Security Services Daemon (SSSD) pour connecter efficacement les hôtes Linux à un domaine Active Directory.

Pourquoi intégrer Ubuntu avec Active Directory ?

L’intégration avec Active Directory fournit un fournisseur d’identité centralisé pour l’authentification réseau, rendant la gestion des utilisateurs plus sécurisée et efficace. Elle simplifie les connexions des utilisateurs et le contrôle d’accès sur plusieurs systèmes, réduisant ainsi la charge administrative.

Préparer votre système Ubuntu

Installer les paquets nécessaires

Commencez par installer les paquets requis sur votre système Ubuntu. La commande suivante installe realmd, sssd, et d’autres outils essentiels :

sudo apt update
sudo apt install realmd sssd-ad sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

Cette étape garantit que tous les composants nécessaires pour l’intégration avec Active Directory sont disponibles.

Configurer DNS

Une configuration DNS correcte est cruciale pour la fonctionnalité d’Active Directory. Assurez-vous que votre serveur DNS peut résoudre le domaine AD :

sudo nano /etc/resolv.conf

Ajoutez l’IP de votre serveur DNS AD :

nameserver <AD_DNS_IP>

Activer et démarrer SSSD

Activez et démarrez le service SSSD pour appliquer vos modifications :

sudo systemctl enable sssd
sudo systemctl start sssd

Découvrir et rejoindre le domaine

Utilisez la commande realm pour découvrir et rejoindre le domaine AD. Remplacez domain.tld par le nom de votre domaine réel :

sudo realm discover domain.tld
sudo realm join -v --user=Administrator domain.tld

La commande realm join vous demandera le mot de passe de l’Administrateur et configurera automatiquement SSSD.

Configurer SSSD

Modifier la configuration de SSSD

Sauvegardez et modifiez le fichier de configuration de SSSD :

sudo cp /etc/sssd/sssd.conf /etc/sssd/sssd.conf.bak
sudo nano /etc/sssd/sssd.conf

Utilisez la configuration suivante comme modèle, en remplaçant domain.tld par votre domaine AD :

[sssd]
domains = domain.tld
config_file_version = 2
services = nss, pam

[domain/domain.tld]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_id_mapping = True
krb5_realm = DOMAIN.TLD
realmd_tags = manages-system joined-with-samba
cache_credentials = True
default_shell = /bin/bash
fallback_homedir = /home/%u@%d
use_fully_qualified_names = True
ldap_schema = ad

Configurer Kerberos

Modifiez le fichier de configuration Kerberos pour refléter votre domaine AD :

sudo nano /etc/krb5.conf

Ajoutez ou modifiez les lignes suivantes :

[libdefaults]
    default_realm = DOMAIN.TLD
    dns_lookup_realm = true
    dns_lookup_kdc = true

[realms]
    DOMAIN.TLD = {
        kdc = domain.tld
        admin_server = domain.tld
    }

[domain_realm]
    .domain.tld = DOMAIN.TLD
    domain.tld = DOMAIN.TLD

Création automatique du répertoire personnel

Ce que l’outil realm n’a pas fait pour nous, c’est la configuration de pam_mkhomedir, afin que les utilisateurs du réseau puissent obtenir un répertoire personnel lorsqu’ils se connectent. Cette étape restante peut être réalisée en exécutant la commande suivante :

sudo pam-auth-update --enable mkhomedir

Tester notre configuration

Vous devriez maintenant être en mesure de récupérer des informations sur les utilisateurs de l’AD. Dans cet exemple, John DOE est un utilisateur de l’AD :

$ getent passwd [email protected]
[email protected]:*:1725801106:1725800513:John Smith:/home/[email protected]:/bin/bash

Voyons ses groupes :

Configurer PAM et NSS

Modifiez les fichiers de configuration PAM et NSS pour intégrer SSSD :

sudo nano /etc/nsswitch.conf

Modifiez la ligne passwd et group pour inclure sss :

passwd:     compat sss
group:      compat sss
shadow:     compat sss

Configurez PAM pour utiliser SSSD :

sudo pam-auth-update

Assurez-vous que SSSD est sélectionné.

Configuration avancée

Gérer plusieurs Active Directories

Pour les environnements avec plusieurs domaines AD, une configuration supplémentaire est nécessaire. Cela inclut la définition de plusieurs domaines dans le fichier sssd.conf et l’assurance de relations de confiance appropriées entre les domaines.

Gérer les permissions des utilisateurs

Contrôlez les permissions des utilisateurs en autorisant ou en refusant l’accès à des utilisateurs ou groupes spécifiques :

sudo realm permit -g "[email protected]"
sudo realm deny --all

Sauvegardez et modifiez le fichier de configuration. Si vous n’avez pas un sssd.conf fonctionnel, ne redémarrez pas car votre système ne démarrera pas ou ne se connectera pas lorsque SSSD est cassé, et vous devrez peut-être utiliser le mode de récupération.

cp /etc/sssd/sssd.conf /etc/sssd/sssd.back.20230101
nano /etc/sssd/sssd.conf

Maintenant, vous pouvez configurer SSSD pour s’adapter à votre environnement.

[sssd]
config_file_version = 2
services = nss, pam
domains = domain.tld
default_domain_suffix = domain.tld

[domain/domain.tld]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = DOMAIN.TLD
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
ldap_sasl_authid = HOSTNAME$
fallback_homedir = /home/%d/%u
ad_domain = domain.tld
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
ad_gpo_access_control = disabled
enumerate = False
ignore_group_members = True

[nss]
memcache_size_passwd = 200
memcache_size_group = 200
memcache_size_initgroups = 50

Vous pouvez utiliser la configuration ci-dessus, en remplaçant domain.tld par votre propre domaine. Laissez-moi vous guider à travers certaines des modifications.

default_domain_suffix = domain.tld

Cela spécifie le domaine « par défaut » que les gens utiliseront lors de la connexion. Habituellement, les utilisateurs doivent se connecter en utilisant leur FQDN (par exemple, [email protected]). Par exemple, lorsque vous utilisez la commande de connexion :

Lorsque nous définissons defaultdomainsuffix à domain.tld, cela ajoute automatiquement le domaine en suffixe à toutes les connexions, ce qui facilite la tâche des utilisateurs finaux.

login myaduser

Si vous avez une forêt multidomaine, les utilisateurs d’autres domaines peuvent toujours utiliser un FQDN (par exemple : [email protected])

Si votre domaine a des extensions Unix, les attributs LDAP régulent les paramètres pour la coquille par défaut et l’emplacement du répertoire d’accueil. Ces lignes définissent la valeur par défaut si un utilisateur n’a pas ces attributs, ou si votre domaine n’a pas d’extensions Unix.

default_shell = /bin/bash
fallback_homedir = /home/%d/%u

L’emplacement du répertoire d’accueil %d/%u assure que les comptes d’utilisateurs ayant des sAMAccountNames chevauchants dans différents domaines ne se heurtent pas ([email protected] est peu probable qu’il soit le même [email protected]).

Le %d sera remplacé par le domaine de l’utilisateur lors de la connexion. %u est le nom d’utilisateur, probablement l’attribut sAMAccountName. En utilisant l’exemple ci-dessus, un utilisateur se connectera à /home/finance.domain.tld/jdoe tandis que l’autre utilisera /home/hr.domain.tld/jdoe.

Avec le %u@%d par défaut, nous avons remarqué que certains programmes ou utilisateurs ne gèrent pas bien le symbole @. Vous devez créer manuellement le répertoire parent pour chaque domaine, car oddjob-mkhomedir ne gère pas la création de répertoires parents.

mkdir /home/finance.domain.tld /home/rh.domain.tld

Dans cette section, nous désactivons le contrôle d’accès GPO :

ad_gpo_access_control = disabled

En désactivant GPO, par défaut, personne ne pourra se connecter. Pour permettre à quiconque possède une accréditation AD active de se connecter (non recommandé) :

realm permit --all

Une alternative plus sécurisée est de spécifier un utilisateur ou un groupe.

realm deny --all
realm permit [email protected]
realm permit -g [email protected]

L’ensemble de configurations suivant est principalement destiné à des domaines plus grands :

enumerate = False
ignore_group_members = True

Par défaut, SSSD énumérera (récupérera et mettra en cache) toutes les informations sur les utilisateurs et les groupes, ce qui n’est pas faisable dans les grands domaines.

La mise en cache manquera de temps et de mémoire. Par la suite, les récupérations d’informations sur le domaine (par exemple, les appels id et getent) deviennent très lentes.

Nous le configurons pour ignorer les adhésions de groupes imbriqués. Si vous comptez sur des groupes imbriqués correctement structurés, vous devrez peut-être l’activer.

[nss]
memcache_size_passwd = 200
memcache_size_group = 200
memcache_size_initgroups = 50

Les utilisateurs qui terminent une connexion auront toujours leurs informations mises en cache localement. La section NSS agrandit le cache RAM par défaut à 200 MB, de sorte que les requêtes sont rapides et n’ont pas besoin de toucher le disque à chaque fois qu’un appel getent est effectué.

Assurez-vous de dimensionner en fonction des ressources disponibles, du nombre d’utilisateurs susceptibles de se connecter et de la taille des adhésions aux groupes.

Une fois toutes les modifications effectuées, redémarrez sssd. Cette commande ne devrait rien retourner, si tout va bien.

systemctl restart sssd

Vous pouvez vérifier l’état de SSSD et les fichiers journaux avec les suivants :

systemctl status sssd
journalctl -u sssd

Questions fréquemment posées

Comment dépanner les problèmes de SSSD ?

Vérifiez le statut du service SSSD et les journaux pour le dépannage :

sudo systemctl status sssd
sudo journalctl -u sssd

Puis-je utiliser SSSD avec d’autres distributions Linux ?

Oui, SSSD est compatible avec diverses distributions Linux, y compris Debian et RedHat. Les commandes d’installation peuvent légèrement différer.

Comment assurer la création des répertoires personnels pour les utilisateurs AD ?

Configurez oddjob-mkhomedir pour créer automatiquement les répertoires personnels lors de la connexion :

sudo pam-auth-update --enable mkhomedir

Conclusion

L’intégration des systèmes Ubuntu avec Active Directory en utilisant SSSD améliore la sécurité et simplifie la gestion des utilisateurs.

En suivant les étapes décrites dans ce guide, vous pouvez connecter efficacement vos hôtes Linux à un domaine AD et gérer les connexions utilisateur sans problème.

Pour des étapes plus détaillées sur comment joindre des hôtes Linux à un domaine Active Directory ou connecter Linux à Active Directory en utilisant SSSD, consultez les ressources supplémentaires disponibles en ligne.

Pour ceux utilisant des systèmes Ubuntu, des guides spécifiques tels que Comment connecter Ubuntu à AD en utilisant SSSD offrent des instructions ciblées.

Pour plus de détails techniques et d’exemples, consultez Comment utiliser Active Directory comme fournisseur d’identité pour SSSD et Joindre une VM Linux à Active Directory.