Journal Aventures en LDAP land...

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
0
23
juil.
2008
Hello cher journal,

Je souhaite mettre en place un serveur mail multi-domaine avec possibilité de définir des sous-administrateur qui pourraient administrer leur propre domaine.

J'ai déjà mis cette solution en place avec Cyrus et web-cyradm qui fonctionne très très bien : ultra simple (à utiliser, pas à installer), élégant, minimal.

Cependant, je me suis mis au défi d'unifier mes comptes Jabber et mail (pas de SSO. Juste partager le même mot de passe).

Pour cela, je ne vois à priori qu'un seul outil : LDAP

Je vous avais fait part de mes interrogations à ce sujet :
https://linuxfr.org//~ploum/26432.html

Le résultat est plus que décevant : je ne comprends toujours rien à rien ! Après des nuits blanches, je ne sais même pas où je suis censé arrivé.

Une grande constante dans toutes les docs et tutos que je lis est la perte de patience du rédacteur. Au début, on te prend par la main et on t'explique de long en large comment compiler, comment déplacer un fichier d'un répertoire à un autre, comme installer un package avec apt-get sous Debian. Super, merci les gars. Et puis dès que ça devient un peu complexe, on te sort des "Now create your admin user in your CN and modify the file.conf to use the SSL certificate and allow brol bazar". Duh o_O ! Et je fais comment ça moi ? Ou bien on te coller un fichier de 600 lignes et on te dit de l'adaptez à ta config alors que tu ne piges rien.

Bref...

Récemment, j'ai passé quelques jours sur Gosa :
https://gosa.gonicus.de/
La doc m'explique comment installer PHP de long en large puis l'install plante car visiblement y'a pas de gosaObject. Aucun moyen de savoir ce qui foire ou pas (j'ai suivi le tuto à la lettre). J'ai rien compris. J'abandonne, de toutes façons cela me semble super complexe et je n'ai rien à foutre de Samba, des fax ou des imprimantes en réseau. Je veux juste des comptes unifiés !

Grâce aux sympathiques commentaires demon journal précédent, j'essaye le Mandriva Server : http://mds.mandriva.org/
Je découvre le tuto : http://www.vogelweith.com/debian_server/07_postfix.php (qui lui aussi me donne le plaisir de sauter pas mal d'étapes mais bon)

Après une journée de batailles, victoire, j'ai un Mandriva Server qui fonctionne et je peux ajouter un utilisateur dans mon LDAP. Me reste plus qu'à installer Dovecot.

Seulement voilà :
1) L'interface d'admin a déjà certains plantages dans la gestion des domaines. Mais bon...
2) Je ne vois pas du tout comment je pourrais déléguer la sous-gestion d'un domaine particulier.
3) Je ne veux *pas* d'un compte Unix/$HOME par utilisateur. Un utilisateur a juste droit a sa mailbox, rien de plus. L'identifiant au webmail doit être son adresse mail (tout comme pour Jabber)
4) Admettons que tout le reste fonctionne : je n'ai fichtrement aucune idée de comment brancher mon serveur Jabber là dessus une fois qu'il fonctionnera.

Voilà, je crois que LDAP est un peu trop complexe pour mon petit cerveau. Du coup si vous avez des combines pour simplifier tout ça ou des conseils, n'hésitez pas ! Un grand merci pour les commentaires du journal précédent qui m'ont déjà bien aidé.

  • # 2 sortes d'admin

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

    Celui qui à compris LDAP et les autres .

    • [^] # Re: 2 sortes d'admin

      Posté par  . Évalué à 6.

      Toute une époque qui fout le camp.
      De mon temps, on disait que t'étais pas vraiment admin si t'avais jamais bouclé une configuration fonctionnelle de sendmail.

      En même temps, j'm'en fous, j'ai jamais été admin...

      Par contre, pour jabber et LDAP, ejabberd te fait ça facilement, enfin, de mémoire: j'avais installé un serveur pour les besoins internes de ma boîte, et les admins de l'époque (des super flèches, vous l'aurez compris, puisque j'ai dû installer ejabberd moi-même sachant que je ne suis pas admin...) ont réussi à claquer un virus dans le serveur en question (sous windows, bien entendu), et n'ont jamais réinstallé le serveur jabber (trop compliqué, y'avait un fichier de configuration à éditer sans option graphique "Suivant" "Suivant" "Terminer"). Et moi comme c'est pas mon boulot, j'ai fermé ma gueule en espérant qu'on ne me redemande pas de le refaire, et ça a marché!

      Là l'admin principal s'est barré, et le nouveau sait ce qu'il fait (mais le gars qui avait demandé une messagerie interne s'est barré aussi, alors plus besoin d'ejabberd non plus).

      Je raconte ma vie, tout ça pour dire que quand t'auras fini de galérer avec LDAP, tu pourras scotcher ton ejabberd dessus facilement, parole de non-admin.

    • [^] # Re: 2 sortes d'admin

      Posté par  . Évalué à 10.

      Celui qui à compris LDAP et les autres .

      J'aime beaucoup le « celui ». Ça voudrait dire qu'il n'y a qu'un seul admin au monde qui a compris LDAP ! Du coup, c'est nettement plus rassurant pour les autres. :-)

  • # LDAP est bien mais n'est pas une nécessité

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

    LDAP est très bien pour un certain nombre de service ... par contre, cela necessite une méthode, une rigueur, une organisation assez lourde pour faire une mise en place correcte.

    Concernant GOSA, c'est bien si tu n'utilise que l'API GOSA. Si tu as des besoins spécifiques, cela devient une grosse usine à gaz.

    Apres plusieurs années de satisfaction avec LDAP, j'ai fait à titre personnel un choix plus simple : mes-petits-doigts (tm)(r)(c).

    grâces à mes-petits-doigts (tm)(r)(c) , j'utilise comme outil de centralisation un MySQL.
    Postfix, SASL, courier, pure-ftpd, powerdns, PAM et d'autres logiciels dont on peut customisé les requetes grace au plug-in cerveau(tm)(r)(c) fourni en option avec mes-petits-doigts(tm)(r)(c).

  • # NIS

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

    Sinon pour faire ça tu peux utiliser l'ancêtre de LDAP, NIS (aka. yellow-pages, yp).
    L'inconvénient de NIS c'est qu'il faut que ton réseau soit "sûr", c'est à dire qu'on ne puisse pas sniffer, spoofer, etc. sur ton réseau, parce que les mécanismes de sécurité de NIS sont pas vraiment au top.
    Mais si c'est pour partager un tas d'infos (authentifications, hosts, etc.) de manière simple sur un réseau que tu maîtrises entièrement, c'est super simple à mettre en oeuvre.
    Perso je m'en sers sur mon réseau local filaire pour partager l'auth entre mon desktop, mes serveurs (mails, ssh, etc.) et d'autres trucs encore, et c'est parfait.

  • # LDAP mon amour

    Posté par  . Évalué à 2.

    Now create your admin user in your CN and modify the file.conf to use the SSL certificate and allow brol baza

    En gros, c'est ce que tu auras à faire à chaque fois que tu bidouilleras LDAP, quelque soit le service que tu voudras mettre en place derrière.

    On en parlait déjà ici :

    https://linuxfr.org/forums/10/25446.html

  • # compte multi domaine

    Posté par  . Évalué à 1.

    Un linux magazine expliquait comment réaliser cette installation.

    L'exemple était basé sur une base SQL, mais dès qu'on a compris le principe, tout suit.

    Le pivot central, c'est la BdD, la dedans, tu as tout.

    Le serveur SMTP, c'est postfix. Il vérifie d'une part que le domaine de destination est dans une table, et d'autre part que le destinataire de ce domaine est bien dans une table.
    Le serveur POP/IMAP, c'est dovecot. Il va juste aller chercher les infos de login/pw dans les tables.

    L'idée, c'est de donner les droits aux tables, et tes admins des sous domaines ne modifient que les données dans leurs tables. postix et dovecot refléteront immédiatement les modifs.

    Pour ldap, c'est pareil. Mais le prérequis, c'est de maitriser ldap.

    Enfin, pour le mail multidomaine, regarde les anciens numéros de linux magazine, c'était bien expliqué.

  • # Virtual Mail

    Posté par  . Évalué à 4.

    LDAP ça n'est pas une "solution" clé en main, c'est un outil qui te permet d'en construire une. Il faut plus le voir comme une sorte de "fichier de conf universel distribué sous amphètes" qu'autre chose.

    Pour ton point numéro 3, c'est que tu utilises LDAP comme source pour pam (si je te comprends bien). Si le but est uniquement de faire des utilisateurs de messagerie, il est inutile de passer par là. Normalement, tu expliques juste à Postfix et à ton IMAPd comment aller chercher les infos dans LDAP. Et c'est tout. Pas de notion de comptes POSIX ni rien. Un UID, un mail et un userPassword, et roulez jeunesse.

    Pour Jabber, ça doit suffire aussi. Si tu considères que le JID est le mail, et selon les options de ton jabberd, tu dois pouvoir te contenter de ces quelques attributs. Pas besoin de sortir l'artillerie lourde (gosa). Logiquement, les outils CLI suffisent, avec un éventuellement un client LDAP graphique _générique_ (genre Apache Directory Studio). Mais pas un outil qui t'impose sa manière de ranger ton annuaire, quoi, parce que pour débuter j'avais trouvé ça très rebutant.

    • [^] # Re: Virtual Mail

      Posté par  (Mastodon) . Évalué à 1.

      Ouais, c'est exactement cela.
      L'annuaire LDAP est un référentiel d'utilisateurs, uniquement au niveau applicatif dans ton cas, Ploum. Pas besoin de se prendre la tête avec les schémas spécifiques pour le système etc.

      La petite difficulté, c'est si le mailserver et le jabberd ont des exigences différentes et incompatibles quant à la structure de l'annuaire, mais cela m'étonnerait. Au pire, tu devrait pouvoir même t'en sortir en faisant en sorte que chaque ait une "vue" (terme de mon cru) différente du contenu unique de l'annuaire.

      Il y a une mailing liste, au CRU, avec un tas de gens compétents et prêts à aider.

  • # apt-get install slapd fait sonner le téléphone

    Posté par  . Évalué à 3.

    C'est très simple : taper "apt-get install slapd" sur votre samba 3.x contrôleur de domaine, saisissez votre téléphone, il va sonner.

    En effet, automagiquement, plus aucune authentification windows (vista en tout cas) ne fonctionnera plus.

    Il est bien sûr possible d'utiliser samba avec LDAP, mais j'ai renoncé après quelques nuits aussi (vu qu'on ne peut pas travailler simplement le jour à ces choses-là), parce que j'avais peur que le chemin retour soit encore plus compliqué que le chemin aller, sans parler du nombre de choses à connaître sur slapd pour qu'il fonctionne correctement en failover (des quelques cours soporifiques que j'ai eu sur le sujet j'avais bien retenu la structure d'un arbre ldap, mais je sous-estimais la difficulté).

    Au départ je voulais faire du SSO, rien de moins, entre jabber, dovecot, samba, squid et unix, mais euh, c'est vraiment pas prêt pour l'admin pressé, l'idée de Mouns, un peu plus haut, est alléchante.

  • # Mêmes aventures ici

    Posté par  . Évalué à 2.

    J'ai eu des aventures sensiblement identiques ces derniers jours moi aussi.

    Je voulais installer ldap sur mon serveur, pour avoir des user/mdp unifiés pour du ftp, du ssh, mon webdav (pour utiliser weave, miam), etc etc.

    Google me renvoit sur le wiki.debian.org (la vie est bien faite, c'est une debian qui tourne sur le bestiau). Celui ci m'apparait à première vue comme plutot crade (pas grand chose d'expliqué dedans, beaucoup de trucs "à l'aveugle")... mais bon, je ne connais pas le sujet, normal que ça semble complexe...

    Armé de ma foi, faisant fi des préjugés, je suis à la lettre les instructions.
    L'import des données déconne a moitié (des erreurs cryptique, mais ça a l'air d'avoir malgré tout bien importé après vérification...). Je fais quelques tests, ça a l'air ok...
    Une fois fini, reboot, et là ... impossible de se logger, plus aucun service ne démarre (plus de http ou autre)... redémarrage en mode de secours à distance, rétablir les fichiers, ... oh joie.

    Le lendemain, je tombe sur un autre blog ou un type explique comment il a fait.
    La méthode a l'air très artisanale, mais je tente le coup (apres un GROS backup des fichiers de config avant), je redémarre... ça se logge, impec, l'identification pour le webdav fonctionne, c'est merveilleux...
    Sauf qu'au bout de quelques dizaines heures, je m'aperçois de trucs bizarres... le service de surveillance m'envoit des messages de temps en temps, pour me dire que le service http est down (2-3 fois par jour) (reglé comme du papier à musique, 25 minutes de downtime chaque fois), le ssh tombe aussi parfois (impossible de se logger), des durées sensiblement identiques...
    Les logs n'indiquent rien de particulier, c'est à s'arracher les cheveux...

    Résultat : j'ai remis la bonne vieille authentification htpasswd/shadow/group, ça me semble reparti comme en 14...

    Prochaine étape : tenter le tutorial gentoo, ils sont généralement assez bien fichus (à vrai dire j'ai même rarement vu mieux), mais ça m'angoisse un peu de tout péter encore une fois, et de devoir adapter ça à la sauce debian...

    Bonne chance à toi, c'est vraiment un m****** fou à configurer comme truc je trouve...

    • [^] # Re: Mêmes aventures ici

      Posté par  . Évalué à 1.

      tu ferais mieux de mettre en service un serveur LDAP sur ta machine principale et via la virtualisation de mettre en oeuvre du LDAP pour les users Linux. D'ailleurs, si c'etait bien configuré, il me semble que les utilisateurs locaux restent visibles. On peut choisir l'ordre dans /etc/nsswich.conf. Mais dans une machine virtuelle, hein :-) et une fois deverminé, tu migres sur ton poste principal.

      • [^] # Re: Mêmes aventures ici

        Posté par  . Évalué à 2.

        Bon moi je veux bien parler de machine principale, mais vu qu'il n'y en a qu'une... :-)
        C'est un petit serveur perso, pas très puissant, et je doute qu'il supporte bien la virtualisation... Et puis bon, ça fait un peu bazooka VS mouche non?

        Pour le nsswitch, je sais bien... j'avais bien suivi l'indication qui disait de mettre "files ldap" dans l'ordre pour que "normalement" il cherche dans le /etc puis dans le ldap... c'est bien pour ça que l'échec reste un mystère à mes yeux ^^ (à la limite cette partie là ça va, il y a 3 lignes à changer ... c'est plus la conf ldap-pam/nss qui est incompréhensible)

  • # Documentation

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

    LDAP est un protocole assez léger mais qui peut s'avérer assez complexe à implémenter.
    As-tu déjà lu les divers articles parus dans Linux mag ?

    - Introduction à LDAP : http://articles.mongueurs.net/magazines/linuxmag65.html ;
    - Fonctionnalités avancées d'OpenLDAP : http://articles.mongueurs.net/magazines/linuxmag66.html ;
    - Authentification Linux avec LDAP : http://articles.mongueurs.net/magazines/linuxmag67.html ;
    - Utilisation de Net::LDAP : http://articles.mongueurs.net/magazines/linuxmag68.html

    Sinon, O'Reilly avait publié un bon livre sur le sujet, qui a l'avantage de rester pratique et concis :
    http://oreilly.com/catalog/9781565924918/index.html

  • # Kolab + integration

    Posté par  . Évalué à 1.

    Hello folks,

    Je voulais rappeler qu'il existe le projet kolab qui a le merite de simplifier le process d'installation d'un server de mail qui peux gerer le multi-domain et ceci depuis la recente version 2.2. par contre je ne suis pas sur que l'on puisse deleguer l'administration des "sous-domain" simplement a l'aide de l'interface web d'administration

    Pour plus d'info http://www.kolab.org

  • # Serveur jabber et ldap

    Posté par  . Évalué à 2.

    Ce n'est certainement pas ce que tu recherche parce que tu utilises ejabberd mais le serveur jabber OpenFire

    http://www.igniterealtime.org/projects/openfire/index.jsp

    est capable de gérer l'authentification des utilisateurs via ldap.

    http://www.igniterealtime.org/builds/openfire/docs/latest/do(...)

    Ce serveur est en java à l'époque ou je l'avais utilisé l'installation
    était sous forme d'un gros blob qui embarquait sa propre JRE mais
    il y a maintenant un paquet debian sans jre téléchargeable.

    J'avais donc réussi à le connecter à ldap mais il y avait un problème
    les utilisateurs ne pouvaient s'envoyer de fichiers si on utilisait ldap
    alors que sans l'envoie de fichier marchait.
    Ca a peut-être évolué depuis c'était il y a deux ans.

    bon courage,
    et merci pour les retours d'expériences car honnêtement je me demandais la semaine dernière:
    "au fait il en est ou ploum avec son ldap ?" ;)

    • [^] # Re: Serveur jabber et ldap

      Posté par  . Évalué à 1.

      Ceci dit apparement ejabberd peut aussi se connecter a ldap:

      http://www.process-one.net/en/ejabberd/guide_en#htoc32

    • [^] # Re: Serveur jabber et ldap

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

      ben pour te répondre :

      - J'ai finalement adopté dovecot et le mandriva directory server (qui est très très bien)
      - j'utilise, comme suggéré ici, intensément phpldapadmin
      - j'ai réussi à connecté mon ejabberd à mon serveur ldap (c'est en fait méga facile).

      alors, il me reste :

      - à trouver comment permettre aux utilisateurs de modifier les infos les concernants (sauf le champ email qui est utilisé par le serveur imap), que ce soit depuis la vCard Jabber ou depuis squirrelmail (il semble que je n'ai pas les droits pour ça, je pige pas trop)
      - à faire en sorte que MDS vérifie qu'une adresse email n'est pas déjà attribuée avant de laisser un admin la rajouter comme alias à un user.
      https://ml.mandriva.net/wws/arc/mds-users/2008-07/msg00009.h(...)
      - trouver comment permettre de nommer un sous-admin pour un domaine donné uniquement
      https://ml.mandriva.net/wws/arc/mds-users/2008-07/msg00010.h(...)
      - à faire fonctionner Sieve avec Dovecot et Squirrelmail pour que les utilisateurs puissent faire leur propres filtres
      - Etudier la question de ce que ça implique d'utiliser le serveur LDAP comme adress book en ligne et si c'est une bonne idée ou pas.
      - Voir si dotclear fonctionne bien avec LDAP ou pas (voir ma question à la fin du thread ici :
      http://forum.dotclear.net/viewtopic.php?id=33727 )

      Bref, j'ai énormément avancé mais il reste beaucoup à faire :-)

      Mes livres CC By-SA : https://ploum.net/livres.html

Suivre le flux des commentaires

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