[postfix-users] ldaps fuer Alias-Konfiguration
Wir testen gerade den Umstieg von hash-Tabellen auf ab jetzt verfuegbare Adress/Alias-Daten auf einem LDAP-Server... Es klappt nicht. Wir wollen kein anonymous bind ...sondern ueber ein vergebenes Nutzerprofil zugeifen...die entsprechenden bind-Angaben stehen in der ldap.cf-Datei , die in main.cf referenziert wurde...
Meine google-Suche fuehrte mich zur Uni Erlangen...da wurde das auch dokumentiert... (chroot-Umgebungen, Zugriffsprobleme auf Zertifikate???).
Geht es nicht mit ldaps ???
Das Dokument ist nicht das neueste...deshalb eine kurze Zwischenfrage...Wo finde ich Aktuelles
???
On 10.06.2011 08:58 Margrit Lottmann wrote:
Es klappt nicht.
Um Dir bei Deinem Problem evtl. helfen zu können, wären ein paar Configs und Errorlogs nicht schlecht ...
Gruß Markus
Zitat von Margrit Lottmann margrit.lottmann@ovgu.de:
Wir testen gerade den Umstieg von hash-Tabellen auf ab jetzt verfuegbare Adress/Alias-Daten auf einem LDAP-Server... Es klappt nicht. Wir wollen kein anonymous bind ...sondern ueber ein vergebenes Nutzerprofil zugeifen...die entsprechenden bind-Angaben stehen in der ldap.cf-Datei , die in main.cf referenziert wurde...
Meine google-Suche fuehrte mich zur Uni Erlangen...da wurde das auch dokumentiert... (chroot-Umgebungen, Zugriffsprobleme auf Zertifikate???).
Geht es nicht mit ldaps ???
Das Dokument ist nicht das neueste...deshalb eine kurze Zwischenfrage...Wo finde ich Aktuelles
http://www.postfix.org/ldap_table.5.html
Insbesonders der Abschnitt "LDAP SSL AND STARTTLS PARAMETERS"
If any of the Postfix programs querying the map is config- ured in master.cf to run chrooted, all the certificates and keys involved have to be copied to the chroot jail. Of course, the private keys should only be readable by the user "postfix".
Es sollte aber auch möglich sein diese Beschränkung mit dem "proxymap" zu umgehen. Ist sowieso ratsam auf einem Eingangsrelay mit eventuell einigen hundert smtpd prozessen.
http://www.postfix.org/proxymap.8.html
Gruß
Andreas
Am 10.06.2011 08:58 schrieb Margrit Lottmann:
Wir testen gerade den Umstieg von hash-Tabellen auf ab jetzt verfuegbare Adress/Alias-Daten auf einem LDAP-Server... Es klappt nicht. Wir wollen kein anonymous bind ...sondern ueber ein vergebenes Nutzerprofil zugeifen...die entsprechenden bind-Angaben stehen in der ldap.cf-Datei , die in main.cf referenziert wurde...
Hier eine ldap-aliases.cf aus einer laufenden config eines gentoos:
ist eingebunden als ldap-aliases.cd wie folgt:
virtual_alias_maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/ldap-aliases.cf, ldap:/etc/postfix/ldap-forwards.cf
Wir benutzen allerdings TLS und nicht ldaps - hat den Vorteil dass nur ein Port offen sein muss.
Der Inhalt:
bind = yes bind_dn = uid=postfix,ou=services,dc=XXXX,dc=XX bind_pw = XXXXXXXX version = 3 debuglevel = 0 timeout = 30
size_limit = 0 expansion_limit = 0
# Use TLS start_tls = yes tls_require_cert = yes
server_host = ldap.XXXXXX.XX search_base = ou=users,dc=XXXX,dc=XX
scope = sub query_filter = (& (|(mailAlternateAddress=%s)(mailGroupAddress=%s)) (|(mailAccountStatus=active)(mailAccountStatus=fwdonly)) ) result_attribute = mail
Meine google-Suche fuehrte mich zur Uni Erlangen...da wurde das auch dokumentiert... (chroot-Umgebungen, Zugriffsprobleme auf Zertifikate???).
um zu testen ob das an den zertifikaten liegt kann man tls_require_cert = no setzen. Die postfix binaries laufen aus einem automatisch erstellten chroot - was auch schon bei der benutzung von libgnutls zu Problemen mit nicht vorhandenen /dev/random /dev/urandom device nodes führt.
Geht es nicht mit ldaps ???
schon, man muss dann nur dafür sorgen, dass man das ggf. selbsterzeugte Zertifikat im system installiert hat. Bei linux nach /ets/ssl/certs kopieren und c_rehash aufrufen.
Soweit ich das verstanden habe hat postfix genau für sowas den tlsmgr, der an die zertifikate des systems herankommt.
Grüße, Florian
participants (4)
-
Florian Streibelt -
lst_hoe02＠kwsoft.de -
Margrit Lottmann -
Markus Winkler