Postfix LDAP HowtoPostfix LDAP HowtoPostfix peut utiliser un annuaire LDAP comme source pour toutes ses correspondances : aliases(5), virtual(5), canonical(5), etc. Ceci vous permet de stocker les informations de votre système de messagerie dans une base de données protégée par un contrôle d'accès fin. En ne les stockant pas localement sur le serveur de messagerie, les administrateurs peuvent les maintenir depuis n'importe où et les utilisateurs peuvent accéder et modifier les informations que vous souhaitez. Vous pouvez également avoir de multiples serveurs utilisant la même information sans les conflits et délais de recopie sur chacun d'eux.
Sujets abordés dans ce document :
Note 1 : Postfix ne supporte plus la version 1 du protocole LDAP.
Note 2 : pour utiliser LDAP avec le Postix de Debian GNU/Linux's, tout ce dont vous avez besoin est d'installer le package postfix-ldap. Il n'y a pas lieu de recompiler Postfix.
Vous devez disposer des librairies et fichiers "include" sur votre système et configurer le Makefile de Postfix en fonction.
Par exemple pour compiler les librairies d'OpenLDAP pour les utiliser avec Postfix (c'est à dire les codes client LDAP seulement), vous pouvez utiliser la commande suivante :
% ./configure --without-kerberos --without-cyrus-sasl --without-tls \
--without-threads --disable-slapd --disable-slurpd \
--disable-debug --disable-shared
Si vous utilisez les librairies de la distribution UM (http://www.umich.edu/~dirsvcs/ldap/ldap.html) ou OpenLDAP (http://www.openldap.org), les commandes suivantes à la racine des sources de Postfix devraient suffire :
% make tidy
% make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
AUXLIBS="-L/usr/local/lib -lldap -L/usr/local/lib -llber"
Sur Solaris 2.x vous devrez spécifier le chemin des librairies sinon, ld.so ne trouvera pas les librairies partagées :
% make tidy
% make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP" \
AUXLIBS="-L/usr/local/lib -R/usr/local/lib -lldap \
-L/usr/local/lib -R/usr/local/lib -llber"
La commande 'make tidy' n'est nécessaire que si vous avez précédemment compilé Postfix sans le support LDAP.
Au lieu de '/usr/local' indiquez la position de vos librairies LDAP et fichier include. Assurez-vous de ne pas mélanger des libriaires et fichiers include de différentes versions!!
Si vos librairies LDAP sont compilées avec le support Kerberos, vous devrez également inclure vos librairies Kerberos sur cette ligne. Notez que les librairies KTH Kerberos IV peuvent entrer en conflit avec la librairie lib/libdns.a de Postfix qui définit dns_lookup. Si celà arrive, vous devrez probablement utiliser des librairies LDAP sans support de Kerberos pour compiler Postfix et il ne supportera pas les connexions Kerberos au serveur LDAP. Désolé...
Si vous utilisez un des SDK LDAP Netscape, vous devrez changer la line AUXLIBS pour pointer sur libldap10.so ou libldapssl30.so ou ce dont vous disposez, et vous devrez utiliser l'option de liage appropriée (-R) pour que l'exécutable la trouve au lancement.
Pour utiliser les correspondances LDAP, définissez une source LDAP comme table de correspondance dans le fichier main.cf, par exemple :
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
Le fichier /etc/postfix/ldap-aliases.cf peut contenir un grand nombre de paramètres, y compris les paramètres qui activent LDAP SSL et STARTTLS. Pour une description complète de ces possibilités, consultez la page de manuel ldap_table(5).
Ci-dessous un exemple d'utilisation de LDAP pour les consultations d'alias locaux (local(8)). Supposons que dans le fichier main.cf, vous avez :
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
et dans ldap:/etc/postfix/ldap-aliases.cf :
server_host = ldap.my.com search_base = dc=my, dc=com
A la reception d'un message à destination de l'adresse locale "ldapuser" qui n'est pas trouvée dans la base de données /etc/aliases, Postfix recherchera le serveur LDAP écoutant sur le port 389 de ldap.my.com. Il se connectera anonymement, cherchera toute entrée dont l'attribut mailacceptinggeneralid est "ldapuser", lira l'attribut "maildrop" des entrées trouvées et construira une liste de leur maildrops qui seront traitées comme des adresses RFC822 à qui le message sera livré.
Si vous voulez stocker vos informations pour les consultations virtuelles dans votre annuaire, c'est seulement un petit peu plus compliqué. D'abord vous devez vous assurer de la configuration du domaine virtuel dans Postfix. Ensuite, vous devrez vous assurer que tous les attributs mailacceptinggeneralid de vos destinataires virtuels ont une forme correcte et dans le domaine virtuel. Finalement, si vous devez désigner une entrée de cet annuaire comme adresse par défaut pour le domaine virtuel, ajoutez simplement un champ mailacceptinggeneralid (ou équivalent dans votre annuaire) contenant "@domaine.virtuel" Si vous ne désirez pas d'adresse de collecte, omettez simplement cette étape et le courrier des utilisateurs inconnus sera retourné.
En résumé, l'enregistrement de l'utilisateur de collecte devrait ressembler à :
dn: cn=defaultrecipient, dc=fake, dc=dom
objectclass: top
objectclass: virtualaccount
cn: defaultrecipient
owner: uid=root, dc=someserver, dc=isp, dc=dom
1 -> mailacceptinggeneralid: fake.dom
2 -> mailacceptinggeneralid: @fake.dom
3 -> maildrop: realuser@real.dom
1: Postfix sait que fake.dom est un domaine virtuel valide lorsqu'il le cherche et obtient quelque chose (maildrop) en réponse.
2: Ceci implémente l'adresse de collecte : le courrier perdu est redirigé sur cette entrée ...
3: ... et va ensuite dans sa boîte-aux-lettres.
Les utilisateurs normaux auront simplement un mailacceptinggeneralid et un maildrop, à savoir "utilisateur.normal@fake.dom" et "utilisateur.normal@real.dom".
Les éléments de schéma et les noms d'attributs utilisés dans cette page sont juste des exemples. Seule remarque, certains sont des valeurs par défaut des configurations LDAP. Vous pouvez utiliser n'importe quel schéma et configurer Postfix en conséquence.
Vous devrez probablement vous assurer que les mailacceptinggeneralids sont uniques et que les utilisateurs ne peuvent les modifier.
Une entrée peut avoir plusieurs mailacceptinggeneralids ou maildrops. Les maildrops peuvent également contenir plusieurs adresses séparées par des virgules. Elles seront toutes retournées par la consultation. Par exemple, vous pouvez définir une entrée pour implémenter une liste de diffusion ressemblant à ceci (Attention! Ce schéma n'est construit que pour l'exemple) :
dn: cn=Accounting Staff List, dc=my, dc=com cn: Accounting Staff List o: my.com objectclass: maillist mailacceptinggeneralid: accountingstaff mailacceptinggeneralid: accounting-staff maildrop: mylist-owner maildrop: an-accountant maildrop: some-other-accountant maildrop: this, that, theother
Si vous utilisez les consultations LDAP pour autre chose que les alias, vous devrez vous assurer que ces consultations ont un sens. Dans le cas de correspondances virtuelles les enregistrement maildrop ne contenant pas d'adresse mail sont déconseillées car Postfix ne peut savoir sous quel utilisateur lancer le programme ou ouvrir le fichier de livraison. Votre requête query_filter devrait ressemebler à :
query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")(maildrop="*:*")(maildrop="*/*"))))
Dans ce cas camme pour les alias, vous ne souhaiterez probablement pas que les utilisateurs modifient leur enregistrement maildrop. Ceci peut être particulièrement pertinent sur un serveur "scellé" où ils n'ont pas de compte UNIX mais n'existent que dans LDAP et Cyrus. Vous souhaiterez également que si le champ maildrop contient un programme et que l'objet n'apartient pas à "cn=root", rien ne soit retourné. Ceci requiert de l'attention de votre part pour implémenter ceci en toute sécurité, considérant les ramifications de ce type de livraison. Si vous décidez qu'il n'est intéressant d'autoriser tous ces non-sens dans les consultations LDAP, supprimez-les du filtre query_filter et utilisez d'autres artifices tels les listes Majordomo ou les bases de données locales d'alias.
query_filter = (&(mailacceptinggeneralid=%s)(!(|(maildrop="*|*")(maildrop="*:*")(maildrop="*/*"))(owner=cn=root, dc=your, dc=com)))
Les requêtes LDAP sont plus lentes que les requêtes aux bases locales DB ou DBM. Pour la plupart des sites, ce ne sera pas un goulot d'entranglement, mais il est bon de savoir comment optimiser votre annuaire LDAP.
Les correspondances LDAP multiples partagent la même connexion LDAP si elles ne diffèrent que dans les paramètres de leur requête : base, scope, query_filter, etc. Pour profiter de cet avantage, évitez les fausses différences dans vos définitions LDAP : ordre de selection des machines, version, connexion, paramètres tls, ... doivent être les mêmes pour le plus de correspondances possible.
Si vous avez des questions, envoyez-les à postfix-users@postfix.org. N'oubliez pas les informations sur votre configuration : paramètres LDAP issus de postconf, quelles librairies LDAP vous avez utilisé et quel serveur d'annuaire vous utilisez. Si votre question porte sur le contenu des entrées de votre annuaire, incluez s'il vous plait quelques entrées;
traduction par Xavier Guimard - Retour au menu