Comment joindre un système Linux à un domaine Active Directory

Active Directory (AD) de Microsoft est le service d'annuaire de référence pour de nombreuses organisations. Si vous et votre équipe êtes responsables d'un environnement mixte Windows et Linux, vous souhaiterez probablement centraliser l'authentification pour les deux plates-formes. J'expliquerai comment ajouter des ordinateurs Linux à un domaine Active Directory.

Active Directory et la nécessité d'une gestion centralisée des accès

Active Directory de Microsoft, plus connu sous le nom d'AD, détient la part du lion du marché de la gestion des accès d'entreprise depuis de nombreuses années maintenant. Il est utilisé par des institutions et des individus du monde entier pour contrôler de manière centralisée l'accès aux ressources appartenant à l'organisation. Il vous donne la possibilité de gérer les utilisateurs, les mots de passe, les ressources telles que les ordinateurs, et de dicter qui a accès à quoi. Pour certains d'entre vous qui lisez cet article, en particulier ceux qui travaillent dans de grandes institutions, vous avez déjà interagi avec AD. En règle générale, l'interaction utilise un ensemble d'informations d'identification de connexion pour se connecter à n'importe quel poste de travail de l'organisation. Ce n'est que la pointe d'un grand iceberg.

Imaginez un ensemble de 40 systèmes informatiques et 70 utilisateurs dans une entreprise. Certains employés effectuent des quarts de travail tandis que d'autres travaillent des heures régulières. Certains ont accès à l'impression; d'autres non. La méthode de travail traditionnelle consiste à créer des comptes d'utilisateurs locaux sur chaque ordinateur auquel un utilisateur doit accéder. Imaginez la charge de travail de l'équipe d'assistance aux utilisateurs finaux. Lorsqu'un utilisateur change son mot de passe pour une raison quelconque, cet utilisateur doit changer le mot de passe sur tous les ordinateurs auxquels il avait précédemment accès, pour que les choses restent synchronisées. En un rien de temps, il y aura du chaos. Maintenant, imaginez que deux membres du personnel démissionnent. Je n'ai pas besoin de vous dire le travail monotone qui doit être répété chaque fois qu'il y a un changement dans les effectifs ou dans les postes de travail. Pour les équipes informatiques, c'est un cauchemar. Le temps qui pourrait être utilisé pour des tâches innovantes est désormais consacré à réinventer la roue. Je n'ai même pas parlé de la gestion des accès aux imprimantes.

C'est là qu'un service d'annuaire tel qu'Active Directory prospère. Cela peut littéralement être une bouée de sauvetage. Avec Active Directory, chaque utilisateur est créé de manière unique en tant qu'objet dans une base de données centrale, avec un seul ensemble d'informations d'identification. Chaque système informatique est également créé en tant qu'objet. Automatiquement, chaque utilisateur peut accéder à chaque poste de travail avec le même ensemble d'informations d'identification. Toutes les modifications de compte qui doivent être apportées sont effectuées une seule fois dans la base de données centrale. Les membres du personnel peuvent accéder aux imprimantes en utilisant le même ensemble d'informations d'identification. Le mécanisme d'authentification des imprimantes peut être couplé à AD pour y parvenir. Des utilisateurs satisfaits, une équipe informatique heureuse.

À l'aide de groupes et d'unités organisationnelles, l'accès à diverses ressources peut être personnalisé et maintenu. C'est encore mieux. Ce répertoire peut stocker les numéros de téléphone et les adresses e-mail du personnel et peut être étendu pour stocker d'autres informations. Et si quelqu'un démissionne ? Aucun problème. Désactivez simplement le compte de l'utilisateur. L'accès de cette personne à toutes les ressources est annulé sur-le-champ. Plus l'organisation est grande, plus la nécessité d'une gestion centralisée est grande. Cela fait gagner du temps; ça sauve les émotions.

Fondamentalement, un service d'annuaire n'est qu'un moyen organisé de répertorier toutes les ressources d'une organisation tout en facilitant l'accès à ces ressources. Fondamentalement, AD est une sorte de base de données distribuée, accessible à distance via le protocole LDAP (Lightweight Directory Access Protocol). LDAP est un protocole ouvert permettant d'accéder à distance aux services d'annuaire via un support orienté connexion tel que TCP/IP. AD n'est pas le seul service d'annuaire basé sur la norme x.500 ou accessible via LDAP. Les autres services d'annuaire incluent OpenLDAP et FreeIPA. Cependant, AD est un service Windows mature qui est intégré aux systèmes Windows Server. En d'autres termes, ce sera le gagnant automatique lorsque votre organisation possède de nombreux systèmes Windows. C'est une des raisons de son omniprésence. Les services d'annuaire tels que FreeIPA sont basés sur Linux et fournissent un excellent service pour une écurie Linux. Lorsque le caoutchouc prend la route, le choix se résume à lequel des deux vous pouvez configurer rapidement, compte tenu de votre environnement actuel et des compétences de votre équipe.

[ Vous pourriez également aimer : L'interopérabilité Windows et Linux :un aperçu de Samba ]

Mais que se passe-t-il lorsque vous choisissez AD, que vous disposez de quelques serveurs CentOS et que vous ne souhaitez pas conserver un ensemble d'informations d'identification distinct pour vos utilisateurs Linux ? Ce surcoût est entièrement évitable. Ce que vous devez faire est de joindre les serveurs Linux au domaine AD, comme vous le feriez avec un serveur Windows.

Si c'est ce que vous devez faire, lisez la suite pour savoir comment le faire. Il est possible de joindre un système Windows à un domaine FreeIPA, mais cela sort du cadre de cet article.

Pré-requis

Cet article présuppose que vous avez au moins une certaine expérience de niveau d'introduction avec Active Directory, en particulier autour de la gestion des comptes d'utilisateurs et d'ordinateurs. En dehors de cela, les exigences évidentes suivantes doivent être remplies :

Un compte dans AD qui dispose des privilèges nécessaires pour joindre un système au domaine.
Un serveur Linux (un serveur CentOS 7 a été utilisé pour cette démonstration).
Un contrôleur de domaine.
Assurez-vous que votre serveur Linux sait comment trouver le contrôleur de domaine via DNS.

Pour rendre cet article plus facile pour tout le monde, voici une liste de détails clés. C'est ainsi que le laboratoire que j'ai utilisé pour cette rédaction est configuré, vous devez donc modifier en conséquence.

Nom de domaine AD :Hope.net
Compte utilisateur pour rejoindre le domaine :fkorea (Fullname - Fiifi Korea)
Nom d'hôte du serveur Linux :centy2

Packages à installer

Pour cette configuration, le package essentiel à installer est realmd . Mis à part realmd , de nombreux packages doivent être installés pour que cela fonctionne.

# yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python

Realmd fournit un moyen simplifié de découvrir et d'interagir avec les domaines Active Directory. Il utilise sssd pour effectuer les recherches réelles requises pour l'authentification à distance et d'autres travaux lourds d'interaction avec le domaine. Par souci de brièveté, je ne m'attarderai pas sur les autres packages de la liste.

Cependant, pour ceux qui s'intéressent aux détails, une recherche rapide sur Google devrait être d'une grande aide.

Realmd (interaction avec le domaine)

Maintenant que tous les packages ont été installés, la première chose à faire est de joindre le système CentOS au domaine Active Directory. Nous utilisons le domaine realm candidature pour cela. Le realm client est installé en même temps que realmd . Il est utilisé pour joindre, supprimer, contrôler l'accès et accomplir de nombreuses autres tâches. Voici la syntaxe attendue pour une jointure de domaine simple :

realm join --user=[domain user account] [domain name]

L'espace entre le compte d'utilisateur et le compte de domaine n'est pas une faute de frappe. En insérant les détails correspondants, nous obtenons la commande suivante :

# realm join --user=fkorea hope.net

Fournissez le mot de passe lorsque l'invite apparaît et attendez la fin du processus.

Ne laissez pas la courte absence de sortie vous tromper. Il y a un certain nombre d'opérations qui se déroulent dans le cadre du processus. Vous pouvez ajouter le -v commutateur pour une sortie plus détaillée. Cependant, la meilleure façon de vérifier si l'ordinateur est maintenant membre du domaine est d'exécuter la realm list commande. La commande tente d'afficher l'état actuel du serveur par rapport au domaine. C'est un moyen rapide et efficace de savoir quels groupes ou utilisateurs peuvent accéder au serveur.

Jetez un œil à sa sortie :

Il est également assez trivial de placer l'objet informatique AD nouvellement créé dans une unité organisationnelle (UO) spécifique dès le départ. Je vais laisser cela pour une lecture plus approfondie, mais, comme astuce, vous pouvez consulter la page de manuel. Utilisation du domaine realm client, vous pouvez accorder ou révoquer l'accès aux utilisateurs et aux groupes du domaine. Une plongée profonde sur l'utilisation de realmd d'une manière plus fine suffit pour faire un autre article. Cependant, je ne manquerai pas de retenir quelques paramètres à votre attention, à savoir le logiciel client et le logiciel serveur. À présent, vous devriez comprendre pourquoi nous avons dû installer autant de packages.

Pour quitter complètement le domaine, vous avez besoin de deux mots :realm leave

Configuration supplémentaire

Ainsi, maintenant que le serveur Linux fait partie du domaine AD, les utilisateurs du domaine peuvent accéder au serveur avec leurs informations d'identification habituelles. Nous avons terminé, n'est-ce pas ? Mauvais. "Quel est le problème?" Je vous entends dire.

Eh bien, pour commencer, c'est la configuration de base pour vous permettre de démarrer. Mais l'expérience est maladroite, c'est le moins qu'on puisse dire. Nous devons configurer davantage le service pour lui donner une véritable sensation AD. Cela devrait être comme si vous vous connectiez à un poste de travail Windows 10 appartenant à un domaine.

Deuxièmement, il y a le gros éléphant dans la salle pour les administrateurs système appelé Dynamic DNS Updates (DynDNS). S'il n'est pas configuré correctement, nous créons une surcharge supplémentaire en devant maintenir manuellement les enregistrements DNS. Pour un environnement qui dépend fortement du DNS, cela pourrait être un problème. Pour les systèmes Windows, joindre un système au domaine signifie que deux entrées sont automatiquement gérées et maintenues sur le serveur DNS. Lorsque les adresses IP changent, le changement est automatiquement reflété dans le DNS. Cela signifie que vous pouvez modifier les adresses IP des systèmes sans encourir le coût de la maintenance manuelle. Cela n'aura de sens que pour les personnes qui tirent déjà parti du DNS dans leur environnement. Outre les gains de productivité notables de l'automatisation, il est utile que les environnements Windows et Linux fonctionnent de la même manière.

Le troisième problème est le nettoyage DNS. Dans un domaine Active Directory, le DNS est généralement fourni par les contrôleurs de domaine. Chaque système associé au domaine possède une entrée DNS automatique avec une adresse IP correspondante. C'est super pratique. Automatiquement, à un intervalle spécifié, les enregistrements DNS obsolètes sont supprimés pour éviter les paquets mal acheminés et également prendre soin des objets informatiques supprimés. C'est ce qu'on appelle le nettoyage , et il n'est pas activé par défaut dans AD. Cependant, s'il est activé, nous devons le configurer. En règle générale, l'intervalle de nettoyage est de sept jours. Si, après cette période, il n'y a pas eu de mise à jour de l'enregistrement, il est supprimé, sauf s'il s'agit d'un enregistrement statique. Pour les systèmes Windows, la fonction de mises à jour dynamiques est automatiquement configurée. Cependant, avec les serveurs Linux, quelques modifications doivent être apportées. Sans cela, nous aurons des services qui tomberont après un certain temps car leurs enregistrements sont supprimés du DNS et personne ne sait comment accéder à leurs composants.

Maintenant que nous connaissons certains des problèmes potentiels que nous devons résoudre, examinons certaines des choses que nous pouvons modifier pour offrir une expérience plus transparente à l'utilisateur final et à l'administrateur système.

SSSD (connexions plus faciles et mises à jour dynamiques)

sssd sur un système Linux est chargé de permettre au système d'accéder aux services d'authentification à partir d'une source distante telle qu'Active Directory. En d'autres termes, il s'agit de l'interface principale entre le service d'annuaire et le module demandant les services d'authentification, realmd . Son fichier de configuration principal se trouve dans /etc/sssd/sssd.conf . En fait, c'est le fichier de configuration principal que nous allons modifier.

Jetons un coup d'œil à son contenu avant la configuration. Une fois que vous avez rejoint le domaine, il est immédiatement modifié pour contenir les informations minimales requises pour une connexion réussie. Mon fichier ressemblait à ceci :

Afin de résoudre les trois problèmes que j'ai mentionnés précédemment, modifiez votre fichier pour qu'il ressemble à celui ci-dessous :

La plupart des options sont explicites et vous pouvez modifier la vôtre en conséquence pendant que nous passons en revue ce que représentent certaines des options clés. Plus d'informations sur toutes les options peuvent être obtenues en consultant la page de manuel. Je pense que c'est bien écrit. Tapez simplement man 5 sssd.conf à la ligne de commande. Vous pouvez également consulter la page de manuel pour sssd_ad pour plus d'informations.

Tout d'abord, le fichier de configuration est séparé en deux sections. La section globale, sous [ssd] et la section des options spécifiques au domaine, [domain/[domain name]] .

La section globale contient des options qui affectent le comportement général de sssd , telles que les informations de version et les services associés. Un paramètre clé de cette section est illustré ci-dessous :

suffixe_domaine_par_défaut - Définissez ceci sur le nom de domaine si vous ne souhaitez pas avoir à saisir le nom complet du compte d'utilisateur lors de la connexion. Au lieu de devoir saisir [email protected] toujours, vous pouvez simplement taper fkorea et le mot de passe. Cela aide beaucoup lorsque vous avez un long nom de domaine.

La section spécifique au domaine contient des paramètres spécifiques au domaine que vous avez rejoint. Les paramètres clés sont :

access_provider - Vous permet de sélectionner un fournisseur optimisé et utilisé pour interagir avec les serveurs AD à des fins d'authentification. Il doit être défini sur ad . Les autres valeurs pouvant être utilisées ici sont ldap et ipa , en supposant que vous utilisez ces services d'annuaire.
id_provider - Permet de sélectionner un fournisseur optimisé et utilisé pour interagir avec les serveurs AD à des fins d'identification. Il doit être défini sur ad .
ad_hostname - Il doit s'agir du nom d'hôte complet du serveur. Il doit être défini si le nom d'hôte du système est autre chose que le nom de domaine complet. Si ce n'est pas défini et que le sssd n'a pas accès au nom d'hôte complet, les mises à jour dynamiques échoueront.
ad_domain - Il doit s'agir du nom de domaine complet (hope.net dans ce cas).
cache_credentials - Cela permet aux utilisateurs AD de se connecter lorsque le contrôleur de domaine est hors ligne. Lorsque ce paramètre est défini sur true , les informations d'identification sont mises en cache pendant une période telle que l'authentification n'échoue pas lorsque le serveur principal est hors ligne. La période de stockage est également paramétrable.
fallback_homedir - Cela vous aide à définir un répertoire personnel pour les utilisateurs AD qui n'ont pas d'attribut de répertoire personnel dans AD. Ceci est différent de override_home paramètre qui fonctionne lorsqu'un répertoire personnel est défini dans AD pour les utilisateurs.
dyndns_update - Cela active les mises à jour DNS dynamiques et accepte soit true ou faux comme valeur. Lorsque les mises à jour dynamiques sont activées, les mises à jour se produisent principalement dans trois conditions :
- Lorsque le serveur Linux redémarre.
- Lorsque le fournisseur se connecte.
- Lorsque l'intervalle d'actualisation est dû.
dyndns_refresh_interval - Cette valeur est en secondes avec un minimum pratique de 60 secondes. Il accepte les valeurs entières et a une valeur par défaut de 24 heures (86400s). Dans cet exemple, nous l'avons défini sur 12 heures. Si rien d'autre ne déclenche une mise à jour, une mise à jour est régulièrement effectuée entre.
dyndns_update_ptr - Une valeur booléenne qui spécifie si l'enregistrement PTR associé doit être mis à jour à chaque cycle de mise à jour. Les enregistrements PTR sont utilisés pour les recherches inversées, et à moins qu'il n'y ait une bonne raison, cela doit être défini sur true .
dyndns_auth - Spécifie si les mises à jour dynamiques doivent être effectuées en toute sécurité ou non. Le réglage dépend du mode accepté par AD. Si AD est défini sur Accepter les mises à jour sécurisées uniquement , cette valeur doit être définie sur GSS-TSIG . Si ce n'est pas le cas, et que vous ne vous souciez pas des avantages de sécurité des mises à jour dynamiques sécurisées (malgré l'avertissement fort dans AD), cette valeur peut être définie sur aucune .

Une fois la configuration terminée, redémarrez sssd pour appliquer les paramètres immédiatement.

# systemctl restart sssd

À ce stade, nous sommes fixés. Nous pouvons maintenant nous connecter comme nous le ferions sur un poste de travail ou un serveur Windows.

Visudo (accorder des privilèges d'administrateur)

Les utilisateurs auxquels l'accès est accordé disposent d'un accès non privilégié au serveur Linux. À toutes fins utiles, tous les comptes Active Directory sont désormais accessibles au système Linux, de la même manière que les comptes locaux créés en mode natif sont accessibles au système. Vous pouvez maintenant effectuer les tâches régulières de l'administrateur système consistant à les ajouter à des groupes, à en faire les propriétaires des ressources et à configurer d'autres paramètres nécessaires. Si l'utilisateur essaie une activité qui nécessite sudo accès, l'erreur familière est présentée. Comme on peut le voir dans l'encart, notre utilisateur n'est pas dans les sudoers fichier.

Dans cette optique, nous pouvons éditer les sudoers fichier directement pour leur accorder des privilèges de superutilisateur. Ceci n'est pas un article sur l'octroi de privilèges de superutilisateur, mais nous pouvons utiliser le visudo outil pour interagir en toute sécurité avec les sudoers fichier.

Alternativement, nous aurions pu simplement ajouter l'utilisateur à la wheel grouper. Le fait est que le compte utilisateur est maintenant disponible pour être utilisé par le système.

[ Le réseau devient incontrôlable ? Découvrez l'automatisation du réseau pour tous, un livre gratuit de Red Hat. ]

Récapitulez

Essayez ceci dans votre organisation ou environnement de laboratoire. Il est évident que je n'ai fait qu'effleurer la surface de ce sujet, mais cela vous mènera assez loin dans le processus. Consultez la documentation correspondante si vous souhaitez explorer des options non couvertes dans cet article.

Joindre un système Linux à un domaine Active Directory vous permet d'obtenir le meilleur des deux mondes. Le processus est très simple et peut être scripté à l'aide de Bash ou automatisé à l'aide d'Ansible, en particulier lors de la configuration initiale du système. Si vous gérez toujours un groupe de plus de cinq systèmes sans service d'annuaire et pour une bonne raison, rendez-vous service et installez-en un. Vous pourrez me remercier plus tard.