Gestion d'identité avec FreeIPA

GNU/Linux Magazine n° 186 | octobre 2015 | Fabien Dupont
Creative Commons
  • Currently 0 out of 5 Stars.
0
Thank you for rating!
You have already rated this page, you can only rate it once!
Your rating has been changed, thanks for rating!
Souvent, chez mes clients, je croise deux solutions pour la gestion des utilisateurs et des machines : Microsoft Active Directory et OpenLDAP. Le second fournit cependant un niveau fonctionnel beaucoup plus faible. Dans cet article, je vous propose de découvrir FreeIPA, une solution de gestion d'identité offrant de nombreux services : DNS, NTP, Kerberos, LDAP, IGC, règles HBAC, sudo, etc.
Résumé

FreeIPA [1]est une solution de gestion des informations de sécurité intégrée. La solution propose un joli portail qui permet de déléguer une partie de la gestion des comptes utilisateurs à des personnes non techniques. Dans cet article, je vais vous guider dans l'installation du serveur FreeIPA, la gestion des comptes utilisateurs et la configuration d'un client. Et parce que faire des copies d'écran n'est vraiment pas mon truc, tout se fera en ligne de commandes :)

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.

Attention !

Si vous souhaitez adapter cet article pour une production avec support éditeur, vous pouvez le transposer sur Red Hat Enterprise Virtualization, Red Hat Enterprise Linux 7 et Red Hat Identity Management.

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

# hostnamectl set-hostname 'ipa001.lab.evenit.info'

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 :

# echo '172.16.0.21 ipa001.lab.evenit.info ipa001' >> /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 :

# yum upgrade -y

# yum install -y vim-enhanced screen rhevm-guest-agent-common bash-completion

# reboot

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

# yum install -y ipa-server bind bind-dyndb-ldap

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 :

# ipa-server-install --unattended \

   --setup-dns --domain lab.evenit.info --reverse-zone 16.172.in-addr.arpa \

   --hostname ipa001.lab.evenit.info --ip-address 172.16.0.21 \

   --forwarder 8.8.8.8 --ssh-trust-dns \

   --realm LAB.EVENIT.INFO \

   --idstart 1000 --idmax 65535 --mkhomedir \

   --ds-password 'secret' --admin-password 'secret'

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 :

# for p in 53 80 88 389 443 464 636

do

   firewall-cmd --add-port ${p}/tcp

   firewall-cmd --add-port ${p}/tcp --permanent

done

# for p in 53 88 123 464

do

   firewall-cmd --add-port ${p}/udp

   firewall-cmd --add-port ${p}/udp --permanent

done

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 :

# openssl pkcs12 -clcerts -nokeys -in /root/cacert.p12 -out lab.evenit.info-ca.pem

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 :

# install -o root -g apache -m 0640 lab.evenit.info-ca.pem /var/www/html/

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 ».

Attention !

Par défaut, l’interface est restreinte à une zone de 960 pixels de large, ce qui peut parfois créer des problèmes d’affichage. Personnellement, je préfère que la zone d’affichage utilise la totalité de la fenêtre du navigateur. Je vous propose ci-dessous un patch qui permet cela :

--- /usr/share/ipa/ui/ipa.css    2014-11-13 11:25:08.986588137 +0100

+++ /usr/share/ipa/ui/ipa.css    2014-11-13 11:58:46.285825924 +0100

@@ -70,7 +70,7 @@

  left: 0;

  right: 0;

  bottom: 0;

- width: 960px;

+/* width: 960px;*/

  margin: 0 auto 0;

 }

 

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 :

# kinit -k -t /root/admin_lab.evenit.info.keytab admin@LAB.EVENIT.INFO

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

# klist

Ticket cache: KEYRING:persistent:0:0

Default principal: admin@LAB.EVENIT.INFO

Valid starting       Expires              Service principal

11/13/2014 11:40:20  11/14/2014 11:40:17  krbtgt/LAB.EVENIT.INFO@LAB.EVENIT.INFO

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 :

# ipa-getkeytab -s ipa001.lab.evenit.info \

   -p admin@LAB.EVENIT.INFO -k /root/admin_lab.evenit.info.keytab -P

Attention !

Note : L’option -P indique que nous souhaitons positionner le mot de passe de l'utilisateur lors de l'export de la keytab. Nous devons remettre le même mot de passe que spécifié lors de l'installation. Si nous ne mettons pas l'option -P, un mot de passe aléatoire est créé par FreeIPA. Ce n'est en soi pas un problème si nous avons toujours une sauvegarde de notre keytab.

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 :

# kdestroy

# kinit -k -t /root/admin_lab.evenit.info.keytab admin@LAB.EVENIT.INFO

# klist

Ticket cache: KEYRING:persistent:0:0

Default principal: admin@LAB.EVENIT.INFO

Valid starting       Expires              Service principal

11/13/2014 11:45:20  11/14/2014 11:45:17  krbtgt/LAB.EVENIT.INFO@LAB.EVENIT.INFO

À 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 :

# ipa host-find

--------------------

1 hôte correspondant

--------------------

  Nom de système: ipa001.lab.evenit.info

  Nom du principal: host/ipa001.lab.evenit.info@LAB.EVENIT.INFO

  Mot de passe: False

  Keytab: True

  Managed by: ipa001.lab.evenit.info

  Empreinte de clé publique SSH: 49:8F:6C:DA:91:C5:98:AC:67:9D:D4:75:16:9B:BF:C0 (ssh-rsa), 4F:19:75:4D:00:E8:63:03:FD:8E:AB:14:A4:A2:0D:17 (ssh-ed25519), AE:81:08:3F:F8:06:2C:45:0F:06:50:1E:05:1B:6F:14 (ecdsa-sha2-nistp256)

----------------------------

Nombre d'entrées renvoyées 1

----------------------------

À 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 :

# ipa config-show

  Longueur maximale de nom d'utilisateur: 32

  Base de répertoire utilisateur: /home

  Shell par défaut: /bin/sh

  Groupe utilisateur par défaut: ipausers

  Domaine par défaut pour les adresses courriel: lab.evenit.info

  Durée de recherche limite: 2

  Taille limite de recherche: 100

  Champs de recherche utilisateur: uid,givenname,sn,telephonenumber,ou,title

  Group search fields: cn,description

  Activer le mode migration: FALSE

  Base du sujet de certificat: O=LAB.EVENIT.INFO

  Notification avant expiration de mot de passe (jours): 4

  Fonctionnalités du greffon de gestion des mots de passe: AllowNThash

  Ordre des utilisateurs SELinux pour les cartes: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023

  Utilisateur SELinux par défaut: unconfined_u:s0-s0:c0.c1023

  Types de PAC par défaut: nfs:NONE, MS-PAC

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 :

# ipa config-mod --defaultshell=/bin/bash

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 :

# ipa user-find

--------------

1 user matched

--------------

 Identifiant de connexion: admin

 Nom: Administrator

 Répertoire utilisateur: /home/admin

 Shell de connexion: /bin/bash

 UID: 1000

 GID: 1000

 Compte désactivé: False

 Mot de passe: True

 Clés Kerberos disponibles: True

----------------------------

Nombre d'entrées renvoyées 1

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 :

# ipa user-add fdupont --first 'Fabien' --last 'Dupont' --password

Mot de passe:

Entrer à nouveau Mot de passe pour validation :

------------------------------

Utilisateur « fdupont » ajouté

------------------------------

  Identifiant de connexion: fdupont

  Prénom: Fabien

  Nom: Dupont

  Nom complet: Fabien Dupont

  Nom affiché: Fabien Dupont

  Initiales: FD

  Répertoire utilisateur: /home/fdupont

  GECOS: Fabien Dupont

  Shell de connexion: /bin/bash

  Principal Kerberos: fdupont@LAB.EVENIT.INFO

  Adresse courriel: fdupont@lab.evenit.info

  UID: 1001

  GID: 1001

  Mot de passe: True

  Membre des groupes: ipausers

  Clés Kerberos disponibles: True

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 :

# getent passwd fdupont

fdupont:*:1001:1001:Fabien Dupont:/home/fdupont:/bin/bash

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.

# ssh -l fdupont ipa001.lab.evenit.info

fdupont@ipa001.lab.evenit.info's password:

Password expired. Change your password now.

Last login: Sat Nov 13 12:02:28 2014 from ipa001.lab.evenit.info

WARNING: Your password has expired.

You must change your password now and login again!

Changement de mot de passe pour l'utilisateur fdupont.

Mot de passe actuel :

Nouveau mot de passe :

Retapez le nouveau mot de passe :

passwd : mise à jour réussie de tous les jetons d'authentification.

Connection to ipa001.lab.evenit.info closed.

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 :

# ssh -l fdupont ipa001.lab.evenit.info

fdupont@ipa001.lab.evenit.info's password:

Last login: Thu Nov 13 12:10:08 2014 from ipa001.lab.evenit.info

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

$ klist

Ticket cache: KEYRING:persistent:1001:krb_ccache_iaLNRPn

Default principal: fdupont@LAB.EVENIT.INFO

Valid starting       Expires              Service principal

11/13/2014 12:01:35  11/14/2014 12:10:35  krbtgt/LAB.EVENIT.INFO@LAB.EVENIT.INFO

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 :

$ ssh ipa001.lab.evenit.info

$ klist

Ticket cache: KEYRING:persistent:1001:krb_ccache_1S3tz27

Default principal: fdupont@LAB.EVENIT.INFO

Valid starting    Expires           Service principal

11/13/2014 12:10:56  11/14/2014 12:10:56  host/ipa001.lab.evenit.info@LAB.EVENIT.INFO

11/13/2014 12:10:35  11/14/2014 12:10:35  krbtgt/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 :

ipa001# ipa host-add client.lab.evenit.info \

    --password=secret --ip-address=172.16.0.123

---------------------------------

Hôte « client.lab.evenit.info » ajouté

--------------------------------------

  Nom de système: client.lab.evenit.info

  Mot de passe: True

  Keytab: False

  Managed by: client.lab.evenit.info

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 :

client# cat >> /etc/hosts << EOF

172.16.0.21 ipa001.lab.evenit.info ipa001

172.16.0.22 ipa002.lab.evenit.info ipa002

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

client# yum -y install ipa-client

Puis nous configurons le client :

client# ipa-client-install --unattended --password secret –mkhomedir –ssh-trust-dns

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 :

ipa001# ipa host-show client.lab.evenit.info

  Nom de système: client.lab.evenit.info

  Certificat: MIIEzTCCA7WgAwIBAgIBDDANBgkqhkiG9w0BAQsFADA7MRkwFwYDVQQKDBBIT01FLkVWRU5JVC5JTkZPMR4wHAYDVQQDDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTUwMzA3MDgwNzQ4WhcNMTcwMzA3MDgwNzQ4WjBAMRkwFwYDVQQKDBBIT01FLkVWRU5JVC5J...

6jlin3/jYsgr/MmLctRYSJ1bJdNgui2nLeY9VrcGWmnT

  Nom du principal: host/client.lab.evenit.info@LAB.EVENIT.INFO

  Mot de passe: False

  Keytab: True

  Managed by: client.lab.evenit.info

  Subjet: CN=client.lab.evenit.info,O=LAB.EVENIT.INFO

  Numéro de série: 12

  Numéro de série (hex): 0xC

  Émetteur: CN=Certificate Authority,O=LAB.EVENIT.INFO

  Pas Avant: Fri Nov 14 21:11:33 2014 UTC

  Pas Après: Mon Nov 14 21:11:33 2016 UTC

  Empreinte (MD5): e1:7e:7e:85:72:d6:12:31:1a:af:7f:31:33:c2:9e:86

  Empreinte (SHA1): 43:82:ca:fe:a6:68:02:4f:b4:64:46:6f:90:65:4c:9d:16:ef:11:b4

  Empreinte de clé publique SSH: 80:D2:63:4C:C3:74:5C:8E:EF:9B:09:EB:21:3C:96:18 (ssh-dss),

                                 3A:84:C0:6A:EA:27:B0:60:CF:89:BA:71:BA:78:6C:01 (ssh-rsa)

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

# getent passwd fdupont

fdupont:*:1001:1001:Fabien Dupont:/home/fdupont:/bin/bash

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