Journal Identification et authentification centralisées

Posté par  . Licence CC By‑SA.
Étiquettes :
21
20
juil.
2020

Sommaire

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 et 386 Directory Server 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) 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 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. La documentation est encore une fois plutôt rare mais cela fonctionne très bien en suivant la documentation Red Hat.

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_keysil 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. 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. Elle n'est pas libre même si des implémentations libres sont possible avec Samba.

Avez-vous été confronté à ce besoin ? Quelle solution avez-vous retenu ?

  • # Idem !

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Comme toi j'ai mis en place un système d'authentification utilisateur basé sur OpenLDAP (voir par là) j'ai été confronté aux mêmes problèmes, dont l'absence d'outil d'administration un brin évolué et un minium convivial et je n'ai pas poussé aussi loin pour le partage de fichiers où je suis encore resté à NFS.
    J'ai mis ça en place très laborieusement il y a maintenant presque 20 ans (!), au fil du temps j'ai peaufiné la chose et aujourd'hui c'est relativement mature, sans être forcément pleinement satisfaisant, ton post va certainement me motiver pour m'y repencher à nouveau (je sais ça t'aide pas vraiment…).

    https://www.funix.org mettez un manchot dans votre PC

  • # qq comentaires

    Posté par  (Mastodon) . Évalué à 6. Dernière modification le 21 juillet 2020 à 01:04.

    j'ai très vite cherché à utiliser une interface graphique

    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.

    389DS est 'robuste'
    Pour ces raisons tu aurais peut être du regarder d'un peu plus près le bon vieux 389DS avec son interface graphique très bien faite (elle n'est pas parfaite, il y a qq pièges à éviter surtout à cause [me semble t il] de vocabulaire en fait, mais elle est bien et très pratique.

    Une mise à jour de /etc/nsswitch.conf

    Authconfig fait ça pour toi en 2 clicks
    (avec la conf pam aussi, perso je préfère faire à la main dès que ça dépasse du truc simple par défaut, ce qui est le cas de mes pam)

    la partie cliente assez robuste

    Oui, quelque soit le choix côté client c'est pas mal. SSSd est vraiment très bien, pour ce besoin tu aurais pu te contenter de plus simple.

    pam-auth-update

    C'est une superbe astuce ;-)

    quelque chose de plus sécurisé que NFSv3

    Kerberos est ton ami, pour nfs v3 ou 4 (ou 4.1 & 2 si tu es riche), et nfs v4.x si tu préfères n'avoir qu'un port ouvert

    Finir sur ça permet d'ouvrir sur une autre solution (en fait une couche en plus) : FreeIPA : c'est robuste, ça fonctionne remarquablement bien et il y a une très chouette wui

    • [^] # Re: qq comentaires

      Posté par  . Évalué à 2.

      En fait mon problème vient du fait que je voulais rester sur une solution installée sur une Debian. J'ai testé 389DS et l'interface graphique ne m'a pas semblé très intéressante pour mon usage. J'ai bien compris que les fonctions que je recherche sont intégrées dans FreeIPA mais comme ce n'est pas évident à installer sous Debian, j'ai jeté l'éponge. Au final, je vais sûrement approfondir cette option dans un container docker ou une machine virtuelle CentOS.

      Merci pour le retour.

      • [^] # Re: qq comentaires

        Posté par  (Mastodon) . Évalué à 3. Dernière modification le 22 juillet 2020 à 00:37.

        Il ne s'agissait effectivement que d'un retour d'usage.
        Pour rester sur Debian, Samba a l'air très bien (je connais moins, si ce n'est la difficulté de la gestion des mots de passe entre client linux et windows sur de vieille version) L'avantage que je vois à Samba c'est qu'il a également l'air très mature aujourd'hui, intègre 'plus facilement' une hétérogénéité de clients, et fait tâter des technos qui occupent plus d'échelle / d'espace dans ce domaine précis. Si je me permet un conseil : ça serait de partir sur Samba.
        Certainement plus compliqué à déployer (la solution Directory Server de Fedora est vraiment superbement bien faite sur ce point : une commande d'installation, un domaine, et c'est prêt, on peut affiner ensuite) mais probablement plus intéressante à l'avenir (?) et adressant (semble t il) l'ensemble de tes besoins (sans exiger d'aller se frotter à kerberos pour nfs, par exemple)
        Merci également.

  • # glauth

    Posté par  . Évalué à 3.

    Salut,

    Merci pour ton retour d'XP ça donne envie. Sauf l'admin du server LDAP qui me parait (à chaque fois que je le regarde) overkill pour un usage domestique.

    Pour du dev j'utilise ça : https://github.com/glauth/glauth

    Mais ils prétendent que ça marche aussi pour du "home".
    Alors je me demandais si tu avais regarder glauth et si tu avais un avis là dessus ?

    • [^] # Re: glauth

      Posté par  . Évalué à 3.

      Je ne connaissais pas. Merci pour le tuyau. Par contre, il y a pas mal de truc que je ne pourrais pas faire avec (hosts, sudo, autofs…). La documentation a l'air pas mal en retard sur le code (les backends ne semblent pas documentés) et je n'ai pas compris comment les changement de mot de passe sont gérés (tout semble stocké en dur). Par contre c'est intéressant pour tester ou pour des gérer des services web avec un ou deux utilisateurs.

  • # LemonLDAP::NG

    Posté par  . Évalué à 3.

    Je dit peut être une bêtise, mais je croyais que LemonLDAP::NG était une solution intéressante.

    • [^] # Re: LemonLDAP::NG

      Posté par  (site web personnel) . Évalué à 2.

      (même si ça va faire beaucoup de peine à Clément…)

      Il y a aussi LAM (LDAP Account Manager) en petit frontend web pour LDAP (packagé dans toutes les bonnes distribs).

      Proverbe Alien : Sauvez la terre ? Mangez des humains !

    • [^] # Re: LemonLDAP::NG

      Posté par  . Évalué à 3.

      Je me trompe peut-être mais j'avais l'impression que LemonLDAP::NG est un fait une solution pour faire du SSO pour des application web. Il utilise ensuite un serveur LDAP qu'il faut lui fournir. Ca ne répond pas à ma problématique de gérer de manière "conviviale" les utilisateurs.

      • [^] # Re: LemonLDAP::NG

        Posté par  . Évalué à 2. Dernière modification le 22 juillet 2020 à 18:10.

        C'est possible, je ne connais pas assez la solution

  • # FreeIPA

    Posté par  . Évalué à 3.

    Pour un besoin similaire, je me suis orienté vers Ansible et FreeIPA

    • Pour la configuration des PCs Linux, j'utilise Ansible: c'est facile à apprendre et à utiliser, et c'est très efficace.

    • Pour l'authentification centralisée, j'avais aussi commencé par essayer OpenLDAP + FusionDirectory, mais je trouvais que c'était trop complexe. J'ai aussi essayé Samba4, mais on est obligé d'utiliser les outils Microsoft pour avoir une console de gestion graphique, alors finalement j'ai choisi FreeIPA.

    FreeIPA est beaucoup plus facile à installer que OpenLDAP + FusionDirectory. L'interface web est très réussi, l'interface en ligne de commande est très facile à utiliser. FreeIPA fournit aussi un royaume Kerberos ce qui permet d'avoir l'authentification unique (SSO).

    Comme je n'ai commencé ce projet que très récemment, je reconnais que je manque encore de recul sur cette solution. Pour l'instant j'ai remarqué les inconvénients suivants:

    • Pour ne pas avoir d'ennui, il vaut mieux faire fonctionner FreeIPA server sur sa plateforme de référence à savoir CentOS 8, car même sur Oracle 8, ça ne fonctionne pas aussi bien. Du coup je n'ai même pas essayé de le faire fonctionner sur Debian.

    • FreeIPA est beaucoup plus lourd que OpenLDAP+FusionDirectory, (il est en Java et il démarre beaucoup de services réseau), mais ca fonctionne quand même bien dans une petite machine virtuelle ( 1 vCPU / 2 GB de RAM).

    • [^] # Re: FreeIPA

      Posté par  . Évalué à 2.

      Merci pour ce retour. Je vais essayer FreeIPA sur une machine virtuelle (CentOS) ou dans un container (docker).

      Toutes mes configurations sont déjà gérées par Ansible dans un dépot git. C'est très pratique quand on a tendance à réinstaller régulièrement de vielles machine.

      • [^] # Re: FreeIPA

        Posté par  . Évalué à 3.

        attention que freeipa demande un container avec beaucoup de privilèges. Je partirais plutôt sur une machine virtuelle.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # SQL ?

    Posté par  . Évalué à 4.

    Question naïve : pour un usage comme le tien, est-ce qu'une base SQL comme Postgres (en central / sur le nas) avec les modules PAM et NSS qui-vont-bien ne serait pas encore plus simple ?
    (peut-être que je dis une hérésie, je ne suis pas sysadmin donc c'est une vraie question. J'ai touché un peu à ldap lors d'un stage il y a 20 ans et ce dernier était théoriquement "optimisé pour un usage avec des lectures fréquentes et des écritures rares", mais en 2020 et pour un usage perso je me dis que la question de la performance est secondaire et je suis curieux de voir en quoi une base SQL classique - qui me semble plus simple - ne serait pas adaptée)

    • [^] # Re: SQL ?

      Posté par  . Évalué à 3.

      SQL est sûrement beaucoup plus adaptée à mon usage mais je crains de devoir réinventer la roue pour chaque fonction déjà prévue par sssd. Mon idée était de s'ennuyer un petit peu avec la partie serveur pour pouvoir utiliser coté client des procédures simples et déjà intégrées dans les distributions.

  • # Samba v.4

    Posté par  (site web personnel) . Évalué à 5.

    Je serais parti sur du Samba v.4, qui est plus simple à utiliser et intègre un LDAP et un Kerberos.

    OpenLDAP vient uniquement avec des commandes génériques. À toi de connaître les bonnes classes de base et penser à tous les attributs d'un utilisateur.
    Samba v.4 vient avec une commande pour gérer les utilisateurs, et elle déterminera pour toi les classes et attribut à utiliser. Moins souple, mais tellement plus pratique !

    Sans compter qu'OpenLDAP est très complexe à utiliser si tu veux vraiment utiliser des classes et attributs personnalisés…

  • # Qui a besoin d'une UI quand on automatise tout ?

    Posté par  (site web personnel) . Évalué à 2.

    Pour ma part, je passe par ansible pour l'orchestration de mon serveur ldap (et de tout le reste tant qu'à faire), et éventuellement phpldapadmin pour aller explorer l'annuaire.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

  • # FusionDirectory

    Posté par  (site web personnel) . Évalué à 3.

    Bonjour,

    Je suis développeur pour FusionDirectory, quelques réponses donc:

    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) couramment, c'est assez compliqué de faire quelque chose de simple surtout que la documentation n'est pas toujours très claire.

    Oui, c’est pas simple leur système de config, en plus leur doc est encore beaucoup centrée sur l’ancien système, et le serveur refuse toute modification un peu risquée pour l’instant, donc par exemple on peut ajouter un overlay, mais pas en retirer un.

    On a un prototype d’outil pour aider un peu à interroger cn=config: https://gitlab.fusiondirectory.org/fusiondirectory/schema2ldif/-/tree/1.4-dev/bin (c’est le ldap-config-manager dans ce dossier)
    C’est pas complet mais ça dépanne et tu peux l’étendre si tu code un peu.
    Pour les modifs refusée par le serveur faut jouer avec slapcat et ses copains, on trouve des exemples dans les archives de la ML openldap.

    Synchroniser les mots de passe LDAP et Samba s'est révélé au dessus de mes capacités.

    Normalement installer le plugin samba de FusionDirectory suffit, quel problème as-tu rencontré?

    Quelle version de FusionDirectory as-tu testé? Ça vaut le coup de mettre nos dépôts pour avoir plus récent que la version Debian.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.