Ubuntu-fr

Zarbatrip

Annuaire LDAP

Bonjour,

est-il possible d'avoir 1 seul annuaire LDAP auquel se connecte :
1 serveur Postfix
1 serveur IMAP
1 serveur SQUID
1 serveur DaviCAL
1 Serveur Apache pour avoir une interface utilisateur de recherche de coordonnées téléphonique (type annuaire)
Plusieurs serveur Samba PDC gérant des domaines différents (societe A, societe B,...) qui n'ont PAS besoin de communiquer entre elles.

Pour la première partie, je sais que c'est possible mais pour l'annuaire et pour les PDC, je ne sais pas si c'est possible.

Merci

chrisCBO

Re : Annuaire LDAP

est-il possible d'avoir 1 seul annuaire LDAP auquel se connectent :
1 serveur Postfix
1 serveur IMAP
1 serveur SQUID
1 serveur DaviCAL
1 Serveur Apache
pour avoir une interface utilisateur de recherche de coordonnées téléphonique (type annuaire)
Plusieurs serveur Samba PDC gérant des domaines différents (societe A, societe B,...) qui n'ont PAS besoin de communiquer entre elles.

La réponse courte est: OUI

La réponse longue est... longue. en fait cela dépend de ce que tu comprends de LDAP.
Pour être un peu plus précis (ne le prends pas mal):
- si tu comprends LDAP, tu ne pose pas ce type de question.
- si tu ne comprends pas (ce qui n'est pas un défaut en soit: tous ceux qui comprennent LDAP aujourd'hui ont commencé par la phase ou ils ne comprennaient pas... ) alors je pense qu'il vaut mieux commencer par un design simple.

Pour justement essayer de faire simple (il y a comme toujours plusieurs solutions):
- créer des branches multiples, par exemple une par société. Dans cette approche, je te conseille fortement d'avoir un DIT basé sur des "domain components" plutôt que sur "organization"
- l'avantage est que tu as une seule branche. il suffit ensuite de pointer sur la bonne entrée dans le baseDN des chaque logiciel ou même avoir un baseDN dépendant de l'utilisateur.
- ça peut facilement servir de repository commun pour le DNS, NIS (NSS_LDAP) etc...

Je connais bien (je pense pouvoir dire très bien ) le directory de Sun (ex iPlanet/Netscape) mais pas OpenLDAP. J'imagine cependant que les possibilités en terme d'ACI (ACL?) sont équivalentes. Ce à quoi il faut faire attention, c'est de bien isoler les droits utilisateurs en fonction de tes règles d'organisation du DIT.

Une autre approche pourrait être de créer des entrées (racine) différentes, une pour chaque société. Ce n'est pas plus difficile mais ça peut rendre certains controles plus difficiles. Par exemple, si tu veux assurer l'unicité du login utilisateur, selon ce que tu vises il y a plusieurs choix:
- si ton login doit être unique transversalement (parmis TOUS les logins pour TOUTES les sociétés) alors l'approche "branche unique" est plus simple.
- si ton login peut être identique (car tu as un mecanisme qui te permet d'identifier d'où vient l'utilisateur et donc de cherche dans la bonne branche) alors tu peux gérer des entrées différentes.
Attention de ne pas confondre ces problématiques de login (et d'unicité de login) avec les problématiques d'unicité (by design) du DN et donc du RDN dans une branche donnée.

Je vais me mettre à OpenLDAP pour monter un petit serveur dans l'architecture familiale. Je pourrai t'en dire plus dans quelques temps.

En espérant que ma réponse t'a apporté plus d'éclairage que de zone d'ombre...
Courage, LDAP est une voie très intéressante.

Christian

Zarbatrip

Re : Annuaire LDAP

Bonjour,

comme tu l'as bien déduit, je ne comprend pas le fonctionnement des annuaires.
J' ai déjà installé de nombreux domaines AD (en production).
J'ai également installé un OpenLDAP (en test) sans comprendre les principes de base, ce que je n'aime pas du tout.
Je me suis beaucoup documenté mais ça reste pour le moment très obscur pour moi.
Il me paraît très dangereux d'installer des services en production en suivant des tutos mais sans en maitriser  les concepts. Le jour ou ça débloque, tu es marron.

Je cherchait à savoir s'il était intéressant pour moi de continuer mes investigations car je pense que l'investissement pour maitriser ce concept (et ses applications) va être longue.

Merci donc pour tes réponses. Je pense que quand je comprendrai de quoi tu parles, j'aurai déjà bien avancé

chrisCBO

Re : Annuaire LDAP

oui...enfin, un des buts d'un tel forum, c'est aussi de t'aider à  comprendre.

Mon propos n'était surtout pas de te dire "si tu sais, ne pose pas la question et sinon, tant pis pour toi" mais plutà´t de te faire remarquer que la réponse n'est pas aisée car elle dépend fortement de ton niveau de compréhension initial.

Je ne peux que t'encourager fortement à  continuer dans la compréhension de LDAP car d'une part c'est de plus en plus répendu en entreprise et d'autre par c'est la base d'une solution souvent efficace à  beaucoup de problème d'identity managment.

En plus, lorsque tu comprends LDAP, ta vision d'AD change sensiblement

Je ne pense pas que la compréhension des concepts de base de LDAP soit difficile. Après tout, il y a peu de commandes et les concepts de classe d'objet et d'attributs sont assez simples.

Ce qui, à  mon sens, réellement difficile à  maitriser, c'est le design: aux quelques problèmes de syntaxe près, tout ce que tu vas faire va fonctionner. Cest bien mais c'est là  que se situe le risque majeur car comme ça marche assez facilement dès le début, il est très difficile de comprendre si ton design est bien ou pas. Est-ce que l'organisation de ton DIT correspond à  l'usage que tu fais des entrées, quels sont les impacts en terme de performance, facilité d'administration fonctionnalités telles que la réplication...

Pour revenir à  des choses pragmatiques.
A suposer que tu veuilles faire un annuaire unique, il y a quelques questions qu'il faut se poser:

1 - La recherche dans l'annuaire
========================
Il faut que tu sache dire si tous les utilisateurs peuvent lire toutes les entrées ou bien si tu veux que les utilisateurs de la société A soient limités aux entrées de la société A.
Une manière simple de se poser cette quesiton est de savoir si la consultaiton de l'annuaire se fait de manière anonyme ou pas.
si les utilisateurs sont authentifiés, des ACI suffiront à  répondre à  la première question car une fois que tu connais l'utilisateur, tu sais déterminer quelle règle s'applique.
Si l'accès doit se faire de manière anonyme (comme c'est souvent le cas lors de la consultaiton de répertoire téléphonique), alors sa ce complique un peu car il faut comprendre si tous les utilisateurs se partage la même interface/application ou pas.
Dans le cas d'une seule application partagée par plusieurs utilisateurs de société différentes en mode anonyme, il n'y a bien sûr pas de solution. Dans le cas ou les interfaces sont différentes (je ne parle pas en terme de layout mais en terme de paramétrage), alors il suffit de pointer vers des baseDN différents, se qui, si tu as construit ton DIT en prenant en compte cette contrainte, va te fournir la seggrégation dont tu as besoin.

2 - configuration des différents "Samba"
==============================
ça tombe bien, la réponse est très proche du point précédent :-)
si tu configures le baseDN de Samba (de mémoire, ça ne s'appelle pas comme ça dans Samba mais plutà´t un truc du genre "ldap suffix") pour correspondre aux entrées de chacune des sociétés, ça te permet de restreindre les accès uniquement aux entrées de ladite société depuis cette occurence de Samba.

Pour reprendre ma réponse précédente, tu as 2 grands choix:

Choix 1
plusieures entrées racine dans LDAP
dc=société1,dc=fr
dc=société2,dc=fr
....
ça marche très bien avec un sunOne directory, je ne sais pas si c'est faisable avec OpenLDAP
pros: isolation de-facto des entrées puisque le baseDN principal est différent.
cons: pas de possibilité simple d'utiliser des pluggin d'unicité qui permettraient par exemple de s'assurer que l'uid "toto" n'est présent qu'une fois dans tout LES directory (ça peut être utile voire indispensable si tu consulte un log et que tu veux retrouver à  quelle entrée dans LDAP ce login appartient...

choix 2
une entré racine
dc=masociété,dc=fr
une sous-entrée par société
o=société1,dc=masociété,dc=fr
o=société2,dc=masociété,dc=fr
...

pros: uniticité plus facile à  gérer, un seul DIT
cons: gestion plus complexe des ACI, nécessité de définir plusieurs baseDN dans les applicaitons avec le risque de permettre la visibilité sur des entrées qui ne sont pas forcément autorisées (pour autant que ce soit un problème).

il y a bien d'autres implémentations possibles. ça dépend vraiment de tes besoins. Mais comme l'expression de tes besoins en aspects qui ont un sens dans LDAP nécessite de comprendre comme LDAP fonctionne, tu tournes vite en rond.

j'espère t'en avoir dit assez pour que tu vois dans quelle direction orienter tes recherches.

si vraiment tu es perdu, envoie moi un message à  christian-at-bonato-point-fr

Christian