L'identité centralisée, nerf de la guerre en infrastructure Linux
Selon les derniers chiffres de la Linux Foundation, plus de 90 % des workloads cloud tournent sous Linux. Pourtant, la gestion centralisée des identités et des accès reste un angle mort dans de nombreuses infrastructures. Fichiers /etc/passwd dupliqués sur chaque machine, règles sudo éparpillées, authentification SSH par clé sans gouvernance : le constat est sans appel. La plupart des environnements Linux souffrent d'une fragmentation qui fragilise leur posture de sécurité.
FreeIPA répond à ce problème. Développé sous l'égide de Red Hat et maintenu par la communauté Fedora, ce projet open source combine annuaire LDAP (389 Directory Server), authentification Kerberos, autorité de certification (Dogtag), DNS et gestion de politiques dans une solution intégrée. Une alternative crédible à Active Directory, pensée nativement pour les systèmes Linux et UNIX.
Ce que FreeIPA apporte concrètement
Un annuaire LDAP taillé pour Linux
Au cœur de FreeIPA, le 389 Directory Server stocke utilisateurs, groupes, hôtes et services. Contrairement à un déploiement OpenLDAP classique qui nécessite une configuration manuelle du schéma et un assemblage de briques séparées, FreeIPA livre un schéma prêt à l'emploi, enrichi de classes d'objets spécifiques aux environnements Linux : groupes d'hôtes, règles sudo, politiques HBAC, mappage SELinux.
L'administration s'effectue via une interface web (migrée vers React depuis la version 4.12), une CLI complète (commande ipa) ou des appels RPC. Plus besoin de manipuler des fichiers LDIF à la main pour créer un utilisateur ou modifier un groupe.
SSO Kerberos : une authentification sans friction
FreeIPA intègre MIT Kerberos pour un Single Sign-On transparent à l'échelle de l'infrastructure. Une fois authentifié, un utilisateur obtient un ticket Kerberos (TGT) qui lui ouvre l'accès à l'ensemble des services enrôlés (SSH, partages NFS, bases de données) sans ressaisir son mot de passe.
Ce mécanisme diffère radicalement de l'approche Keycloak orientée OAuth2/OIDC qui cible les applications web. FreeIPA opère au niveau système : le SSO de l'infrastructure, pas celui des applications SaaS. Les deux solutions se complètent ; Keycloak peut s'appuyer sur FreeIPA comme backend d'identité pour couvrir le spectre applicatif.
D'après la documentation officielle du projet, FreeIPA 4.12 a introduit le support des passkeys FIDO2, qui autorise l'authentification par clé matérielle ou biométrie en complément du mot de passe Kerberos. Un apport notable pour les environnements sensibles.
HBAC : qui accède à quoi, sur quel hôte
La fonctionnalité la plus sous-estimée de FreeIPA reste le Host-Based Access Control (HBAC). Cette couche d'autorisation définit précisément quels utilisateurs (ou groupes) peuvent se connecter à quels hôtes (ou groupes d'hôtes), via quels services (SSH, console, FTP, etc.).
Exemple concret : une règle HBAC peut autoriser le groupe "développeurs" à se connecter en SSH uniquement sur les serveurs du groupe "staging", tout en leur interdisant l'accès aux machines de production. Cette granularité dépasse largement ce que donnent les fichiers /etc/security/access.conf gérés machine par machine.
Les règles HBAC s'appliquent en temps réel via SSSD sur chaque client enrôlé. Pas besoin de redéployer une configuration ou de pousser des fichiers : la politique reste centralisée et immédiatement effective. Pour les environnements qui adoptent une approche Zero Trust, ce contrôle d'accès granulaire forme une brique structurelle.
Sudo centralisé : la fin des sudoers éparpillés
La gestion des droits sudo via LDAP et SSSD est un sujet que nous avons déjà couvert en détail. FreeIPA pousse cette logique plus loin en intégrant nativement la gestion des règles sudo dans son interface.
Chaque règle sudo dans FreeIPA définit quatre dimensions :
- Qui : utilisateurs ou groupes autorisés
- Où : sur quels hôtes ou groupes d'hôtes
- Quoi : quelles commandes (ou groupes de commandes) sont autorisées
- Comment : avec ou sans mot de passe, en tant que quel utilisateur cible
# Créer une règle sudo complète via la CLI
ipa sudorule-add sysadmin-services --desc="Sysadmins: gestion services"
ipa sudorule-add-user sysadmin-services --groups=sysadmins
ipa sudorule-add-allow-command sysadmin-services \
--sudocmdgroups=service-management
ipa sudorule-add-host sysadmin-services --hostgroups=production
Ces règles sont stockées dans l'annuaire LDAP et distribuées aux clients via SSSD. Le cache local de SSSD joue un rôle critique : le système sudo continue de fonctionner même si le serveur FreeIPA est temporairement injoignable. L'administration gagne en cohérence sans sacrifier la résilience.
SSSD : le chaînon manquant côté client
SSSD (System Security Services Daemon) relie chaque machine Linux au serveur FreeIPA. Son rôle dépasse la simple résolution d'identité : il gère l'authentification Kerberos, applique les règles HBAC, distribue les politiques sudo et met en cache l'ensemble pour un fonctionnement offline.
L'enrôlement d'un client se fait en une commande :
ipa-client-install --mkhomedir --enable-dns-updates
Cette commande configure automatiquement SSSD, Kerberos (/etc/krb5.conf), NSS et PAM. Le paramètre --mkhomedir crée le répertoire personnel de l'utilisateur à sa première connexion, un détail qui simplifie nettement le provisioning des postes.
Après l'enrôlement, le fichier /etc/sssd/sssd.conf généré automatiquement ressemble à ceci :
[sssd]
domains = infra.example.com
services = nss, pam, ssh, sudo
[domain/infra.example.com]
id_provider = ipa
auth_provider = ipa
access_provider = ipa
sudo_provider = ipa
cache_credentials = True
krb5_store_password_if_offline = True
La directive cache_credentials = True conditionne la résilience. Si votre serveur IPA tombe, les machines clientes continuent de fonctionner avec le cache local. Pour les environnements qui exigent un durcissement SSH avancé, FreeIPA distribue aussi les clés publiques SSH via l'annuaire LDAP, ce qui supprime la gestion manuelle des fichiers authorized_keys.
FreeIPA vs Active Directory : deux philosophies
Ce que les chiffres ne disent pas : FreeIPA n'est pas un clone d'Active Directory. Une solution conçue pour un écosystème radicalement différent.
| Critère | FreeIPA | Active Directory |
| Cible principale | Linux, UNIX | Windows |
| Annuaire | 389 DS (LDAPv3) | AD DS (LDAP propriétaire) |
| Authentification | MIT Kerberos | Kerberos Microsoft |
| Politiques | HBAC, sudo, SELinux | GPO (Group Policy Objects) |
| PKI | Dogtag (intégré) | AD CS (module séparé) |
| Coût | Open source, gratuit | Licences Windows Server |
L'interopérabilité existe : FreeIPA peut établir une relation de confiance cross-realm Kerberos avec Active Directory. Les utilisateurs AD accèdent alors aux ressources Linux sans compte dupliqué. D'après la documentation officielle de FreeIPA, cette approche par trust est recommandée plutôt que la synchronisation d'annuaires, qui introduit des problèmes de cohérence et de latence.
Architecture et haute disponibilité
Un déploiement FreeIPA de production repose typiquement sur :
- 2 à 3 réplicas : réplication multi-maître du 389 DS, chaque réplica est autonome en lecture et écriture
- DNS intégré : résolution de service via les enregistrements SRV, basculement automatique des clients
- PKI distribuée : certificats gérés par Dogtag, renouvellement automatique via certmonger
La réplication multi-maître élimine le point de défaillance unique. Si un serveur tombe, SSSD bascule automatiquement sur un réplica disponible, et le cache local assure la continuité de service pendant la bascule. La recommandation officielle est de ne pas dépasser quatre réplicas par topologie : au-delà, le coût de réplication devient significatif.
Limites et points de vigilance
Les limites constatées, sans détour :
- Pas de GPO : FreeIPA ne gère pas la configuration des postes (fond d'écran, registre, etc.). Ce n'est pas son rôle ; des outils comme Ansible comblent ce besoin.
- Écosystème Red Hat : bien que fonctionnel sur Debian/Ubuntu, FreeIPA est optimisé pour RHEL, CentOS, Fedora et leurs dérivés. L'installation sur d'autres distributions peut nécessiter des ajustements.
- Courbe d'apprentissage : Kerberos reste un protocole exigeant à déboguer. Les erreurs de configuration DNS sont la première cause de problèmes lors du déploiement initial.
- Pas de gestion applicative : pour le SSO des applications web (OAuth2, OIDC, SAML), il faut coupler FreeIPA avec Keycloak ou un équivalent.
Recommandation
Pour toute infrastructure comptant plus de 10 serveurs Linux, la centralisation de l'identité n'est plus optionnelle. FreeIPA donne une solution intégrée, mature (le projet existe depuis 2008) et activement maintenue qui couvre les besoins de base : annuaire, authentification, autorisation et audit.
La combinaison FreeIPA (identité système) + Keycloak (identité applicative) reste aujourd'hui le stack open source le plus complet pour une gestion des utilisateurs Linux à l'échelle. Couplée à un audit de sécurité régulier, cette architecture donne un niveau de contrôle comparable aux solutions propriétaires, sans les coûts de licences associés. Selon la documentation du projet, la version 4.12 confirme la trajectoire : modernisation de l'interface, support FIDO2, outils de migration entre environnements. FreeIPA n'est plus une curiosité de niche ; une pièce maîtresse de l'infrastructure Linux moderne.
