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.
Sommaire :
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.
![](https://brandonvisca.com/wp-content/uploads/2024/06/image-1.gif)
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 :
$ groups [email protected]
[email protected] : utilisateurs du [email protected] [email protected]
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 :
login [email protected]
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.