Sommaire
- Mais quel est le sujet au juste ?
- Ce que j’ai l’habitude de réaliser
- Ce qui est encore un grand mystère pour moi
- Chez vous et dans le futur, comment c’est ?
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,groupen 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 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, 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, 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.
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), 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 !
# stockage ldap
Posté par flan (site web personnel) . Évalué à 2.
Merci pour ce journal intéressant.
Pourquoi avoir stocké kerberos dans ldap ? De mémoire, ça oblige à utiliser MIT et non Heimdal et ça rajoute une vulnérabilité, mais c'est vrai que ça facilite les sauvegardes.
[^] # Re: stockage ldap
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Je ne sais plus pourquoi, cet exemple est un projet auquel je n’ai pas touché depuis longtemps. Je crois que c’était juste pour n’avoir qu’à sauvegarder LDAP pour tout sauvegarder, tout en gardant une authentification commune à Kerberos et LDAP.
Pourrais tu expliciter un peu ? en quoi MIT krb5 rajoute une vulnérabilité par rapport à Heimdal ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: stockage ldap
Posté par flan (site web personnel) . Évalué à 3.
désolé, ce n'était pas clair :
- ça oblige à utiliser MIT car Heimdal ne permet de stocker sa base dans LDAP (et Heimdal est obligatoire si tu veux faire du pkinit avec OS X).
- ça ajoute une vulnérabilité dans le sens où tu as une dépendance double (LDAP dépend de Kerberos, qui dépend de LDAP). Je ne sais pas trop comment ça se passe si l'un des deux met un peu de temps à démarrer, par exemple.
[^] # Re: stockage ldap
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Ah ok je comprends, j’avais compris « vulnérabilité » dans le sens qu’utiliser MIT krb5 était moins sûr qu’utiliser Heimdal et que donc MIT krb5 serait moins sûr qu’Heimdal, j’avais lu ça dans le sens de vulnérabilité à des attaques, pas dans le sens d’une vulnérabilité aux pannes. :-)
En fait LDAP n’a pas besoin de Kerberos pour démarrer, ce sont les clients qui ont besoin de Kerberos pour se connecter au LDAP.
Kerberos ne peut probablement pas démarrer sans LDAP (à vrai dire je ne sais pas s’il échoue si LDAP manque ou s’il l’attend patiemment, je n’ai plus ce projet sous la main depuis longtemps), mais LDAP peut démarrer sans Kerberos, donc quelque soient les doutes, il suffit de démarrer OpenLDAP avant MIT krb5 et tout va bien.
Ce sont les clients LDAP qui doivent attendre le service Kerberos d’être après le service LDAP, donc en fait il n’y a pas de problème de compétition si tout cela est fait en séquence.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: stockage ldap
Posté par flan (site web personnel) . Évalué à 2.
Ok, merci.
Note : je me suis planté, Heimdal accepte de stocker sa base dans LDAP. Va falloir que je regarde pourquoi je ne l'ai pas fait également (j'étais parti sur cette solution pour MIT Kerberos, avant de basculer sur Heimdal).
[^] # Re: stockage ldap
Posté par Dreammm . Évalué à 1.
Le protocole de réplication d'openldap, syncrepl, est très performant et très facile : c'est un serveur esclave qui va faire une requête sur un serveur maître.
Pour répliquer un serveur kerberos, au contraire, c'est le serveur maître qui initie la réplication.
Au niveau architecture, cela veut dire que quand tu vas vouloir ajouter un serveur esclade, tu vas dans le cas de kerberos modifier la conf du serveur maître, et dans le cas du ldap, non.
Stocker les données kerberos dans openldap, c'est donc profiter d'un meilleur service de réplication, gratuitement.
# Avec Active directory
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
Bonsoir,
suivant ton besoin et ton infra existante, je dirais que si tu a un Active Directory sous la main, utilise le meilleur des 2 mondes.
tout l infra LDAP/Kerberos de l AD qui est pour le coup vraiment bien faite, avec redondance, réplication, gui su tu es fénéant, mais aussi le cli si tu es courageux ou habituté.
cela fait au moins 10 ans que est comme ca que je travail, et aucun problème n est survenus.
l ajoute de user, groupe, management peu se faire aisément par des requête ldap et un ticket kerberos d un user ayant les droits sur l AD avec le positionnement d ACL adhoc.
il y a maintenant pléthore de doc sur le web pour cela.
[^] # Re: Avec Active directory
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Je n’ai pas d’AD. Toute l’infra serveur est sous Debian, en fait toutes les machines qui ne sont pas des postes clients sont sous Debian (routeurs, serveurs, jusqu’au sauvegarde. Ma philosophie est qu’une distribution est d’abord une méthode de travail avant d’être un dépôt logiciel, ce qui fait que je choisis mon matériel et mes logiciels (ceux que moi j’utilise) en fonction de sa compatibilité avec la méthode de travail. Ce qui jusqu’ici a vraiment très bien marché.
En fait, même le dernier service windows-only qui reste tourne sous wine, ça a libéré une machine qui ne servait qu’à ça et est devenu plus fiable et plus facile à maintenir.
Par contre côté client, quasiment (c’est à dire tous les postes à part les admins et quelques rares postes qui ne servent qu’à afficher des infos) tout est sous Windows. Parce qu’Office, parce que plein d’appli-métier windows-only, etc. Bref, tous ces trucs que moi je n’utilise pas mais que tous les autres utilisent.
Je n’ai jamais touché un seul AD de chez Microsoft de toute ma vie, jusque là j’ai toujours pu faire sans (et ça a toujours marché sans), ce qui est un très bon point pour Debian (la méthode que j’ai choisi) et GNU/Linux en général. ;-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Avec Active directory
Posté par BAud (site web personnel) . Évalué à 6.
Quand quelqu'un t'indique AD comme exemple, tu peux désormais lui répondre https://access.redhat.com/products/identity-management-and-infrastructure/
Cela intègre samba, kerberos, ldap, le changement de mot de passe qui semble te manquer, tout ce dont il y a besoin en entreprise… Bon, ça ne règle pas tout non plus (interop NFSv4 / kerberos ne reste pas très simple à mettre en œuvre), mais cela règle 90% des besoins, le reste bin faut bosser par rapport au spécifique…
Tu as bien de la chance de n'avoir pas d'intérop' AD ou poste client windows à gérer, les consultants microsoft débarquent (certains très compétents, d'autres euh comment dire ?)
Même si la techno Microsoft est désormais d'un niveau correct, j'ai croisé si peu de monde la maîtrisant et sachant la déployer qu'il vaut sans doute mieux investir dans du Red Hat (au moins ils sont motivés), c'est le même prix de mise en œuvre, à voir pour le support et la stabilité : cela dépend de ton nombre d'utilisateurs, de l'équipe support (et sa formation… j'ai déjà vu des catas liées à l'AD).
Contrairement à Samba qui ne fournit que la fonctionnalité pour le faire, l'avantage de Red Hat est de te proposer une solution clé en main pour le déploiement, ça existe dans Debian (vu que ce que fait Red Hat est reversé en libre), mais moins intégré, à toi de configurer plus de choses.
[^] # Re: Avec Active directory
Posté par palm123 (site web personnel) . Évalué à 2.
Tiens ça me fait penser à une grosse boite, qui mettait son AD sur du NAS (oui, ce n'est pas une faute de frappe, NAS et pas SAN), lequel partait en sucette quand il y avait trop d'accès, ce qui arrivait très souvent la nuit. La personne d'astreinte se faisait réveiller "le job xxx n'a pas tourné", et oui, le job n'a pu trouver le user à utiliser…
ウィズコロナ
[^] # Re: Avec Active directory
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
et bien la ou je suis aucun pb d interop avec l AD, j ai tout mis en place.
90% des dev sont en linux(commence en gentoo en 2001 a cause de seul distrib correcte qui marchais en 64bits a l époque), un AD, du kerberos
si tu dis que les admins sont mauvais avec un AD c est que ce ne sont pas des admin, juste des pousses boutons.
la majeur partie des admins que je côtoie qui font du windows, sont au moins au 3/4 en powershell en cli.
pour le office regarde ca, http://wps.com/fr/wps-office-for-linux/
pas open source (pas plus que office) c est gratuit et ca tourne sous linux et très proche de office.
pas un ersatz, comme open/libre office quoique que l on en pense ou dise.
[^] # Re: Avec Active directory
Posté par GG (site web personnel) . Évalué à 2.
Si à 50 ans tu ne sais pas administrer un AD tu as raté ta vie d'admin sys?
Pour un admin sys Linux, c'est obligatoire de connaître AD?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Avec Active directory
Posté par SauronDeMordor (site web personnel) . Évalué à 5.
Pour un admin sys se refuser de connaître l ensemble du spectre technologique est un aveux d incompétence. La maîtrise c est autre chose. Mais refuser les autres techno est idiot. Ça veut pas dire que il faille absolument l utiliser,mais de savoir de quoi on parle.
De plus les environnement sont très souvent multi os. Donc on a souvent des windows,des unix et des linux.
[^] # Re: Avec Active directory
Posté par Faya . Évalué à 2.
Un ersatz, je sais pas, mais je me vois mal proposer à mes clients une solution en alpha :http://wps-community.org/downloads
Sauf si j'ai mal cherché
[^] # Re: Avec Active directory
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Si c’est pas Mocrosoft Office, ce n’est pas Microsoft Office. point, il n’y a pas à discuter.
Ceux qui acceptent de ne pas utiliser Microsoft Office sont très content de LibreOffice, alors non, je ne chercherais pas autre chose de pas libre.
Ceux qui s’opposent à LibreOffice s’opposent parce que ce n’est pas Microsoft Office, donc il y aurait la même opposition pour n’importe quoi d’autre, fut-ce cet autre non-libre et en version alpha.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Avec Active directory
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
J'utilise FreeIPA sur lequel est basé cette solution. Ça juste fonctionne et c'est pas mal documenté.
Sur redhat like freeipa-client fait juste le job sous debian, le paquet existe mais je ne l'ai pas testé, sous FreeBSD et je pense pas mal d'autres Unix, l'intégration se fait à la main via sssd. Par contre pour Windows si les besoins ne sont pas simple, il faut passer par un AD (bientôt samba4 visiblement https://www.redhat.com/archives/freeipa-users/2015-May/msg00004.html).
Ne connaissant pas Windows, je ne sais pas si ça répond à tes besoins.
Pour moi les plus sont avant tout l'ui (web + cli + API), la gestion des clés ssh, ssh fingerprint et droits sudo, mappage selinux, le sucre (scripts de setup, réplication, backup …), la page d’enrôlement pour firefox, l'intégration avec The Foreman. Je n'ai par contre pas encore trop touché à la PKI.
Manque la récup des mots de passes.
http://www.freeipa.org
# Samba 4
Posté par jolitorax . Évalué à 4.
J'avoue que j'ai lu le journal en diagonale, mais samba4 répond à ce genre de problématique.
Il faut juste accepter de passer sur l'authentification Active Directory qui est désormais le standard de samba4 en lieu et place d'openldap. C'est un tout en un: Samba4 contient un annuaire AD, un serveur DNS, et kerberos. L'avantage c'est que pour avoir tout ça, il ne faut presque que configurer le smb.conf. On a une seule base de mots de passe, donc plus de problèmes de synchronisations entre le monde Windows et Linux.
On peut interroger samba4-Active Directory comme un annuaire LDAP classique à l'aide de nslcd ou passer par sssd (plus chiant à mettre en œuvre je trouve) pour faire du kerberos.
On a mis samba4 en place pour authentifier nos services et l'accès aux serveurs et à certains postes de travail Linux, pour l'instant on ne l'utilise que comme un annuaire LDAP
Nous avons testé l'authentification avec kerberos sous Linux et ça fonctionne aussi. Évidement les postes Windows s'authentifient sur le contrôleur de domaine samba4 Active Directory, avec du kerberos donc.
[^] # Re: Samba 4
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
C’est très intéressant, ça signifierait que par exemple, pour centraliser l’authentification d’appli web façon LDAP (wordpress, redmine, ownCloud) et d’autres service réseaux façon Kerberos (XMPP, IMAP, SMTP), il suffirait d’installer un Samba4 et de ne pas s’embêter avec OpenLDAP et MIT krb5, et ne rien activer des fonctionnalités ordinaires (comme les partages CIFS) ?
En fait je trouve ce Samba4 très intéressant, mais je m’inquiète un peu de tout lui déléguer, le Kerberos, le LDAP, et les partages réseaux, ça fait beaucoup je trouve, et je préfère m’inquiéter dès maintenant de ce que pourrait être une future migration quand il faudra mettre à jour vers un hypothétique Samba5, et que tout, tout reposera dessus. Plus tard, il sera trop tard. :-)
Donc c’est aussi ma question, pour ceux qui administrent des parcs assez conséquents (au moins 100 utilisateurs), voire plusieurs parcs, est-ce que vous déléguez tout à Samba, ou séparez un peu les tâches ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Samba 4
Posté par claudex . Évalué à 4.
Si tu veux utiliser Samba4 comme un active directory, tu es obligé de lui confier le LDAP1. Il n'y a que le DNS qui peut être externalisé dans Bind.
Durant le développement, ils se sont rendu compte que les implémentations existantes ne permettaient pas de répondre aux exigences de MS pour un AD, et ils ont trouvé plus simple de de le développer eux-même que d'intégrer des patch ailleurs, surtout qu'ils devaient un peu tatonner pour voir ce qui était nécessaire. ↩
« 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
[^] # Re: Samba 4
Posté par jolitorax . Évalué à 1.
Oui, c'est comme ça que nous l'utilisons. Par exemple l'un des serveurs Linux qui héberge Wordpress est authentifié sur samba 4 à l'aide de nslcd. Il voit le Samba4 AD comme un simple serveur ldap(s). Par contre l'instance de Wordpress est connecté à l'aide du plugin active-directory-integration sur le même Samba4 AD et le voit comme un annuaire AD.
Dans le cas de Wordpress nous utilisions auparavant le plugin wpmuldap, mais il n'est plus activement développé. Ce fut une bonne raison pour passer sur le plugin active-directory-integration, bien que sous le capot l'annuaire d'authentification soit le même.
Même chose pour Owncloud, Drupal et d'autres que j'oublie certainement. Nous avons un samba4-ad et un samba4-ad-replicat sous Debian Jessie et un serveur de fichiers qui gère les partages Windows sous Centos 6 toujours sous samba4. Lui est juste client du serveur samba4-ad. Le serveur de fichier fait aussi du NFSv4, mais nous n'avons pas tenté de faire du kerberos NFS.
Pour la migration, il faut repartir de zéro. La montée en version majeure chez Samba est très lente et c'est un compliment. C'est l'occasion de refaire des choix en accords avec les technologies actuelles.
Pour mettre des dates en face de tout ça et par un curieux télescopage des calendriers et des besoins, on a toujours monté des infrastructures Samba lors des sorties des versions majeures. Notre première infra en Samba 3.0.2a nous l'avons montée en 2004. Celle ci a commencé en Samba 4.0.0 en Janvier 2013 et aussi toujours sur des serveurs Debian. (Là aussi c'est un hasard !)
Nous avons environ 800 personnes dans notre annuaire et c'est lui qui gère tout à l'aide d'un réplicat en cas de panne.
Tous nos nouveaux serveurs, services et postes de travail depuis un an migrent d'un ancien serveur LDAP hors de notre périmètre vers notre authentification Samba4-AD. Je n'ai pas trop d'idée de combien s'authentifient aujourd'hui sur le serveur Samba4-AD, je dirais au doigt mouillé entre 50 et 150 machines.
[^] # Re: Samba 4
Posté par SauronDeMordor (site web personnel) . Évalué à 0.
je gère plusieurs centaines de machine physiques plus des virtuelles + des containers cela doit être un peu plus d un millier en tout
l approche de séparer les services est vital, séparer les SPOF. et de tout mettre absolument en redondance.
déjà quand tu doit changer de machine/serveur, c est moins pénible
il faut aussi tout mettre dans un puppet/chef/(ansible)/salt, pour refaire la conf a l identique de tes machines. mais si tu envisages >100 c est que tu ne fais pas tout à la la main.
ensuite une fois goutté à kerberos, tu aura envie d un SSO basé sur kerberos, avec CAS par exemple de jassig, les modules apache(ou autre httpd) cas, et la le bonheur plus de mot de passe sur le réseau :).
# Microsoft Active Directory
Posté par koopa . Évalué à 2.
Voici mon expérience dans le cadre de la gestion d'un parc informatique mixte (80% Windows, 20% Linux) dans une moyenne entreprise de 100 personnes.
J'ai essayé divers d'annuaires LDAP (389ds, Apache DS, OpenDJ, OpenLdap) pour centraliser les authentifications, et finalement j'ai trouvé que le plus facile était encore de tout regrouper sur Microsoft Active Directory. AD s'installe en quelques minutes et offre une infrastructure multi-maître. La gestion au quotidien ne nécessitent pas beaucoup de compétences. Grâce à la granularité fine des privilèges et on peut même déléguer une partie de la gestion en dehors du service informatique. Par exemple on peut déléguer aux chefs de service le privilège de réinitialiser les mots de passes de leurs employés.
De plus AD est un standard de fait. Il est donc très supporté par tous les clients (Windows, Linux, MacOS, carte DELL iDRAC, NAS, etc.)
Pour Linux on trouve même la documentation chez Microsoft:
https://technet.microsoft.com/en-us/magazine/2008.12.linux.aspx
De toute façon, même si on arriverait à se passer de AD, il faudrait quand même acheter des licenses Windows Server pour utiliser les accessoires: WSUS, Terminal Server et ISS (réclamé par l'ERP)
Contrairement aux grandes entreprises qui peuvent amortir les développement grâce à la taille de leur parc, les PME n'ont guère le choix, et sont obligé d'acheter Windows Server car les autres alternatives ne sont pas rentables à leurs échelles.
[^] # Re: Microsoft Active Directory
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Et pas Samba ? :-)
Ou peut-être ces expériences étaient-elles avant que Samba ne sache en faire autant ?
Oh, merci pour le lien, ce document est très intéressant à lire !
Parfois je rencontre des problèmes “XY” : quand il y a déjà toute l’infrastructure et qu’au lieu d’exprimer des besoin (exemple : « j’ai besoin de tel disque partagé »), certains expriment des solutions, par exemple quand le fournisseur de logiciel qui ne connaît que son environnement de développement et qui arrive avec des gros sabots en disant « comment puis-je mettre mon AD pour pouvoir mettre en réseau le logiciel sur le nouveau poste que je vous facture » et qui ne propose pas d’autre manière de fournir son logiciel qu’en remplaçant le parc complet avec ses machines et son AD, à-la-façon-de-chez-lui. Si, si ce type de fournisseur existe.
Bref, malheureusement, souvent quand je vois quelqu’un pousser un AD de chez microsoft, c’est qu’il n’exprime pas son besoin. Si les autres alternatives ne sont pas rentables à petite échelle (ce qui est possible), c’est peut-être aussi parce que l’AD fait partie du paquet obligé pour être conforme à de nombreux fournisseurs (personne n’a été viré pour avoir choisi Microsoft). Utiliser AD est donc infiniment plus facile puisque souvent, ne pas utiliser le produit Microsoft ferme la porte du support…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Microsoft Active Directory
Posté par flan (site web personnel) . Évalué à 5.
disclaimer : je ne suis pas admin sys, je fais plutôt ça par curiosité
J'ai un peu regardé Samba 4, et au final j'ai repris l'ensemble DNS/LDAP/Kerberos. Ce n'est pas encore assez sec à mon goût. Ils sont partis pour beaucoup de Python… mais Python 2 seulement alors que Python 3 est annoncé depuis très longtemps et qu'il est assez facile de faire un code compatible 2/3. Il y a quelques fonctions que je n'ai jamais réussi à faire fonctionner en utilisant l'API (absolument pas documentée, d'ailleurs). Pour les GPO, la seule interface de configuration fournie est le client lourd Windows. On ne peut pas ajouter ses propres schémas LDAP, donc il faudra probablement un LDAP à côté quand même.
[^] # Re: Microsoft Active Directory
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Tu veux dire que tu as pris l’option LDAP et Kerberos à part (genre OpenLDAP + krb5 ou similaire) ?
Je ne crois pas que ça changera quelque chose pour moi tant que ça marche, je ne m’attends pas à toucher à ce code… Enfin jusqu’à maintenant je n’ai jamais eu à toucher à quoi que ce soit qui ressemble à du code avec Samba, excepté le fichier de config de samba lui-même, et des scripts windows que samba sert comme des fichiers… Donc à moins que j’ignore quelque chose, je ne me sens pas vraiment concerné par le langage ou l’API… Ai-je raison de ne pas me sentir concerné ? :-)
Hmmm, c’est typiquement le genre d’info que j’attendais. Je crains que Samba fasse tout ce dont il a besoin, mais pas plus. En même temps, est-ce que c’est grave de cantonner Samba à ne faire ce que qu’il fait ?
Par exemple si venait à se faire sentir le besoin d’un LDAP pour y placer les coordonnées des contacts pour IPBX (exemple sorti du chapeau magique), il est très probable que je monte un LDAP à part histoire d’avoir deux services indépendants.
Connais-tu des exemples où il serait nécessaire d’ajouter des schémas au LDAP utilisé par Samba ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Microsoft Active Directory
Posté par flan (site web personnel) . Évalué à 3.
Actuellement, je n'ai pas du tout de Samba (je progresse assez lentement : je n'ai pas beaucoup de temps à consacrer au projet, je cherche à avoir une infra complète et je veux que tout s'installe automatiquement, du coup j'en suis encore à l'étape de la supervision après avoir mis la couche Kerberos/OpenSSL/LDAP/NTP/DNS/DHCP).
Je ferai probablement du Samba, mais uniquement en partage de fichiers (et ce n'est même pas sûr, j'hésite avec OpenAFS).
L'API Python peut être pratique si tu veux faire des scripts pour créer les utilisateurs (ou équivalent), plutôt que d'avoir un code Python qui appelle du shell qui appelle du Python. A part ça, pas de raison particulière.
A plus long terme, ça veut dire avoir une dépendance supplémentaire à du Python 2 alors que les distribs passent à Python 3 par défaut.
Si tu acceptes d'avoir deux LDAP, tu dois pouvoir t'en passer ; j'avais besoin de schémas pour Samba, Asterisk et Kerberos (et perso je souhaite avoir un seul LDAP).
[^] # Re: Microsoft Active Directory
Posté par lolop (site web personnel) . Évalué à 2.
"par défaut"… je n'en connais qu'une qui ait fait cela: Arch. Toutes les autres proposent Python2 et Pyhon3 qui cohabitent sans problème, la commande
pythonétant Python2 (sauf sur Arch…).On peut regretter qu'ils soient partis sur Python2 - encore qu'il faut voir à quel moment ils ont commencé leurs développements - mais c'est un choix pérenne et AMA ça ne peut pas être une raison valable de sélection d'une solution par rapport à une aurte.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Microsoft Active Directory
Posté par Larry Cow . Évalué à 1.
Ah merde. Même en passant par l'administration de schéma fourni avec Windows (le "client lourd"), du coup? C'est assez limitant, ça, tout de même.
Est-ce qu'au moins il arrive à répliquer depuis un AD Windows sur lequel des modifications de schéma ont été appliquées?
[^] # Re: Microsoft Active Directory
Posté par Thomas Debesse (site web personnel) . Évalué à 2. Dernière modification le 04 novembre 2015 à 17:33.
Hum, j’ai lu ici https://wiki.samba.org/index.php/Samba_AD_schema_extensions
Donc il semble qu’on puisse mettre à jour les schémas avec une option explicite.
Cela dit, ce qu’ils disent est intéressant, s’il est si risqué que ça de toucher aux schémas parce que ça peut mener très facilement à des incompatibilités avec Microsoft, alors utiliser volontairement un LDAP tiers n’apporte que la possibilité d’avoir ces mêmes risques.
Il est probable que j’installe un samba sur une machine virtuelle qui ne tienne que le rôle du KDC et du LDAP, et que mes serveurs samba actuels (qui servent des fichiers etc.) ne fassent que la gestion des fichiers en déléguant désormais leur authentification au Samba/KDC. si plus tard j’ai besoin de faire du LDAP avancé, il me sera très probablement possible de monter un OpenLDAP à coté qui authentifie ses utilisateurs auprès du Samba/KDC.
L’idée est de séparer le rôle du KDC pour pouvoir le maintenir indépendamment du reste, comme je ferais avec un Kerberos qui ne ferait que ça, mais en utilisant Samba comme ça ça limite la complexité de la solution (un seul type de logiciel à maintenir, même s’il y a plusieurs instances).
ce commentaire est sous licence cc by 4 et précédentes
# Je profite de la présence de compétences LDAP sur ce fil de discussion...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Pour le logiciel Tracim que je développe, on m'a demandé à plusieurs reprises si il supportait LDAP. C'est une fonctionnalité que je souhaite développer, mais je ne connais pas les bonnes pratiques et les besoins/attentes d'admin sys par rapport à ça.
Tracim est un outil de gestion/diffusion collaborative documentaire. Il s'appuie sur différents concepts, entre autres :
- des comptes utilisateurs
- des espaces de travail auxquels les utilisateurs sont associés via un rôle (admin, contributeur ou lecteur) ; le rôle indique quel type d'interactions l'utilisateur peut faire sur le contenu
- des contenus (fichiers, discussions, pages type wiki) associés à un espace de travail.
(test possible en ligne sur le "bac à sable" si vous voulez mieux comprendre - http://demo.tracim.fr/)
Si j'implémente le support de LDAP, le "b-a-ba" me semble de proposer l'authentification via LDAP, mais qui de la gestion des "espaces de travail" et des droits associés ? cela doit être géré dans LDAP et récupéré/dupliqué par mon soft ? Si on part sur ce principe, si un admin souhaite créer un nouvel espace de travail et y inviter des utilisateurs, cela se passe dans LDAP et je dois synchro ma base avec LDAP ?
Question subsidiaire : dans le concept de base, j'ai prévu un rôle intermédiaire qui permet de créer des espaces de travail. Cela signifie, si j'ai bien compris la pratique LDAP qu'il faudrait que mon soft puisse créer des groupes dans LDAP, ce qui est à bannir (cf citation ci-dessus).
Du coup… que me conseillez-vous d'implémenter ?
Solution 1 : simple authentification via LDAP. la gestion des groupes de travail et du rôle de chacun est alors géré dans Tracim (dans LDAP on va créer un utilisateur "admin tracim" qui pourra gérer sur tracim les espaces de travail et l'association des utilisateurs aux espaces de travail
Solution 2 : déporter toute la gestion des droits d'accès aux espaces de travail dans LDAP, et du coup il faut que Tracim synchronise les espaces de travail qu'il gère avec des groupes LDAP ?
Solution 3 : gérer au niveau tracim et autoriser la modif LDAP (mais ça semble banni)
Autre sujet : en pratique, que faire des fonctionnalités changement de mot de passe, reset du mot de passe par email, invitation d'un utilisateur etc ? Je désative tout ?
Merci d'avance pour vos retours.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je profite de la présence de compétences LDAP sur ce fil de discussion...
Posté par BAud (site web personnel) . Évalué à 3.
Solution 1 clairement. L'authentification est ainsi déportée (hormis distinction de groupe user_admin / user_normal voire un autre groupe de haut niveau : parfois admin technique et admin fonctionnel sont distingués). Les habilitations liées aux objets métiers gérés dans ton appli, restent dans ton appli, avec la granularité et les évolutions que tu souhaites.
J'ai souvent vu la solution 2 mise en avant, jamais implémenté (ou retour arrière…).
Pour la solution 3, moui, là tu en viens à squatter le LDAP d'authentification pour le fonctionnement de ton application, c'est rarement opérationnel de mélanger les genres ;-)
moui, propose de les désactiver dans un fichier de conf', éventuellement en proposant un redirect vers la page centralisée d'auto-assistance utilisateur.
Tu as aussi la solution 4 de gérer aussi du webSSO avec du SAML2.0, mais cela viendra ensuite ;-) déjà implémenter du
LDAP /LDAPS cela le fera bien.[^] # Re: Je profite de la présence de compétences LDAP sur ce fil de discussion...
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Ce n’est pas nécessairement à bannir. Le truc c’est que j’ai vu des applis web qui demandaient le mot de passe root, et ça je dis non.
À mon avis le mieux est de créer un groupe privilégié avec des ACL bien taillées pour l’usage (par exemple, qui a seulement le droit de créer des groupes dans une arborescence particulière et rien d’autre), et tu crées un utilisateur de maintenance qui appartient à ce groupe.
Le problème des applis web qui font du LDAP, c’est que toi tu peux administrer le LDAP et quelqu’un d’autre développe l’appli web, et là tu n’as pas la moindre envie de mettre ton mot de passe root dans un fichier de config.
Typiquement tu fournis un espace disque, un server http, un serveur mysql, un serveur ldap déjà peuplé, il faut que quelqu’un d’autre que toi crée un blog qui soit accessible de tout utilisateur connu du ldap.
À ce quelqu’un d’autre tu donnes un dossier avec les bon droits unix, tu mets la bonne config apache/nginx, tu fournis une base de donnée, mais non, tu ne donnes pas le mot de passe root de ton LDAP, le plus simple est encore de ne faire que de l’authentification (aucun mot de passe à donner, ça utilise celui de l’utilisateur), et si tu as besoin que l’appli créée de groupes, et bien fait des ACL. Le fait de se limiter à la simple authentification simplifie beaucoup les choses, mais bien évidemment, parfois ça ne suffit pas.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Je profite de la présence de compétences LDAP sur ce fil de discussion...
Posté par Thomas Debesse (site web personnel) . Évalué à 2. Dernière modification le 29 octobre 2015 à 18:40.
Au fait quand tu écris :
si ça correspond à :
alors je pense qu’on est sur la même longueur d’onde.
Ce que je voulais dire, c’est qu’il faut éviter au maximum de donner des droits qui ne servent à rien. C’est du bon sens, mais parfois on tombe sur des outils qui ont du mal avec le bon sens (c’est comme le chmod 777, bien sûr, c’est tellement plus simple)… :/
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Je profite de la présence de compétences LDAP sur ce fil de discussion...
Posté par MCMic (site web personnel) . Évalué à 2.
La deuxième solution est à privilégier.
C’est bien de faire de l’auth LDAP, mais pouvoir baser les droits sur les groupes/rôles LDAP est vraiment un plus.
Pense à toujours donner la possibilité de configurer les filtres et attributs à utiliser (surtout pour les groupes/rôles beaucoup de schémas différents existent).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.