Associer une machine RHEL ou autre Linux directement à Microsoft Active Directory

Il peut être difficile de gérer l'accès aux systèmes sur un réseau. Tandis que certains administrateurs créent tous les utilisateurs sur toutes les machines, d'autres partagent des comptes à l'aide de clés SSH ou de mots de passe. D'autres encore utilisent la liaison LDAP (en utilisant soit l'infrastructure Active Directory existante, soit un domaine distinct), ce qui les oblige à écrire des requêtes LDAP pour filtrer l'accès.

Toutes ces méthodes compliquent la gestion de l'accès aux machines et exigent que les administrateurs soient informés lorsqu'une personne quitte ou rejoint une équipe. En cas de partage de comptes, la journalisation est presque inutile, car tout le monde a le même nom d'utilisateur. Et les communications des ressources humaines à propos des changements dans l'équipe ne correspondent pas toujours aux besoins des équipes techniques. Il existe pourtant une solution efficace à ces problèmes, qui s'intègre aux configurations d'entreprise courantes.

La plupart des entreprises que je connais disposent d'un système ERP qui permet de créer, désactiver ou supprimer automatiquement les comptes d'utilisateurs dans Microsoft Active Directory (AD) afin de profiter du travail des autres. Par exemple, le service SSSD peut se connecter directement à AD.

S'il vous est arrivé de configurer un serveur d'authentification pour Linux ayant une relation de confiance avec AD, SSSD a déjà communiqué avec vos serveurs AD. Dans le cadre d'une relation de confiance, le serveur d'authentification que vous avez configuré renvoie une référence aux serveurs AD, ce qui oblige le service SSSD à interroger directement vos serveurs AD. Avec la configuration suivante, il n'est pas nécessaire de disposer d'un serveur d'authentification supplémentaire et le service SSSD est configuré pour accéder directement à AD en premier.

Il faut ensuite définir le contrôle des accès. C'est là qu'intervient le contrôle d'accès basé sur les rôles (RBAC). Cette technologie permet d'attribuer les accès non plus à des utilisateurs, mais à des rôles. Une fois les groupes définis, vous pouvez affecter un nouveau membre à une équipe, qui fait déjà partie du rôle ayant un accès approprié à un groupe de serveurs. Cette approche élimine les demandes d'accès des nouveaux membres qui font référence à d'anciens employés dont les accès ont été purgés.

Lorsque le nouvel utilisateur est ajouté au groupe de son équipe, il dispose de l'accès dont il a besoin. Vous éviterez aussi de vous rendre compte un an plus tard qu'un ancien employé a toujours accès à tous les serveurs, car personne n'a informé les administrateurs de son départ. Lorsque le système ERP met automatiquement à jour son compte AD, l'employé perd tout accès.

Auparavant, il était difficile de gérer AD à partir d'autres systèmes d'exploitation que Windows. Mais depuis que Microsoft a lancé Windows Admin Center, vous pouvez accéder aux utilisateurs et aux ordinateurs Active Directory directement à partir du navigateur de votre choix, sur tout type de système d'exploitation. Cet outil donne également accès à d'autres outils de gestion Windows. Installez-le sur un serveur Windows pour ne plus avoir à vous soucier des limites de session ou de RemoteApp. Il vous suffit de lancer un navigateur et d'accéder à l'interface web.

Configurer les groupes AD pour le contrôle d'accès basé sur les rôles

Le schéma de dénomination de votre entreprise peut être différent des exemples présentés dans cet article. Les noms de groupe ne sont pas importants. L'essentiel est l'utilisation prévue de chaque groupe.

Dans la mesure où le service SSSD ne synchronise pas de groupes AD et se contente d'obtenir la liste des groupes dont l'utilisateur est membre pendant la connexion, les groupes manquants n'empêchent pas cette configuration de fonctionner. Toutefois, si vous disposez de plusieurs équipes avec des autorisations déléguées dans AD, il est recommandé de créer tous les groupes pour éviter qu'ils ne se trouvent dans la mauvaise unité organisationnelle et qu'ils ne donnent le contrôle des accès aux mauvaises équipes.

Accès à des machines spécifiques

Créez deux groupes dans Active Directory pour chaque machine. Ils doivent tous les deux inclure le nom abrégé de la machine. 

L'un des groupes est réservé à l'accès SSH propre à la machine (ci-après Machine_SSH_Access).

L'autre groupe fournit un accès sudo propre à la machine (ci-après Machine_SUDO_Access).

Exemples de formats de groupe :

<DOMAIN> Linux <hostname> ssh access
<DOMAIN> Linux <hostname> sudo access

• <hostname> est le nom abrégé de la machine.
• <DOMAIN>est le nom abrégé de votre domaine (facultatif).

Accès à toutes les machines

Créez deux groupes dans Active Directory pour un accès global aux machines.

L'un des groupes est réservé à l'accès SSH (ci-après Global_SSH_Access) à toutes les machines.

L'autre groupe fournit un accès sudo (ci-après Global_SUDO_Access) à toutes les machines.

Exemples de formats de groupe :

<DOMAIN> Linux ssh access
<DOMAIN> Linux sudo access

<DOMAIN>est le nom abrégé de votre domaine (facultatif).

Imbrication

L'imbrication dans les groupes AD est autorisée. Si vous souhaitez créer un groupe avec un accès à plusieurs machines, il est inutile de modifier la configuration des machines RHEL. Vous pouvez ajouter le nouveau groupe à celui qui a accès aux machines en question. Cette méthode vous permet de contrôler l'accès directement depuis AD.

Exemple d'imbrication :

• CONTOSO Linux Webserver1 ssh access
  • CONTOSO Linux Webservers ssh access
    • CONTOSO Web Developers
      • User1
      • User2

Cette imbrication permet d'attribuer des rôles (CONTOSO Web Developers) à des groupes de machines (CONTOSO Linux Webservers ssh access) au lieu d'assigner des utilisateurs à des systèmes spécifiques.

Associer une machine Linux à un domaine

Si le service RC4 est activé dans votre environnement, suivez les conseils de sécurité Microsoft et désactivez-le.

Pour associer une machine Linux à un domaine :

1. Installez les paquets requis :

$ sudo dnf install -y chrony krb5-workstation \
samba-common-tools oddjob-mkhomedir samba-common \
sssd authselect

2. Ajoutez la chaîne de l'autorité de certification de votre domaine en créant le fichier /etc/sssd/pki/sssd_auth_ca_db.pem et en écrivant la chaîne de l'autorité de certification du domaine. Il n'est pas nécessaire d'inclure les certificats des contrôleurs de domaine. Vous pouvez commencer par le certificat qui a signé leurs certificats.
3. Ajoutez la chaîne de l'autorité de certification aux ancres d'approbation du système :

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

4. Configurez le service SSSD en modifiant le fichier /etc/sssd/sssd.conf ou /etc/sssd/conf.d/<DOMAIN>.conf selon les lignes suivantes.

La modification du fichier /etc/sssd/conf.d/<DOMAIN>.conf est la méthode moderne privilégiée, mais la modification du fichier/etc/sssd/sssd.conf fonctionne également.

[domain/<DOMAIN>]
access_provider = simple
auth_provider = ad
chpass_provider = ad
id_provider = ad
dyndns_update = true
override_homedir = /home/%u
override_shell = /bin/bash
default_shell = /bin/bash
ldap_idmap_range_size = 4000000
cache_credentials = true
simple_allow_groups = Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access, Machine_SUDO_Access
ignore_group_members = true
ad_gpo_access_control = disabled
ad_enable_gc = false
ad_use_ldaps = true
[sssd]
services = nss, pam
config_file_version = 2
domains = <DOMAIN>

• <DOMAIN>est le nom complet de votre domaine en lettres majuscules. Utilisez exclusivement des majuscules pour éviter tout problème d'authentification.
• ldap_idmap_range_size est un paramètre facultatif. Il est seulement nécessaire pour les environnements AD volumineux. La modification de cette valeur entraîne la modification du hachage de l'UID. Ne la modifiez pas après l'association de la machine au domaine, et assurez-vous d'utiliser la même valeur sur toutes les machines.
• Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access et Machine_SUDO_Access sont les groupes AD que vous avez créés pour le contrôle d'accès basé sur les rôles.

5. Définissez les autorisations pour le fichier que vous venez d'écrire, /etc/sssd/sssd.conf ou /etc/sssd/conf.d/<DOMAIN>.conf :

$ sudo chmod 400 /etc/sssd/sssd.conf

ou

$ sudo chmod 400 /etc/sssd/conf.d/*.conf

6. Configurez KRB5 en modifiant le fichier /etc/krb5.conf selon ces lignes :

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = true
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = <DOMAIN>
[realms]
[domain_realm]

Il n'est pas nécessaire d'indiquer une valeur sous [realms] ou [domain_realm]. SSSD détecte automatiquement ces informations à partir du DNS.

7. Configurez l'accès SUDO en créant un fichier dans /etc/sudoers.d :

$ sudo visudo -f /etc/sudoers.d/<DOMAIN>

Définissez l'accès sudo par défaut pour les membres des groupes AD sudo. Vous pouvez nommer le fichier comme vous le souhaitez, le nom DOMAIN n'est pas obligatoire.

Vous devez ajouter une barre oblique inverse (\) devant chaque espace. Par exemple, pour « Linux sudo access », écrivez « Linux\ sudo\ access ».

%Global_SUDO_Access  ALL=(ALL) ALL
%Machine_SUDO_Access  ALL=(ALL) ALL

Global_SUDO_Access et Machine_SUDO_Access sont les groupes AD que vous avez créés pour le RBAC. Le signe de pourcentage (%) avant le nom du groupe indique qu'il s'agit d'un groupe.

Tout autre accès sudo que vous souhaitez accorder aux groupes AD peut être défini de la même façon dans des fichiers distincts ou dans le même fichier.

8. Assurez-vous que le nom d'hôte de la machine est défini sur le nom de domaine complet. Le nom d'hôte de la machine ne peut pas être le nom abrégé :

$ sudo hostnamectl set-hostname $(hostname -f)

9. Associez la machine avec l'une des commandes suivantes (adcli est compatible avec SMBv1 et SMBv2). Pour définir les informations du système d'exploitation dans AD lors de l'association, utilisez la commande suivante :

$ source /etc/os-release
$ sudo adcli join -U <join_user> --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

Vous pouvez également l'associer sans définir les informations du système d'exploitation :

$ sudo adcli join -U <join_user>

<join_user> est le compte AD qui sera utilisé pour associer la machine au domaine. Le mot de passe demandé par adcli n'est pas stocké. Les autorisations déléguées sont les autorisations requises pour l'association.

10. Activez et démarrez SSSD et oddjobd :

$ sudo systemctl enable sssd oddjobd
$ sudo systemctl restart sssd oddjobd

11. Activez la connexion avec AD :

$ sudo authselect select sssd with-mkhomedir --force

Tant que votre compte est membre de l'un des groupes que vous avez créés, vous pouvez vous connecter à la machine. Il n'est pas nécessaire d'indiquer le domaine. Le domaine spécifié en tant que default_realm dans le fichier /etc/krb5.conf est utilisé. GNOME peut nécessiter un redémarrage, mais sshd accepte généralement les modifications sans redémarrage.

Maintenir les informations du système d'exploitation à jour

Par défaut, l'objet ordinateur n'est pas autorisé à mettre à jour les informations de son propre système d'exploitation. Accédez aux utilisateurs et aux ordinateurs Active Directory pour autoriser l'auto-écriture de chacun des champs du système d'exploitation sur les objets ordinateur (vous pouvez le faire au niveau de l'unité organisationnelle). Après avoir ajouté l'objet AD, mettez-le à jour avec les informations récentes relatives au système d'exploitation :

$ source /etc/os-release
$ sudo /usr/sbin/adcli update --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

Ces informations peuvent être ajoutées en tant que tâche cron ou service systemd. Par exemple :

[Unit]
Description=Updates AD with current OS information
After=sssd.service
[Service]
Type=oneshot
EnvironmentFile=/etc/os-release
ExecStart=/usr/sbin/adcli update --os-name="${NAME}" --os-version="${VERSION}" --os-service-pack="${VERSION_ID}"
[Install]
WantedBy=multi-user.target

Activer l'authentification par carte à puce

Dans cette section, on part du principe que l'authentification par carte à puce fonctionne sur vos machines Windows. Si ce n'est pas le cas, configurez l'authentification par carte à puce sur une machine Windows avant de continuer.

1. Écrivez la chaîne de certificats de votre domaine dans le fichier /etc/sssd/pki/sssd_auth_ca_db.pem. Il n'est pas nécessaire d'inclure les certificats des contrôleurs de domaine. Vous pouvez commencer par le certificat qui a signé leurs certificats.
2. Ajoutez le certificat à la liste des autorités de certification approuvées de la machine :

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

3. Modifiez le fichier /etc/sssd/sssd.conf ou /etc/sssd/conf.d/<DOMAIN>.conf, en fonction du fichier que vous avez utilisé lorsque vous avez associé le domaine, puis ajoutez la ligne suivante dans la section [domain/<DOMAIN>]. Cette entrée indique à SSSD où rechercher le certificat d'utilisateur. Windows utilise l'attribut userCertificate. Si nous utilisons le même attribut, la même carte à puce fonctionne aussi bien sous Linux que sous Windows.

ldap_user_certificate = userCertificate;binary

Ajoutez ces lignes à la fin du même fichier de configuration :

[pam]
pam_cert_auth = true

4. Modifiez le fichier /etc/krb5.conf et ajoutez les lignes suivantes sous [realms], en remplaçant <DOMAIN>par le nom complet de votre domaine en lettres majuscules. Cette méthode permet de résoudre une potentielle incohérence, car contrairement à Linux, Windows n'est pas sensible à la casse.

<DOMAIN> = {
pkinit_anchors = DIR:/etc/sssd/pki
  pkinit_kdc_hostname = <DOMAIN>
}

5. Utilisez l'une des commandes suivantes pour activer l'authentification par carte à puce dans PAM :

• authselect enable-feature with-smartcard : autorise l'authentification par carte à puce en tant qu'option.
• authselect enable-feature with-smartcard-required : exige l'authentification par carte à puce. Par défaut, sshd n'appelle pas PAM lors de l'authentification avec des clés SSH.
• authselect enable-feature with-smartcard-lock-on-removal : exige l'authentification par carte à puce et verrouille la machine lorsque la carte à puce est retirée.

Activer l'accès SSH à l'aide du certificat de carte à puce

Sur RHEL 8 et versions ultérieures, vous pouvez activer l'accès SSH à l'aide d'une carte à puce.

1. Vérifiez que le certificat de la carte à puce est lu correctement sur AD :

sss_ssh_authorizedkeys ${USER}

Si aucune clé publique n'est renvoyée, vérifiez que l'authentification par carte à puce est correctement configurée.

2. Ajoutez les lignes suivantes au paramètre /etc/ssh/sshd_config :

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

3. Redémarrez sshd :

$ sudo systemctl restart sshd

Pour vous connecter par SSH à partir d'un client, utilisez l'option PKCS11Provider=/usr/lib64/opensc-pkcs11.so. Tant que la carte à puce correspond à une clé publique pour l'utilisateur, vous devrez saisir le code d'identification ou le mot de passe de la carte à puce :

$ ssh -o PKCS11Provider=/usr/lib64/opensc-pkcs11.so <host>

Informations supplémentaires

Vous disposez maintenant d'une machine associée au domaine, avec un contrôle d'accès basé sur les rôles qui détermine qui peut se connecter ou exécuter des commandes liées à des privilèges. La gestion devient rapidement plus facile, car vous pouvez tirer parti du travail des autres. Voici quelques éléments à prendre en compte :

• La désactivation d'un utilisateur dans AD bloque immédiatement l'accès à la machine. Comme sous Windows, toute personne déjà connectée le reste.
• Toute modification apportée aux groupes des utilisateurs est mise à jour lors de la connexion, comme sous Windows. Cette étape précède la vérification de leurs autorisations de connexion.
• Le service SSSD reconnaît les sites. Si vous configurez des sites dans AD Sites and Services, SSSD se connecte au contrôleur de domaine approprié.
• SSSD programme automatiquement une rotation du mot de passe de la machine.
• SSSD crée et gère automatiquement les enregistrements DNS d'une machine tant que les mises à jour dynamiques (sécurisées ou non) sont activées.

En général, je déconseille d'utiliser des outils Windows pour gérer des systèmes Linux et des outils Linux pour gérer des systèmes Windows, car il arrive souvent que des fonctions importantes soient perdues, que la sécurité soit trop faible ou qu'il soit beaucoup plus facile d'accomplir la même tâche avec un outil natif. Avec AD, c'est différent. La technologie SSSD a été soigneusement conçue pour être compatible avec AD, ce qui facilite le travail.