URL: https://linuxfr.org/users/illwieckz/journaux/disputatio-samba-kerberos-et-ldap Title: Disputatio : Samba, Kerberos et LDAP Authors: Thomas Debesse Date: 2015年10月23日T20:04:50+02:00 License: CC By-SA Tags: ldap, samba, openldap, kerberos, cifs, authentification et sso Score: 32 Cher journal, je me retrouve aujourd’hui à préparer la montée en version de plusieurs serveurs Samba de plusieurs organisations et puisqu’il faut repasser par la case labo pour tester et valider la migration, c’est l’occasion pour moi de remettre à plat certains choix techniques passés que j’ai faits ou que d’autres ont faits avant moi ou avec moi. Aussi, j’hérite de certains choix techniques qui ont été faits à une époque où il n’y avait pas le choix tout simplement, car certains parcs ont vraiment un très long passé ! Sur un autre plan, j’ai une certaine expérience de LDAP comme annuaire d’utilisateur/groupe/mots de passe, et un peu de Kerberos. Mais toutes ces expériences ne sont pas liées entre elles, et là, c’est nouveau, il va peut-être falloir que je connecte tout cela. Ce journal est donc à la fois un partage de mon expérience, un appel à témoigner de la vôtre, et une invitation à débattre de diverses solutions. # Mais quel est le sujet au juste ? Je rappelle en gros les différentes technologies : * [[Samba]], un service de domaine compatible avec le service Active Directory de Microsoft. C’est très utile pour fournir des services d’authentification (machines, utilisateur, groupes) et des dossiers partagés. C’est ce qui fait qu’en vous asseyant devant une machine quelconque de l’entreprise, vous entrez votre identifiant et votre mot de passe, et hop vous avez votre bureau et les dossiers en réseau auxquels vous êtes abonnés. Samba est un logiciel qui fournit plusieurs services et prend en charge divers protocoles, il est incontournable si vous voulez fournir un réseau d’entreprise compatible avec des clients Microsoft. * [[Kerberos]], c’est un système d’authentification : en gros il gère une base d’utilisateurs et c’est lui qui donne les autorisations et les accès aux services qui se basent là dessus. Avec Kerberos on pourrait par exemple authentifier les accès à des dossiers réseau CIFS (SMB) ou NFS, ou encore les accès SSH (avec [[OpenSSH]]. Kerberos est un protocole, sous GNU/Linux on utilisera généralement le logiciel MIT Kerberos (krb5). * [[LDAP]], c’est un annuaire. Dit très rapidement, c’est une base de donnée dédiée aux services d’annuaire, avec un protocole standardisé. Ça peut servir à différente choses, comme par exemple conserver les contacts de votre carnet d’adresse (il y a souvent du LDAP derrière un service [[CardDAV]] par exemple). Vous pouvez mettre un peu n’importe quoi dans un LDAP, mais ce qui nous intéresse ici, c’est que LDAP peut aussi être un annuaire d’identifiant et de groupe (un `/etc/passwd`, `shadow`, `group` en réseau quoi), surtout qu’il est très facile pour LDAP de contenir son propre annuaire d’utilisateur pour gérer les accès à LDAP (un peu comme MySQL a sa propre base de données de comptes pouvant accéder aux bases de données de MySQL). Beaucoup d’applications peuvent utiliser LDAP pour authentifier leurs utilisateurs, comme des applications web par exemple, et beaucoup de ceux qui ne savent le faire d’eux même ont un greffon pour ça. LDAP est un protocole, on utilisera généralement [[OpenLDAP]] sous GNU/Linux. Évidemment, tout cela se recoupe un peu. Samba authentifie des utilisateurs, comme Kerberos et comme LDAP peut le faire. Kerberos peut sauvegarder ses données dans un annuaire LDAP. Kerberos peut gérer l’accès à un annuaire LDAP (vous vous authentifiez auprès de Kerberos d’abord, et une fois votre session Kerberos ouverte, vous demandez autant d’accès à LDAP que vous voulez). Samba peut fournir un service Kerberos. Samba peut utiliser un annuaire LDAP pour y placer ses données. Samba peut s’authentifier auprès d’un annuaire LDAP. Samba peut utiliser un service Kerberos tiers. Etc. # Ce que j’ai l’habitude de réaliser Voici quelques exemples de configurations que j’ai eu à réaliser : ## Annuaire LDAP pour l’authentification d’application web J’ai fait cela pour plusieurs projets. J’ai eu par exemple un annuaire LDAP qui servait de service d’authentification à l’application de gestion de projet [[Redmine]] (forum, wiki, gestion de tickets, calendrier de tâches, dépôt de code source etc.) et à l’application [[ownCloud]] (synchonisation de fichiers, partage de fichiers en ligne, gestionnaire de contacts, calendrier et divers éditeurs/visualisateurs de documents en ligne). LDAP gérait donc les accès des utilisateurs et leur appartenance aux groupes (qui étaient donc répliqués entre Redmine et ownCloud). Il y avait aussi, reposant sur ce même LDAP, un service XMPP (Jabber) de messagerie instantanée basé sur le logiciel [[Ejabberd]]. Ce n’était pas une application web, mais ça faisait partie de ce projet. J’ai eu un autre projet où il s’agissait d’avoir une base d’utilisateurs commune à une galaxie de blogs [[Wordpress]] : plusieurs instances Wordpress, certaines en « Multisite », toutes les instances et donc tous les blogs servis devaient être accessibles avec le même couple identifiant/mot de passe. Malheureusement, Wordpress ne prend pas en charge LDAP par défaut, il faut utiliser un greffon. Comme l’utilisation d’un greffon tiers n’a pas le même niveau de fiabilité, j’ai limité sa fonctionnalité : il ne fait qu’authentifier les utilisateurs. Quand une personne tente de s’identifier auprès de WordPress, WordPress demande à LDAP, et si LDAP répond « c’est OK », LDAP ouvre la session (et crée l’utilisateur dans WordPress si besoin). Je n’ai pas délégué la gestion des groupes à LDAP et donc au greffon LDAP. La seule chose que fait le greffon, c’est transmettre l’identifiant/mot de passe à LDAP et attend une réponse oui/non, il n’y a aucun mot de passe LDAP sauvegardé dans la configuration du greffon, si WordPress devait être capable de créer des utilisateurs ou des groupes dans LDAP, il faudrait donner un accès privilégié au greffon, qui est un greffon tiers, et ce ne serait pas sûr du tout. D’ailleurs, je le dis en passant, certaines applications ou greffons demandent un accès administrateur pour authentifier les utilisateurs, fuyez-les. Exigez toujours que l’authentification de l’utilisateur ne nécessite que les identifiants de l’utilisateur à authentifier, ce n’est pas à un compte LDAP privilégié d’authentifier les comptes utilisateurs. Coté LDAP, cela signifie qu’un anonyme doit avoir au moins le droit de s’authentifier lui-même. ## Annuaire LDAP avec authentification Kerberos basée sur LDAP Attention, ça peut faire un peu mal à la tête. Dans ce schéma, c’est Kerberos qui gère les accès à LDAP, mais c’est LDAP qui fournit à Kerberos le service de stockage des identifiants et des mots de passe. En gros il y a quatre annuaires : * L’annuaire d’utilisateur (un peu comme `/etc/passwd`) avec le nom de l’utilisateur, son adresse mail, sa date de naissance, son identifiant, mais le champ « mot de passe » est inutilisé. Les entrées utilisent le schéma utilisateur standard. * L’annuaire de groupe (un peu comme `/etc/group`), la liste des groupes auxquels peuvent être abonnés les utilisateurs. Les entrées utilisent le schéma groupe standard. * L’annuaire des identifiants kerberos, dans une arborescence à part (et un [[FQDN]] différent) que personne ne peut lire à part Kerberos. Les entrées utilisent le schéma kerberos, pas le schéma ordinaire. * L’annuaire des [ACL](https://fr.wikipedia.org/wiki/Access_Control_List) d’LDAP, présent par défaut évidemment, c’est lui détermine que Kerberos a accès seul à son annuaire seulement, et le reste au reste. Tout ça c’est de la tambouille interne mais il faut bien en parler. À cela j’avais ajouté une couche de compatibilité : si on n’est pas authentifié par Kerberos (le système ne le gère pas, par exemple une application web comme cité ci-dessus) et qu’on demande un accès à LDAP, LDAP peut le demander à Kerberos en sous main grâce à [[SASL]]. Ce que cela signifie : - L’utilisateur n’a absolument aucun accès à quoi que ce soit de proche ou de loin à son mot de passe (l’annuaire qui contient ses informations privées ne contient même pas le [[hash]] de son mot de passe, ce champ est vide). - L’utilisateur peut sécuriser sa connexion LDAP avec Kerberos. - Les applications qui savent utiliser Kerberos peuvent utiliser Kerberos. - Les applications qui ne savent pas utiliser Kerberos mais LDAP peuvent authentifier leurs utilisateurs. C’est une régression, mais si les seules applications dans ce cas sont des services web vous êtes assez tranquilles. Vous pouvez choisir que LDAP ne soit pas disponible publiquement et que seul Kerberos le soit, les applications ne verront LDAP qu’en local. De toute façon, si c’est pour servir de base d’identifiants, il y a très peu de chances que vous deviez tirer une croix sur la sécurité de Kerberos : le mot de passe transite déjà par l’application et par https, qui sont autant de points d’attaque. - Toute application compatible SASL (qui est compatible Kerberos) peut authentifier des utilisateurs. Avec ça vous avez une base d’authentification commune pour tout ce que vous voulez : Samba, NFS, OpenSSH, IMAP, SMTP, applications web, comptes unix, bref, tout ce qui est compatible avec une authentification par [PAM](https://fr.wikipedia.org/wiki/Pluggable_Authentication_Modules), SASL, LDAP ou Kerberos. Concernant les applications web, il existe certainement des services [[OpenID]] fondé sur LDAP, vous pouvez aussi utiliser [[LemonLDAP]], et même Apache sait authentifier auprès de Kerberos ou LDAP, et Nginx a des modules pour cela également. Bref, dans le meilleur des cas, vos authentifications sont sécurisées par Kerberos, dans le meilleur des cas vous avez un mécanisme d’authentification unique [[SSO]] soit par Kerberos, soit par OpenID, et dans le pire des cas, vous avec un couple identifiant/mot de passe commun partout. Les inconvénients sont : * Tout cela est assez complexe à mettre en œuvre. * Les utilisateurs ne peuvent pas bénéficier des mécanismes applicatifs (ni même celui d’LDAP) pour changer son mot de passe ou pour en réclamer un nouveau. Je n’ai pas trouvé d’application dédié à cela qui sache se connecter à Kerberos pour faire ces tâches là (et optionnellement, qui sache aussi se connecter à LDAP pour récupérer l’adresse mail de l’utilisateur qui demande une procédure de récupération de mot de passe). ## Mon expérience Samba Avec Samba j’ai déjà fait plein de choses amusantes. Comme expliqué en [commentaire d’un journal](http://linuxfr.org/users/chrisk/journaux/internet-explorer-4-failles-0-day-publiees#comment-1614847), j’ai désactivé toute synchronisation sur les postes clients et minimisé au maximum les données hors-connexion du profil itinérant, qui est une vraie plaie. Contrairement à ce que j’ai vu dans certaines entreprises (et surtout, entendu d’employé de beaucoup d’entreprises), le bureau est en réseau, et le dossier _AppData_ aussi. Cela évite les pertes de données lorsque la même session est ouverte plusieurs fois (la dernière session fermée écrase la précédente), et cela évite surtout la perte de données lorsque la session est interrompue de manière intempestive (coupure de courant par exemple). Je ne comprends pas qu’une société de la taille de Microsoft ait pu concevoir un protocole de fichier réseau qui consiste à tout télécharger au début et à tout renvoyer à la fin, ce qui est défectueux par conception, car seule la connexion est garantie, pas la déconnexion. Bref, En plus des partages réseau dans le poste de travail, tout ce qui est possible de mettre en réseau est mis en réseau. Ce qui n’est pas en réseau, en gros, c’est le `Local Settings`, qui est fait pour être local et qui est d’ailleurs conçu pour pouvoir être perdu. L’autre chose qui n’est pas en réseau, la grosse exception, c’est la ruche de registre utilisateur, qui est récupérée à la connexion et renvoyée à la déconnexion, mais ce n’est pas bien grave et il y a les sauvegardes pour ça. Là où j’étais assez fier, mais maintenant l’usage devient peu fréquent, c’est que le profile était commun entre Windows XP et suivants (`profile.v2` à partir de Vista), à l’exception bien sûr de la ruche. Cela a permis de faire cohabiter Windows XP avec les nouveaux Windows pendant très longtemps, et a réduit beaucoup de coûts (il n’était pas nécessaire de remplacer tous les postes XP dès le premier jour où le premier windows 7 est arrivé). Ainsi, quel que soit la machine ou le Windows, les utilisateurs avaient le même Bureau, même _AppData_, même dossiers « Mes images » (en réseau bien sûr), et il était possible d’avoir ces mêmes dossiers (bureau, « Mes Images », « Ma Musique », etc.) communs sous GNU/Linux, même si ça ne s’est jamais fait (il y a très peu de client GNU/Linux). Vu que le bureau est en réseau, il est très facile à un administrateur d’ajouter des raccourcis sur les bureaux des utilisateurs alors qu’ils sont connectés, ou faire d’autres tâches de maintenance de ce type. Ça permet aussi de mieux gérer les quotas (quand l’utilisateur dépasse, c’est tout de suite, pas à la déconnexion quand le profil itinérant est renvoyé) et ça permet donc de superviser les quotas en temps réel. Pour plus de détails, voir mon [précédent commentaire](http://linuxfr.org/users/chrisk/journaux/internet-explorer-4-failles-0-day-publiees#comment-1614847). J’ai fait ça pour plusieurs entités et plusieurs centaines d’utilisateurs utilisent ce type de configuration. Samba est vraiment un outil super. Mais je suis bien conscient qu’il y a encore beaucoup à explorer, et c’est là l’objet de mon journal : partager des solutions, recueillir vos témoignages, etc. Je pose tout de suite la question : _Êtes-vous intéressés par mon partage d’expérience et par des journaux-tutoriels décrivant comment faire toutes ces choses que je décris ? Que ce soit sur le plan LDAP, Kerberos ou Samba ?_ # Ce qui est encore un grand mystère pour moi Voici des réalisations que je n’ai encore jamais faites de toute ma vie : * Utiliser Samba comme un service Kerberos. * Connecter Samba à un service LDAP. * Connecter Samba à un service Kerberos tiers. * Authentifier des utilisateurs Unix auprès d’un de ces deux mécanismes. A priori j’ai déjà appris tout ce qu’il fallait coté LDAP ou Kerberos pour que Samba puisse reposer sur un LDAP et/ou un Kerberos externe, mais je n’ai jamais « branché » un Samba sur un LDAP ou un Kerberos. Les services Samba que j’administre pour le moment utilisent toujours LAN Manager, ce qui est déprécié par Microsoft depuis longtemps (cf. [cet article sur MSDN](https://msdn.microsoft.com/en-us/library/bb742516.aspx)), et il n’est pas garanti que Microsoft n’abandonne pas cela bientôt, le support de LAN Manager est déjà désactivé par défaut coté client. Pour l’instant tous les Windows que j’ai vus étaient encore compatible à condition parfois d’activer le support déprécié (si ça vous intéresse de savoir comment faire, demandez en commentaire), mais ça pourrait changer. Je n’ai jamais non-plus utilisé `slapd-smbk5pwd`. Ce greffon permettrait, selon ses concepteurs, de mettre à jour automatiquement les mots de passe dans Samba et dans Kerberos à chaque fois qu’un mot de passe est changé dans LDAP. Ainsi on pourrait, si je comprends bien, avoir trois services distincts et les mêmes mots de passe partout. Ceux-ci sont dupliqués, mais il y a un seul endroit pour les changer : LDAP. Ça peut être intéressant et peut énormément simplifier la configuration de l’ensemble, chacun serait alors configuré comme si le reste n’existait pas. Cela signifie que toute application qui sait parler à LDAP et qui permet à l’utilisateur de changer ou récupérer son mot de passe fonctionnerait pour tout, LDAP, Samba et Kerberos, le pied ! # Chez vous et dans le futur, comment c’est ? J’utilise donc encore Samba à l’ancienne, avec LAN Manager, et il serait temps de passer à Kerberos. Aussi, maintenant que j’ai de l’expérience dans LDAP, autant en profiter. J’ai notamment des longueurs dans les connexions/déconnexions de Windows 7 et je soupçonne quelques _timeouts_ sous-jacents, probablement que les nouveaux clients essaient des protocoles plus récents avant de passer au reste, en secours. Ça marche mais ça pourrait être mieux. Il y a, semble-t-il, dix mille manières de combiner tout ça. Si j’ai bien compris, Samba peut aujourd’hui fournir lui-même le service Kerberos, ou utiliser un service tiers (merci de confirmer/infirmer selon votre expérience). Samba peut aussi utiliser un serveur LDAP tiers (merci aussi de confirmer/infirmer selon votre expérience). ;-) Est-ce que par exemple cela signifie que Samba peut fournir un serveur Kerberos avec une base utilisateur fondée sur LDAP ? Si oui est-ce que Samba enregistre ses utilisateurs selon les schémas habituels (ce qui permettrait d’avoir le même annuaire pour les utilisateurs Samba et LDAP, ou dans un schéma différent dans une autre arborescence (comme fait Kerberos) ? Et pour les « bonnes pratiques », que conseillez-vous et que faites-vous ? Utiliser Samba pour tout faire est certainement l’option la plus pratique et la plus facile à court terme, mais pas nécessairement la plus robuste à long terme. Je me souviens de la dernière grande montée de version de Samba que j’ai faite il y a quelques années. Pendant des mois de labo tout allait bien : j’avais cloné quelques clients comme cobaye et reproduit le réseau avec de vrais postes identiques et une copie conforme du serveur en labo et la migration se faisait sans heurt. Mais ce fut la catastrophe lorsque j’ai appliqué la migration en vraie. En fait, si la migration de Samba a pris quelques minutes seulement, il a fallu réenregistrer dans le domaine 80% des machines, manuellement bien sûr sinon ce n’est pas drôle. La migration avait été commencée vers 19h après le départ du dernier employé, et à deux, on a terminé juste avant l’arrivée du premier employé, à 5h du matin, pas avant. L’horreur. Plus jamais ça ! Cette anecdote m’a appris qu’on a beau prendre ceinture et bretelle (n’en déplaise à Franck), ce n’est pas encore suffisant. On peut reproduire une copie exacte du réseau avec des copies exactes des clients avec exactement le même matériel, et rater une régression qui n’est visible que lorsqu’on y va en vrai. Tout ça parce que la maquette ne fait pas 20% du parc machine en terme de matériel (normal, c’est une maquette). Je veux éviter que ce type de désagrément m’arrive dans le futur, et j’ai le pressentiment que tout faire reposer sur Samba n’est pas une mauvaise idée. Samba fait trop de choses. J’imagine que lorsque j’aurais un Kerberos et ou un LDAP commun avec Samba, je m’en servirai pour autre chose qu’identifier des utilisateurs Windows, et je ne veux pas prendre le risque qu’un problème dans Samba mette en panne tous les autres hypothétiques services. Je me dirige plutôt vers un LDAP/Kerberos à part, probablement sur une autre machine que je pourrais mettre à jour indépendamment de celle qui héberge Samba, mais je ne sais pas encore comment faire, si je dois utiliser `slapd-smbk5pwd` ou reproduire la très complexe mais très puissante configuration présentée plus haut. J’ai une contrainte, j’ai déjà une très grande base de compte utilisateurs, et si je pouvais conserver les mots de passe ce serait bien. LDAP permet d’importer des _hash_ de mots de passe dans divers formats en indiquant le format, ça c’est vraiment super, ça signifierai que je peux importer plein de mots de passes et hop ça marche. Le problème est que ce n’est pas compatible avec la configuration que j’ai présenté plus haut avec Kerberos, car le schéma Kerberos est différent que le schéma standard des annuaires utilisateurs dans LDAP, même quand la base utilisateur de Kerberos est stockée dans LDAP. Je ne crois pas pouvoir importer ces _hashs_ dans Kerberos. Le greffon `slapd-smbk5pwd` ne résout pas non-plus le problème puisqu’il ne fonctionne que pour les mots de passe nouvellement créés. Je peux aussi décider que tous les mots de passe des utilisateurs soient recréés, c’est bien de ne pas garder trop longtemps les mêmes mots de passe dit-on, ce serait l’occasion de tout rafraîchir. Si je décide cela ça peux choisir la solution technique que je veux. Ce journal est donc aussi un appel à témoignage et une invitation à partager votre expérience : Et vous, que faites-vous ? comment faites-vous ? Avez vous choisi de tout déléguer à Samba ou avez-vous distribué les services entre plusieurs logiciels ? Quels sont les problèmes que vous avez rencontré dans vos différentes configurations ? Avez-vous des conseils pour configurer un Samba afin qu’il plaise au mieux aux outils Microsoft ? Et en fait, quel est l’exact rôle de Kerberos, mais surtout de LDAP, pour Samba ? En gros, qu’est ce que fait Samba avec ces technologies ? Je n’ai pas encore dans ma tête un aperçu bien clair du paysage, si vous en savez plus, n’hésitez pas à éclairer ma lanterne, ça profitera à d’autres, la _[[disputatio]]_ est publique ! :-) Voici donc ma _questio_ développée, à vous le micro !

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