Gestion d'identité avec FreeIPA

FreeIPA fournit une solution centralisée pour l'authentification, l'autorisation et les informations de compte, en stockant les données des utilisateurs, groupes, hôtes et autres objets nécessaires à la gestion de la sécurité d'un réseau d'ordinateurs. Un mécanisme de Single-Sign-On (SSO) est intégré au travers de Kerberos. Une autorité de certification étend les capacités d'authentification en fournissant des certificats X509. Les noms de machines sont aussi gérés au travers d'un DNS Bind, s'appuyant sur 389 Directory Server pour stocker les zones et enregistrements.

Plusieurs serveurs FreeIPA peuvent être configurés en mode multimaître pour assurer la montée en charge et la redondance. 389 Directory Server est le module de stockage principal des données et c'est lui qui fournit nativement une réplication multimaître.

En bonus, FreeIPA s'administre au travers d'une interface web et/ou d'un utilitaire en ligne de commandes. Ainsi, tout le monde y trouve son compte.

Et pour couronner toutes ces fonctionnalités, nous pouvons interconnecter FreeIPA avec un domaine Active Directory pour tirer parti de toute la gestion d'identité que vos camarades administrateurs Windows (ou vous-même) ont mis en œuvre. Cela passe par la mise en place d'une relation d'approbation, qui permet notamment d'utiliser des tickets Kerberos sur les deux domaines.

1 Installation de FreeIPA

Pour cet article, la plateforme de virtualisation s'appuie sur oVirt [2] et nous créons une machine virtuelle avec 1 vCPU, 1 Go de mémoire et 10 Go de disque. Au niveau système d'exploitation, nous utilisons CentOS 7.

Pour commencer, nous donnons un nom à notre machine virtuelle. Pour cela, nous disposons de l’utilitaire hostnamectl :

FreeIPA fournit une solution de gestion DNS et nous allons l’installer, mais en attendant, le serveur doit être capable de résoudre son propre nom de machine. Le moyen le plus efficace est d’ajouter un enregistrement dans /etc/hosts :

Nous mettons à jour nos serveurs et installons quelques paquets additionnels. Ensuite, nous redémarrons notre serveur pour être sûrs que la configuration est appliquée :

Nous installons les paquets nécessaires à FreeIPA (et les plus de 300 dépendances) :

L’étape la plus délicate est le déploiement de FreeIPA. En effet, c’est le moment où nous spécifions les options globales qui seront inscrites dans tous les composants : annuaire LDAP, autorité de certification, etc. Il est possible de les mettre à jour plus tard, mais cela peut devenir compliqué. Pour l’environnement du laboratoire, tout se fait en une commande :

Cette ligne de commandes est assez longue et mérite quelques explications :

- --unattended : cette option est plutôt évidente ; l'installation ne sera pas interactive ;

- --setup-dns : FreeIPA gère le DNS pour notre environnement ;

- --domain : le nom de domaine que nous souhaitons gérer ;

- --reverse-zone : la zone inverse que nous souhaitons gérer (optionnel) ;

- --hostname : le nom que nous souhaitons donner à notre serveur FreeIPA. La valeur est reprise pour créer le premier enregistrement d'hôte dans l'annuaire, ainsi que les entrées DNS : le serveur de nom de la zone créée pendant l'installation. Il faut utiliser le FQDN ;

- --ip-address : pour créer l'enregistrement A du serveur de nom, nous devons fournir son adresse IP ;

- --forwarder : le serveur DNS que FreeIPA contactera pour les requêtes qu'il ne peut résoudre ;

- --ssh-trust-dns : FreeIPA peut stocker les clés SSH des serveurs et exposer les empreintes desdites clés au niveau du serveur DNS via des enregistrements SSHFP (SSH FingerPrint). Les clients ne demandent donc plus aux utilisateurs de valider les empreintes, puisqu'ils font confiance au DNS. Ce mécanisme peut être renforcé par l'usage de DNSSEC : je vous renvoie à la documentation FreeIPA [3] ;

- --realm : le nom du royaume Kerberos associé à notre domaine DNS ;

- --idstart, --idmax : les bornes de la plage d'UID pour les comptes utilisateurs. Nous les limitons aux UID habituellement rencontrés sur les systèmes GNU/Linux ;

- --ds-password, --admin-password : respectivement les mots de passe de l'administrateur de l'annuaire et du compte « admin » de FreeIPA.

L'installation prend un peu plus d'une minute si votre serveur dispose de suffisamment d'entropie. L'ensemble des étapes sont décrites par l'installateur et celui-ci se termine en nous listant les ports à ouvrir au niveau du pare-feu local. Nous ouvrons donc ces ports pour que les services puissent être accessibles :

Arrivés ici, notre service FreeIPA est parfaitement fonctionnel et nous pouvons y accéder via l’URL : https://ipa001.lab.evenit.info/ipa/ui. Si nous ouvrons cette URL dans notre navigateur, celui-ci se plaint que le certificat n’est pas valide, car non signé par une autorité de certification de confiance. Et c’est normal : le certificat serveur présenté a été signé par l’autorité de certification intégrée à FreeIPA. Pour éviter ce message et renforcer la sécurité de votre infrastructure, nous ne créons pas d’exception de sécurité, mais importons le certificat de l’autorité de certification racine intégrée à FreeIPA. Pour cela, nous extrayons le certificat du conteneur PKCS12 généré lors de l’installation :

La commande nous demande le mot de passe de l'archive PKCS12 : il s'agit de celui du compte « admin ». Nous mettons le fichier contenant le certificat à disposition sur le serveur web intégré à FreeIPA :

Il suffit de le télécharger via l’URL http://ipa001.lab.evenit.info/lab.evenit.info-ca.pem et de l’installer dans notre navigateur préféré. Si nous actualisons la page d’accueil de FreeIPA, le message d’alerte disparaît et nous pouvons nous connecter en tant qu' « admin ».

2 Premier contact avec FreeIPA

Nous laissons de côté l’interface graphique et reprenons les opérations depuis la ligne de commandes. La commande ipa s’appuie sur l’API de FreeIPA et expose l’ensemble des opérations. L’authentification se base sur Kerberos, donc nous devons obtenir les jetons d’authentification avant de pouvoir réaliser une quelconque opération.

La première chose à faire est d'obtenir un ticket Kerberos, qui nous permettra de réaliser les futures opérations sans entrer de mot de passe :

Nous vérifions que le TGT (Ticket Granting Ticket) Kerberos a bien été obtenu, via la commande klist :

Notre première opération sera de récupérer la keytab de l'utilisateur admin (il est conseillé d'en profiter pour la sauvegarder sur un périphérique externe sécurisé). La keytab nous permettra de nous authentifier, et de récupérer des tickets Kerberos, sans mot de passe :

Pour vérifier le bon fonctionnement, nous supprimons les tickets Kerberos que nous avons obtenus précédemment, via la commande kdestroy. Nous initions à nouveau une session Kerberos avec la keytab. Pour cela, nous utilisons les -k, qui indiquent que nous utilisons une keytab, et -t, qui spécifie la keytab à utiliser. La commande klist nous permet de vérifier nos tickets :

À partir d'ici, nous allons intensivement utiliser la commande ipa. Il s'agit d'un wrapper pour l'API de FreeIPA qui permet de manipuler l'ensemble des items gérés par FreeIPA. La page de manuel est un bon point de départ, mais grâce au paquet bash-completion, il nous suffit de taper ipa, puis de taper deux fois sur la touche tabulation pour obtenir la liste des actions disponibles. Pour chacune d'elles, l'option --help permet de connaître la syntaxe et les options.

Nous pouvons, par exemple, lister les hôtes présents dans IPA, avec la commande suivante :

À cette étape, il n'y a qu'un seul serveur : notre serveur FreeIPA. Nous constatons d'ailleurs que l'empreinte de la clé SSH du serveur est bien présente. Elle sera utile plus tard (suspens !).

Nous pouvons aussi afficher la configuration globale de FreeIPA :

Parmi les éléments de configuration, nous constatons que le shell par défaut est /bin/sh. Nous préférons que tous les utilisateurs utilisent /bin/bash. Pour cela, nous modifions la configuration globale de FreeIPA :

Nous pouvons maintenant nous intéresser aux comptes utilisateurs.

3 Gestion des comptes et des droits

Commençons par quelque chose de facile en listant les comptes utilisateurs :

Il n'y a pour le moment qu'un seul compte : admin. Les informations obtenues sont classiques et se passent de commentaire. La seule information notable est que nous avons généré une keytab pour l'utilisateur : « Clés Kerberos disponibles: True ».

Nous créons un compte utilisateur qui sera utilisé comme administrateur :

Un certain nombre d'attributs de l'utilisateur peuvent être positionnés lors de la création d'un utilisateur. La commande ipa help user-add vous indiquera les options disponibles. Nous avons donc laissé FreeIPA utiliser les paramètres par défaut, notamment l'adresse de courriel qui est générée à partir de l'identifiant de connexion et du nom de domaine DNS.

Nous pouvons vérifier tout de suite que le système d'exploitation du serveur FreeIPA connaît l'utilisateur :

Le mot de passe de l'utilisateur a été positionné de manière temporaire et doit être changé à la première connexion. Nous nous connectons donc une première fois pour changer le mot de passe. Pour cela, nous utilisons SSH et nous pouvons d'ailleurs constater que l'on ne nous demande pas d'accepter la clé SSH du serveur : SSSD l'a récupéré via le DNS et l'a stocké dans /var/lib/sss/pubconf/known_hosts.

Une fois le mot de passe modifié, la connexion est interrompue. Nous la relançons pour valider que notre mot de passe est bien fonctionnel :

Lors de la connexion, un TGT Kerberos est aussi obtenu :

Ce TGT est particulièrement intéressant, car il permet notamment de se connecter au travers du protocole SSH. Nous pouvons le vérifier en nous connectant récursivement au serveur. Aucun mot de passe ne nous est demandé et nous pouvons voir que nous avons obtenu un ticket Kerberos pour le service host/ipa001.lab.evenit.info@LAB.EVENIT.INFO :

Nous reviendrons sur la gestion des droits avancés dans un prochain article.

4 Configuration d'un client

Avoir des utilisateurs pouvant se connecter à des serveurs, c'est mieux. Nous allons donc intégrer une machine cliente dans notre environnement. Fort originalement, nous créons une machine virtuelle CentOS 7 et nous lui donnons le nom d'hôte client.lab.evenit.info.

Sur l'un des serveurs FreeIPA, nous ajoutons le nouveau serveur :

La commande ajoute un hôte en spécifiant son FQDN et son adresse IP, ainsi qu'un mot de passe. Le FQDN et l'adresse IP permettent de créer les enregistrements DNS et le principal Kerberos. Le mot de passe est temporaire et servira à terminer la configuration depuis le client.

Sur le client, nous ajoutons l'adresse des serveurs FreeIPA dans /etc/hosts pour ne pas dépendre du DNS :

Sur le client IPA, nous installons le paquet ipa-client et ses nombreuses dépendances :

Puis nous configurons le client :

La commande est assez explicite et les options sont similaires à la commande d'installation du serveur. Le mot de passe est utilisé, ce qui a pour effet la désactivation de celui-ci en fin de configuration.

Nous pouvons vérifier assez simplement que la configuration a fonctionné en nous connectant en tant que fdupont. Un test complémentaire consiste en l'affichage des informations de la machine sur l'un des serveurs FreeIPA :

Un autre test intéressant est de vérifier que l'utilisateur précédemment créé est visible par ce client :

Conclusion

Au terme de ces quelques pages, j'espère vous avoir donné envie d'expérimenter FreeIPA dans votre environnement et de découvrir les fonctionnalités que je n'ai pas abordées. Comme cela ne consomme que peu de ressources, vous pouvez vous entraîner sur des machines virtuelles.

Personnellement, FreeIPA (ou son pendant commercial Red Hat Identity Management) est le premier composant que je déploie. Il m'apporte les fondements d'une infrastructure DNS, une authentification centralisée, voire du SSO, basée sur Kerberos et la possibilité de mettre en place une politique de contrôle d'accès riche. Et, comme je n'apprécie pas les certificats auto-signés, je fais en sorte que les services que je déploie disposent d'un certificat émis par FreeIPA.

Je voudrais aussi remercier François Cami, un très compétent collègue, qui m'a fait l'honneur de relire cet article. Si je l'avais écouté, vous auriez eu un livre complet sur FreeIPA.

Références

[1] Site Web du projet FreeIPA : http://www.freeipa.org/

[2] Site web du projet oVirt : http://www.ovirt.org/

[3] Documentation du support de DNSSEC dans FreeIPA : http://www.freeipa.org/page/V4/DNSSEC_Support