URL: https://linuxfr.org/users/rahan/journaux/identification-et-authentification-centralisees Title: Identification et authentification centralisées Authors: rahan Date: 2020年07月20日T22:31:55+02:00 License: CC By-SA Tags: ldap, openldap, fusiondirectory, sssd, authentification et debian Score: 21 # Contexte # Les enfants grandissant, ils ont maintenant besoin d'un accès à un ordinateur. Ils s'attendent à retrouver leurs fichiers d'un jour à l'autre. Le problème est que leur père a la fâcheuse tendance à *tester* de nouvelles configurations avec les morceaux d'ordinateurs qui traînent à la maison. Je me retrouve en ce moment avec plusieurs PC. J'ai commencé à en avoir marre de devoir configurer les comptes de toute la famille à chaque réinstallation. Les mots de passe n'étaient pas toujours les mêmes et mes enfants ne savaient plus où étaient stockés leurs fichier. Je dispose d'un NAS (un PC sous Debian avec 4 disques) et je me suis dit que ce serait la bonne occasion pour commencer à centraliser l'identification et l'authentification de mes machines. # Une solution avec LDAP # Le serveur LDAP c'est la solution par défaut à laquelle on pense dans le monde Unix. Je dois avouer que mon expérience est un peu ancienne avec cette technologie : j'avais développé mon gestionnaire de carnet d'adresse il y a 20 ans avec un serveur LDAP et une interface en PHP. C'était l'occasion de voir ce qu'il en était de nos jours. ## Le serveur LDAP : OpenLDAP ## Comme serveur d'annuaire, il n'y a visiblement pas beaucoup de choix : le vénérable [OpenLDAP](https://www.openldap.org/) et [386 Directory Server](https://directory.fedoraproject.org/) proposé par Red Hat. L'intégration dans Debian avait l'air meilleure pour OpenLDAP et c'est celui-ci que j'ai choisi. J'ai tout de même testé 389DS mais je n'ai pas trouvé d'avantage pour mon usage et la configuration avait l'air plus obscure qu'OpenLDAP (c'est dire !). La grande nouveauté de OpenLDAP c'est qu'il n'y a plus de fichier de configuration. Toute la configuration est stockée dans la base de donnée de l'annuaire. C'est peut-être séduisant sur le papier mais lorsqu'on ne parle pas le [LDAP Data Interchange Format (.ldif)](https://fr.wikipedia.org/wiki/LDAP_Data_Interchange_Format) couramment, c'est assez compliqué de faire quelque chose de simple surtout que la documentation n'est pas toujours très claire. Tout se fait à l'aide des commandes `ldapadd` ou `ldapmodify`. Par exemple, pour activer la prise en charge de TLS et indiquer au serveur les fichers de certificats et de clés à utiliser, voici ce qu'il faut taper : ``` ldapmodify -H ldapi:/// -Y EXTERNAL << EOF dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/tls/serveur_ldap.crt - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/tls/serveur_ldap.pem EOF ``` C'est pour ça que j'ai très vite cherché à utiliser une interface graphique pour la gestion des utilisateurs. ## La gestion de l'annuaire : Fusion Directory ## Deuxième déconvenue : je pensais pouvoir trouver pléthore d'outils graphiques pour la gestion des annuaires LDAP (c'est sensé être LA solution de gestion centralisée des utilisateurs). Au final, je n'ai trouvé que très peu d'outils libres, maintenus et permettant de gérer les permissions sudo, les clés SSH et l'autorisation de connexion en fonction de la machine. J'ai donc installé [Fusion Directory](https://www.fusiondirectory.org/) qui a la bonne idée d'être packagé dans Debian. Au final, ça fonctionne : je peux gérer les utilisateurs, leurs groupes, leurs mots de passe, leurs clés SSH, définir sur quelle machines ils peuvent se connecter, les règles sudo... Par contre c'est très fragile : en rajoutant des modules, j'ai réussi à corrompre la base de donnée. La documentation est minimaliste (je n'ai jamais réussi à faire fonctionner les attributs autofs par exemple). Le package par Debian fonctionne mais cela impose l'utilisation d'Apache. J'ai voulu essayé de l'installer à partir des sources dans un container docker et ce fut un échec tellement la documentation est lacunaire (il faut visiblement rapatrier des projets JavaScript). J'avais donc un annuaire et un moyen de gérer les utilisateurs. Il ne restait plus qu'à utiliser ces données sur les postes clients. ## Sur les machines clientes : SSSD ## C'est la bonne surprise de ce périple : il y a une solution simple qui fonctionne très bien. J'ai utilisé [SSSD](https://sssd.io/). La documentation est encore une fois plutôt rare mais cela fonctionne très bien en suivant la [documentation Red Hat](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sssd-introduction). Il y a un fichier de configuration (`/etc/sssd/sssd.conf`) qui est plutôt simple à préparer. Par exemple, ma configuration ressemble à ça : ``` [sssd] domains = LDAP_example_com [nss] filter_groups = root filter_users = root entry_cache_timeout = 300 [pam] offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5 entry_cache_nowait_percentage = 75 [sudo] [domain/LDAP_example_com] id_provider = ldap auth_provider = ldap access_provider = ldap ldap_access_order = host cache_credentials = true offline_credentials_expiration = 3 ldap_uri = ldap://ldap.example.com ldap_search_base = dc=example,dc=com ldap_id_use_start_tls = true ldap_tls_reqcert = demand ldap_tls_cacert = /etc/sssd/CA.crt sudo_provider = ldap ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ``` Une mise à jour de `/etc/nsswitch.conf` est nécessaire : ``` passwd: files systemd sss group: files systemd sss shadow: files sss gshadow: files hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname mymachines networks: files protocols: db files services: db files sss ethers: db files rpc: db files netgroup: nis sss sudoers: files sss automount: sss ``` Et là comme par magie (après `pam-auth-update`), les utilisateurs, leurs groupes, leurs mots de passes, leurs droits sudo sont récupérés dans l'annuaire. Les mots de passe sont même stockés quelque temps localement pour palier à une indisponibilité du serveur LDAP (utile pour les portables). Pour que les clés publiques SSH soient issues de l'annuaire à la place de `~/.ssh/authorized_keys`il suffit de changer la directive `AuthorizedKeysCommand` dans `/etc/ssh/sshd_config` pour qu'elle pointe vers `/usr/bin/sss_ssh_authorizedkeys`. Les utilisateurs peuvent également changer leurs mots de passe avec les outils locaux (`passwd` ou l'équivalent chez Gnome et KDE) et ce changement est inscrit dans la base de donnée centralisée. ## Limites de la solution ## Autant j'ai trouvé la partie cliente assez robuste, autant j'ai moins confiance en la partie serveur. La configuration d'OpenLDAP relève à mon sens de la magie noire tandis que Fusion Directory me semble très fragile. Cet état des lieux est à mon sens lié au fait que la gestion centralisée des utilisateurs est une fonctionnalité incontournable et très rémunératrice auprès des entreprises. Peu de gens sont près à rendre cette brique plus accessible. Là où j'ai atteins les limites de cette solution c'est lorsque que j'ai voulu coupler ce système aux partages de fichiers de mon NAS. Je voulais avoir quelque chose de plus sécurisé que NFSv3. De plus je voulais pouvoir utiliser les mêmes mots de passe pour les partages Samba (mon épouse a un portable sous Windows). Synchroniser les mots de passe LDAP et Samba s'est révélé au dessus de mes capacités. Je me suis donc intéressé à NFSv4 qui exige d'être couplé à [Kerberos](https://fr.wikipedia.org/wiki/Kerberos_(protocole)). Rajouter un nouveau serveur ne m'enchante guère et la documentation est encore une fois légère. # À la recherche d'une meilleure solution # Je suis peut-être à la recherche du Graal mais je n'arrive pas à trouver comment faire quelque chose qui devrait être à la base d'un déploiement de linux sur un parc : gérer les utilisateurs et leurs droits de manière centralisé, le tout couplé au partage de fichiers et avec une interface simple et robuste. Ce qui m'ennuie d'autant plus est que je sais qu'une solution éprouvée existe : [Active Directory](https://fr.wikipedia.org/wiki/Active_Directory). Elle n'est pas libre même si des implémentations libres sont possible avec [Samba](https://www.samba.org/). Avez-vous été confronté à ce besoin ? Quelle solution avez-vous retenu ?

AltStyle によって変換されたページ (->オリジナル) /