Intégration d'une VM linux dans un Active Directory

2023-03-28 2457 mots 12 minutes

Contenu

Introduction

Il y a quelques mois pour un client grand compte j’ai eu pour mission d’intégrer des l’ensemble des VMs Linux (RHEL8) au sein de son domaine géré par deux Active Directory. Ceci peut être une aberration pour certains, mais ce fonctionnement apporte une authentification commune entre Linux et Windows et sécurisée pour l’ensemble des administrateurs systèmes. Je rédige ces quelques lignes, car je n’avais pas trouvé de documentation fonctionnelle à l’époque et je suis sûr que le sujet peut en intéresser plus d’un.

Prérequis

Cette procédure n’a pas été testée que sur des Red Hat 7 & 8.
L’installation et la configuration de votre ou vos Active Directory a déjà été faîte.
Vous disposez d’un serveur DNS et NTP configuré et fonctionnel.
L’installation de votre machine Linux a été faîte au préalable.
Vous êtes en capacités de pouvoir installer plusieurs packages.
Vous comprenez comment fonctionne Kerberos, car je ne reviendrai pas sur ce point dans cet article.

Si vous ces prérequis sont remplis, vous pouvez commencer la procédure !

1.Installation des packages nécessaires

Pour intégrer vos machines Linux à un Active directory, vous aurez besoin de 3 paquets:

SSSD (System Security Services Daemon) est un démon de service qui fournit une authentification, une autorisation et une résolution de nom pour les systèmes Linux et Unix en utilisant des sources de données externes telles que des serveurs LDAP, Kerberos ou Active Directory (AD). SSSD offre une gestion centralisée des identités pour les utilisateurs et les groupes, ainsi qu’une gestion des connexions réseau pour les clients.
Samba est une suite de logiciels qui permet de partager des fichiers, des imprimantes et d’autres ressources entre des ordinateurs Windows et Linux/Unix. Samba peut également fonctionner en tant que contrôleur de domaine pour gérer les utilisateurs et les ordinateurs dans un environnement Windows, ainsi qu’intégrer l’authentification et l’autorisation avec Active Directory. Samba est souvent utilisé pour fournir des services de fichiers et d’impression sur des réseaux hétérogènes.
Oddjob est un service qui fournit des services d’infrastructure de sécurité pour les systèmes Linux. Oddjob gère les clés de chiffrement, les certificats et les autorités de certification (CA) pour les clients Linux, ainsi que les tâches de gestion des mots de passe et des accès de cryptage de disque. Oddjob peut également fournir des services de gestion des comptes d’utilisateur et de groupe.
krb5 (Kerberos version 5) est un logiciel de sécurité qui fournit une authentification forte pour les applications et les services dans un environnement de réseau d’entreprise. Kerberos est un protocole d’authentification et de gestion des clés de chiffrement qui permet aux utilisateurs de s’authentifier une seule fois et d’accéder à plusieurs services sans avoir besoin de fournir leurs identifiants à chaque fois.

Pour l’installation des packages vous pouvez exécuter la commande suivante:

yum install sssd samba oddjob-mkhomedir.x86_64 krb5-workstation krb5-libs

2.Check du DNS

Vous allez ensuite modifier le fichier /etc/resolv.conf en ajoutant votre domaine ainsi que vos serveurs DNS.

Pour rappel: “Le fichier /etc/resolv.conf est un fichier texte qui stocke les adresses des serveurs DNS du système."

Votre fichier devrait avoir cette allure:

search  domain.local
nameserver      A.B.C.D
nameserver      A.B.C.D

Le champs search va permettre de rechercher un hôte dans votre domaine automatique. Au lieu d’effectuer ping myhost.domain.local vous pourrez simplement effectuer ping myhost.

3.Configuration Kerberos

Vous allez ensuite vous attaquer à la configuration de krb5. Ce fichier de config va regrouper les informations de configuration client pour dialoguer avec le serveur Kerberos maître (nos AD). Par mesure de sécurité vous pouvez copier le fichier original avec la commande ci-dessous, afin de récupérer le contenu en cas d’erreur.

cp -p /etc/krb5.conf /etc/krb5.conf.orig

Ensuite vous allez éditer le fichier /etc/krb5.conf afin qu’il ait la configuration suivante:

vim /etc/krb5.conf

[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 = false
default_realm = DOMAIN.LOCAL # <!> A remplacer par votre domaine.
default_ccache_name = KEYRING:persistent:%{uid}

[realms]
# EXAMPLE.COM = {
#  kdc = kerberos.example.com
#  admin_server = kerberos.example.com
# }

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

Je ne vais pas revenir sur chacun des champs mais je vais vous expliquer les principaux:

dns_lookup_realm: Cette option définit si les noms de domaines des serveurs KDC doivent être résolus pour déterminer le nom de domaine Kerberos (realm) lors de la demande d’un ticket de sécurité. Si cette option est activée, le système essaiera de résoudre le nom de domaine Kerberos via DNS.
dns_lookup_kdc: Cette option définit si les noms de domaines des serveurs KDC doivent être résolus pour trouver les serveurs KDC qui gèrent les services demandés. Si cette option est activée, le système essaiera de résoudre les noms des serveurs KDC via DNS.
ticket_lifetime: Cette option définit la durée de validité des tickets de sécurité Kerberos. Une fois qu’un ticket a expiré, l’utilisateur doit se reconnecter et en demander un nouveau.
renew_lifetime: Cette option définit la durée pendant laquelle un ticket de sécurité peut être renouvelé. Si un utilisateur se connecte et qu’il possède un ticket qui expire bientôt, il peut renouveler son ticket s’il est encore dans la durée de vie du ticket.
forwardable: Cette option définit si un ticket de sécurité peut être transféré à un autre utilisateur ou à un autre service.
rdns: Cette option définit si le système doit tenter de résoudre les noms d’hôte des adresses IP des serveurs KDC et des serveurs d’applications.
default_realm: Cette option définit le nom de domaine Kerberos (realm) par défaut pour les clients Kerberos. Si un nom de domaine Kerberos n’est pas spécifié, le client utilisera cette option pour déterminer le domaine Kerberos par défaut.

4.Configuration Samba

Comme tout à l’heure vous pouvez copier le fichier original avec la commande ci-dessous, afin de récupérer le contenu en cas d’erreur.

/etc/samba/smb.conf /etc/samba/smb.conf.orig

Ensuite, vous devrez éditer la configuration du fichier /etc/samba/smb.conf avec votre éditeur préféré afin d’avoir une configuration comme celle-ci:

workgroup = DOMAIN

   client signing = yes
   client use spnego = yes
   kerberos method = secrets and keytab

           ;       security = user

    security = ads
    realm = DOMAIN.LOCAL

    password server = AD.DOMAIN.LOCAL

    load printers = no

   ;[homes]
   ;     comment = Home Directories
   ;     browseable = no
   ;     writable = yes


   ;[printers]
   ;     comment = All Printers
   ;     path = /var/spool/samba
   ;     browseable = no
   ;     guest ok = no
   ;     writable = no
   ;     printable = yes

Les 4 points majeurs à retenir:

kerberos method: Cette option définit la méthode d’authentification Kerberos utilisée pour l’authentification des utilisateurs. Les valeurs courantes de cette option incluent “secrets and keytab” et “system keytab”, qui déterminent comment les informations d’authentification sont stockées et récupérées.
security: Cette option définit le niveau de sécurité pour les connexions de clients Samba. Les valeurs courantes incluent “user”, “share” et “ads”. La valeur “user” signifie que l’authentification est basée sur les utilisateurs Samba, “share” signifie que l’authentification est basée sur le partage de ressources, et “ads” signifie que l’authentification est basée sur un serveur d’annuaire Active Directory.
realm: Cette option définit le domaine Kerberos pour l’authentification des utilisateurs. Cette option doit correspondre au domaine Kerberos configuré sur les clients et les serveurs pour permettre une authentification réussie.
password server: Cette option définit le serveur qui stocke les informations d’authentification pour les utilisateurs Samba. Cette option est utilisée pour fournir une redondance et une haute disponibilité dans les environnements Samba à grande échelle. Les informations d’authentification comprennent les noms d’utilisateur et les mots de passe des utilisateurs Samba.

ℹ️ ; sont des commentaires

Veuillez taper les quelques commandes ci-dessous pour lancer le service samba au boot de la machine, le démarrer maintenant et vérifier son statut:

systemctl enable smb
systemctl start smb
service smb status

5.Vérifier le nom de la machine dans /etc/hostname et /etc/sysconfig/network

Le hostname de vos VMs Linux est très important pour que ce système fonctionne c’est pourquoi je vous recommande de vérifier ou d’inscrire le nom de votre serveur dans les fichiers suivants /etc/hostname & /etc/sysconfig/network.

Si ce n’est pas déjà fait, ajouter la ligne suivante dans /etc/hostname: template-linux.domain.local

Et celle-ci dans /etc/sysconfig/network: HOSTNAME=template-linux

6.Ajouter le contrôleur de domaine dans /etc/hosts

Veuillez ajouter un enregistrement statique avec le nom complet du contrôleur de domaine à la fin du fichier /etc/hosts. La traduction entre l’adresse IP et le nom du serveur est nécessaire pour que vous puissiez utiliser le nom d’hôte au lieu de l’adresse IP.

A.B.C.D contoller.domain.local template-linux

À ce moment là, vous devriez avoir besoin de redémarrer le service en charge du réseau de votre serveur pour prendre en compte votre config.

systemctl restart network

En exécutant la commande suivante vous permettez la création une correspondance entre un SID (Security Identifier) Windows et un groupe Unix. En ajoutant cette entrée de correspondance, la commande permet aux utilisateurs Windows membres du groupe “Built-in Guests” d’accéder aux ressources partagées sur un système Unix. Cela peut être utile dans un environnement où des utilisateurs Windows et Unix doivent collaborer et partager des fichiers ou d’autres ressources.

net -s /dev/null groupmap add sid=S-1-5-32-546 unixgroup=nobody type=builtin

7.Configuration de oddjob-mkhomedir avec authconfig

Veuillez exécuter la commande suivante qui permettra de configurer l'authentification sur un système Linux en utilisant les services SSSD (System Security Services Daemon) et en créant automatiquement des répertoires utilisateurs (home directories).

authconfig --update --enablesssd --enablesssdauth --enablemkhomedir

9.Configuration de sssd

/etc/sssd/sssd.conf

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

# le premier "domain" est à conservé, il faut juste adapté "domain.local"
[domain/domain.local]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u
default_shell = /bin/bash

Je ne vais pas revenir sur les paramètres domains, override_homedir & default_shell qui se comprennent de manière limpide mais je vais prendre le temps de détailler les suivants:

id_provider : spécifie la source d’identification pour les utilisateurs et les groupes. Il existe plusieurs options pour ce paramètre, telles que ldap pour interroger un serveur LDAP, ad pour interroger un Active Directory, ou local pour utiliser des comptes locaux sur la machine.
auth_provider : spécifie la source d’authentification pour les utilisateurs. Cela détermine comment SSSD vérifie les informations d’authentification des utilisateurs pour leur permettre de se connecter. Les options pour ce paramètre sont similaires à celles du id_provider.
chpass_provider : spécifie la source pour changer le mot de passe. Ce paramètre détermine comment SSSD gère les demandes de changement de mot de passe des utilisateurs.
access_provider : spécifie la source pour gérer l’accès des utilisateurs aux ressources système. Ce paramètre détermine comment SSSD gère les demandes d’accès des utilisateurs et les autorisations d’accès.
cache_credentials : spécifie si SSSD doit mettre en cache les informations d’identification des utilisateurs. Lorsque cette option est activée, SSSD stocke les informations d’identification dans un cache local pour éviter de devoir interroger les sources d’authentification à chaque demande d’accès.

Puis veuillez modifier les permissions sur le fichier /etc/sssd/sssd.conf:

# chown root:root /etc/sssd/sssd.conf
# chmod 600 /etc/sssd/sssd.conf

10.Mise à jour de sshd_config

Éditer votre config sshd afin d'autoriser les groupes utilisateurs présents dans votre AD à ce connecter en ssh à votre machine linux:

/etc/ssh/sshd_config

Addressfamily inet
Protocol 2
PermitRootLogin no
AllowGroups XXXX XXXX XXXX XXXX
DenyUsers root
DenyGroups root

11.Mise à jour de sudoers avec visudo

Vous pourriez avoir besoin d’ajuster votre configuration sudoers via visudo, pour ce faire il vous suffira d**'**ajouter votre ou vos groupes**.

[...]
## Allows people in group wheel to run all commands
# %wheel        ALL=(ALL)       ALL
% XXXXX     ALL=(ALL)       ALL

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

12.Redémarrage de l’ensemble des services

Vous pouvez exécuter ces commandes afin de redémarrer l’ensemble des services:

# systemctl restart sshd
# systemctl restart sssd
# systemctl restart smb
# systemctl restart oddjobd

13.Initialisation avec l’AD

Exécutez la commande suivante:

kinit <username_ad>
Password for username_ad@DOMAIN.LOCAL:

La commande kinit est utilisée pour obtenir un ticket Kerberos pour un utilisateur. Le ticket Kerberos est un jeton d’authentification qui permet à un utilisateur de prouver son identité auprès d’un serveur dans un environnement Kerberos.

La commande kinit est généralement utilisée lorsque l’utilisateur doit accéder à des services réseau qui requièrent une authentification Kerberos, tels que l’authentification d’un utilisateur lorsqu’il se connecte à un système distant, l’accès à des ressources partagées sur un réseau ou l’exécution de scripts automatisés.

Lorsqu’un utilisateur exécute la commande kinit, il est invité à saisir son nom d’utilisateur et son mot de passe. Une fois l’authentification réussie, kinit demande au serveur Kerberos un ticket de sécurité pour l’utilisateur. Ce ticket est stocké dans un cache local sur le système de l’utilisateur, et peut être utilisé pour accéder aux services réseau qui requièrent une authentification Kerberos.

14.Intégration dans l’AD et implémentation du DNS

Exécutez la commande suivante:

# net ads join -k -U username_ad
Enter username_ad's password:
Using short domain name -- DOMAIN
Joined 'TEMPLATE-LINUX' to dns domain 'domain.local'

La commande net ads join -k -U est utilisée pour joindre un ordinateur Linux à un domaine Active Directory (AD) en utilisant Kerberos pour l’authentification.

Voici la signification des options utilisées dans la commande :

ads : spécifie que le domaine Active Directory sera utilisé comme source d’authentification et de contrôle d’accès.
join : spécifie que le serveur Linux va se joindre au domaine Active Directory.
-k : spécifie que la commande doit utiliser Kerberos pour l’authentification.
-U : spécifie l’utilisateur qui exécute la commande. L'utilisateur doit être membre du groupe d’administrateurs du domaine Active Directory pour pouvoir joindre l’ordinateur Linux au domaine. Lorsque la commande net ads join est exécutée, l’utilisateur est invité à saisir le mot de passe de l’utilisateur spécifié dans l’option -U. Une fois l’authentification réussie, la commande utilise les informations du compte de l’utilisateur pour joindre l’ordinateur Linux au domaine Active Directory.

Après la réussite de la commande, le serveur Linux peut être utilisé pour accéder aux ressources du domaine Active Directory telles que les fichiers partagés et les applications qui utilisent l’authentification Kerberos. Les utilisateurs du domaine Active Directory peuvent également accéder à l’ordinateur Linux en utilisant leur compte de domaine Active Directory.

Un peu plus loin

Bien que la procédure soit fonctionnelle et peut être mise en place en production, il est envisageable d’aller plus loin dans la configuration des Active Directory afin de valider les audits de sécurité pouvant être fait dans les grands groupes. Je ne détaille pas cette partie, car elle est pour moi hors scope de cet article qui concerne plus les AD.

Conclusion

Voilà votre première VM Linux devrait être liée à votre domaine contrôler par un Active Directory. Bien entendu vous avez fait ça à la main, ce qui est top pour apprendre, mais vous aurez certainement de souhait d’industraliser cette tâche qui peut être chronophage, il ne vous reste donc plus qu’à rédiger un rôle ansible 😀 Fais-le moi savoir si tu as besoin !