SASL-AUTH and/or Kerberos in ldap_table
Christian Rößner
little question:
What about SASL-AUTH (i.e. EXTERNAL) and or Kerberos support in ldap_table? I was looking for not binding with binddn/bindpw to my LDAP-server and using something like authz-regexp to map the user. But could not find the support in postfix :)
Best regards
Christian
---
Roessner-Network-Solutions
Bachelor of Science Informatik
Nahrungsberg 81, 35390 Gießen
F: +49 641 5879091, M: +49 176 93118939
USt-IdNr.: DE225643613
http://www.roessner-network-solutions.com
Brian Evans - Postfix List
> Hi gain,
>
> little question:
>
> What about SASL-AUTH (i.e. EXTERNAL) and or Kerberos support in ldap_table? I was looking for not binding with binddn/bindpw to my LDAP-server and using something like authz-regexp to map the user. But could not find the support in postfix :)
>
Postfix uses Dovecot or Cyrus libraries for SASL implementations.
It does not care how they are configured to look on their backend for
requests.
Brian
Christian Rößner
>
> It does not care how they are configured to look on their backend for requests.
But the backend is a part of the setup. Shouldn't it cover it?
My wishlist features for example would be:
/etc/postfix/some_ldap.cf:
...
ldap_sasl_auth = yes
ldap_sasl_mech = EXTERNAL
or something similar. How hard could this be to include into the ldap_table code? Not meant ironically.
Postfix uses SASL for "user to service" authentication, right? But what is with postfix as user to backend services?
I am very new to this topic, so if my question sounds silly or even shows some "not understanding the material", then I apologize for it. I try to learn and to understand. :)
Patrick Ben Koetter
> On 9/15/2010 8:19 AM, Christian Rößner wrote:
> >Hi gain,
> >
> >little question:
> >
> >What about SASL-AUTH (i.e. EXTERNAL) and or Kerberos support in ldap_table? I was looking for not binding with binddn/bindpw to my LDAP-server and using something like authz-regexp to map the user. But could not find the support in postfix :)
> >
>
>
> It does not care how they are configured to look on their backend
> for requests.
Mistaken! Christian wants SASL binds when he sends Postfix to query a remote
LDAP server for e.g. valid recipients. He's not after SMTP AUTH.
p@rick
--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Dieter Kluenter
> Hi gain,
>
> little question:
>
> What about SASL-AUTH (i.e. EXTERNAL) and or Kerberos support in
> ldap_table? I was looking for not binding with binddn/bindpw to my
> LDAP-server and using something like authz-regexp to map the user. But
> could not find the support in postfix :)
You may use the sasl auxprop ldapdb and GSSAPI mechanism
-Dieter
--
Dieter Klünter | Systemberatung
sip: 777...@sipgate.de
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
Christian Rößner
>> ldap_table? I was looking for not binding with binddn/bindpw to my
>> LDAP-server and using something like authz-regexp to map the user. But
>> could not find the support in postfix :)
>
> You may use the sasl auxprop ldapdb and GSSAPI mechanism
>
Are you sure that is working at the backend side?
I have used a very simple ldap.cf file from my current postfix configuration and commented out the binddn/bindpw stuff:
I have done a test with a regular user taking postfix' x509 certs:
The result from LDAP:
Sep 15 13:50:09 db slapd[1355]: do_bind: dn () SASL mech EXTERNAL
Sep 15 13:50:09 db slapd[1355]: do_bind: SASL/EXTERNAL bind: dn="cn=mx0.roessner-net.de" sasl_ssf=0
This is, what I wished to have.
But how can I set up postfix _backend_ ldap to use sasl?
Binding with DN looks like this:
Sep 15 13:38:08 db slapd[1355]: do_bind: version=3 dn="cn=proxyuser,dc=roessner-net,dc=de" method=128
Sep 15 13:38:08 db slapd[1355]: do_bind: v3 bind: "cn=proxyuser,dc=roessner-net,dc=de" to "cn=proxyuser,dc=roessner-net,dc=de"
But I would like the EXTERNAL mech from SASL ;) And maybe at a final result Kerberos.
Maybe I want too much? :)
Quanah Gibson-Mount
<c...@roessner-network-solutions.com> wrote:
> Hi gain,
>
> little question:
>
> What about SASL-AUTH (i.e. EXTERNAL) and or Kerberos support in
> ldap_table? I was looking for not binding with binddn/bindpw to my
> LDAP-server and using something like authz-regexp to map the user. But
> could not find the support in postfix :)
I wrote a patch to support SASL mechanisms when connecting to LDAP many
years ago, and maintained for for a time. However, I left the job where I
required it back in 2007, and didn't do much with it since that point in
time. I have submitted that work to Victor Duchovni of the Postfix
project, and it is my understanding he is looking at having it included in
a future release. Stanford University may still have the original work I
did on Postfix for this, since it was a requirement for their Postfix
deployment. You may wish to ping them.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Dieter Kluenter
>>> What about SASL-AUTH (i.e. EXTERNAL) and or Kerberos support in
>>> ldap_table? I was looking for not binding with binddn/bindpw to my
>>> LDAP-server and using something like authz-regexp to map the user. But
>>> could not find the support in postfix :)
>>
>> You may use the sasl auxprop ldapdb and GSSAPI mechanism
>>
>
> Are you sure that is working at the backend side?
>
> I have used a very simple ldap.cf file from my current postfix configuration and commented out the binddn/bindpw stuff:
>
> I have done a test with a regular user taking postfix' x509 certs:
>
> The result from LDAP:
>
> Sep 15 13:50:09 db slapd[1355]: do_bind: dn () SASL mech EXTERNAL
> Sep 15 13:50:09 db slapd[1355]: do_bind: SASL/EXTERNAL bind: dn="cn=mx0.roessner-net.de" sasl_ssf=0
>
> This is, what I wished to have.
>
> But how can I set up postfix _backend_ ldap to use sasl?
>
> Binding with DN looks like this:
>
> Sep 15 13:38:08 db slapd[1355]: do_bind: version=3 dn="cn=proxyuser,dc=roessner-net,dc=de" method=128
> Sep 15 13:38:08 db slapd[1355]: do_bind: v3 bind: "cn=proxyuser,dc=roessner-net,dc=de" to "cn=proxyuser,dc=roessner-net,dc=de"
>
> But I would like the EXTERNAL mech from SASL ;) And maybe at a final result Kerberos.
>
> Maybe I want too much? :)
I use ldapdb for cyrus-imapd and postfix authentication but haven't
tested with EXTERNAL mechanisms for users.
Just an excerpt from /etc/sasl2/smtpd.conf
pwcheck_method: auxprop
auxprop_plugin: ldapdb
mech_list: LOGIN DIGEST-MD5
ldapdb_uri: ldap://localhost
ldapdb_mech: EXTERNAL
ldapdb_rc: /etc/sasl2/ldaprc
ldapdb_starttls: demand
and from /etc/sasl2/ldaprc
TLS_CACERT /etc/openldap/certs/avciCA.pem
TLS_CERT /etc/openldap/certs/mailadmin.pem
TLS_KEY /etc/openldap/certs/mailadmin-key.pem
TLS_CIPHER_SUITE HIGH
The EXTERNAL mechanism is to authenticate the proxy user mailadmin.
OpenLDAP needs proper authz-policy and authz-regexp configured though.
Victor Duchovni
> I wrote a patch to support SASL mechanisms when connecting to LDAP many
> years ago, and maintained for for a time. However, I left the job where I
> required it back in 2007, and didn't do much with it since that point in
> time. I have submitted that work to Victor Duchovni of the Postfix
> project, and it is my understanding he is looking at having it included in
> a future release. Stanford University may still have the original work I
> did on Postfix for this, since it was a requirement for their Postfix
> deployment. You may wish to ping them.
I have the patch, it has not yet been fully reviewed/integrated. If
anyone wants to test it "as is", it is attached.
--
Viktor.
Christian Rößner
> anyone wants to test it "as is", it is attached.
Thanks. I took the patch and applied it. Is compiled without warnings. Just little bugs in the man page, which I am going to fix tomorrow.
server_host = ldap://db.roessner-net.de/
ldap://ldapslave.roessner-net.de/
start_tls = yes
tls_ca_cert_file = /ca/cacert_org.crt
tls_cert = /ca/mx0.roessner-net.de/newcert.pem
tls_key = /ca/mx0.roessner-net.de/newkey.pem
tls_require_cert = yes
search_base = ou=users,ou=people,dc=roessner-net,dc=de
bind = yes
sasl = yes
sasl_mechs = EXTERNAL
scope = sub
query_filter = (&(objectClass=rnsMSPostfixAccount)(rnsMSRecipientAddress=%s)(rnsMSEnablePostfix=TRUE))
result_attribute = rnsMSDeliverToAddress
version = 3
# debuglevel = 2
postmap -q "de1...@service.intern" ldap:/etc/postfix/ldap/test.cf
At ldap.log:
Sep 15 18:29:06 db slapd[1355]: conn=3021 op=1 do_bind
Sep 15 18:29:06 db slapd[1355]: do_bind: dn () SASL mech EXTERNAL
Sep 15 18:29:06 db slapd[1355]: do_bind: SASL/EXTERNAL bind: dn="cn=mx0.roessner-net.de" sasl_ssf=0
So it seems, it might work. I will paste the results when I have set up LDAP with appropriate settings (authz*)
Christian
Christian Rößner
The ldap_table SASL patch works for me on postfix-2.8-20100913
Sep 15 18:57:58 db slapd[1355]: do_bind: dn () SASL mech EXTERNAL
Sep 15 18:57:58 db slapd[1355]: ==>slap_sasl2dn: converting SASL name cn=mx0.roessner-net.de to a DN
Sep 15 18:57:58 db slapd[1355]: slap_parseURI: parsing cn=proxyuser,dc=roessner-net,dc=de
Sep 15 18:57:58 db slapd[1355]: >>> dnNormalize: <cn=proxyuser,dc=roessner-net,dc=de>
Sep 15 18:57:58 db slapd[1355]: <<< dnNormalize: <cn=proxyuser,dc=roessner-net,dc=de>
Sep 15 18:57:58 db slapd[1355]: <==slap_sasl2dn: Converted SASL name to cn=proxyuser,dc=roessner-net,dc=de
Sep 15 18:57:58 db slapd[1355]: slap_sasl_getdn: dn:id converted to cn=proxyuser,dc=roessner-net,dc=de
Sep 15 18:57:58 db slapd[1355]: conn=3057 op=1 BIND authcid="cn=mx0.roessner-net.de" authzid="cn=mx0.roessner-net.de"
Sep 15 18:57:58 db slapd[1355]: SASL Authorize [conn=3057]: proxy authorization allowed authzDN=""
Sep 15 18:57:58 db slapd[1355]: send_ldap_sasl: err=0 len=-1
Sep 15 18:57:58 db slapd[1355]: conn=3057 op=1 BIND dn="cn=proxyuser,dc=roessner-net,dc=de" mech=EXTERNAL sasl_ssf=0 ssf=128
Sep 15 18:57:58 db slapd[1355]: do_bind: SASL/EXTERNAL bind: dn="cn=proxyuser,dc=roessner-net,dc=de" sasl_ssf=0
I have to check, if I did a mistake with the patch itself, causing the man page errors, or if the patch needs little tweaks :) But at least the functionality is working. I am so happy! :)
Christian
Quanah Gibson-Mount
<c...@roessner-network-solutions.com> wrote:
> I have to check, if I did a mistake with the patch itself, causing the
> man page errors, or if the patch needs little tweaks :) But at least the
> functionality is working. I am so happy! :)
Glad to hear it! I only ever used it with SASL/GSSAPI but it was written
in such a way to be completely generic as far as SASL mechs goes, so it is
nice to see confirmation it works for someone else with a different mech.
Christian Rößner
The patch has very little bugs. The following snippet from the patch _could_ look like this:
--- proto/ldap_table.orig 2008-07-23 11:20:19.000000000 -0700
+++ proto/ldap_table 2008-07-23 11:23:13.000000000 -0700
@@ -470,6 +470,29 @@
# Specifies the LDAP protocol version to use.
# .IP "\fBdebuglevel (default: 0)\fR"
# What level to set for debugging in the OpenLDAP libraries.
+# LDAP SASL PARAMETERS
+# .ad
+# .fi
+# If you're using the OpenLDAP libraries compiled with SASL
+# support, Postfix can connect to LDAP servers using SASL
+# mechanisms.
+#
+# Using SASL mechanisms requires LDAP protocol version 3, which
+# is the default.
+#
+# The following parameters are relevant to using LDAP with
+# SASL
+# .IP "\fBsasl (default: no)\fR"
+# Whether or not to use SASL binds to the server. Can be yes or no.
+# .IP "\fBsasl_mechs (No default)\fR"
+# Space separated list of SASL mechanism(s) to try.
+# .IP "\fBsasl_realm (No default)\fR"
+# SASL Realm to use, if applicable.
+# .IP "\fBsasl_authz_id (No default)\fR"
+# The SASL authorization identity to assert, if applicable.
+# .IP "\fBsasl_minssf (default: 0)\fR"
+# The minimum required sasl security factor required to
+# establish a connection.
# LDAP SSL AND STARTTLS PARAMETERS
# .ad
# .fi
In fron of the keywords sasl_realm, sasl_authz, sasl_minssf there was the "B" missing. That is all.
Would be great, if others would test it, too, and maybe if the patch would be included into the next release.
Have a nice evening
Christian
Patrick Ben Koetter
> It works!
Probably OT for this list and better suited for the developers list, but does
it still work without any errors? Having EXTERNAL available in LDAP queries
would be quite nice - you get TLS, authentication and authorization at once.
Could this become part of Postfix if it works? I'd volunteer to add some
documentation to SASL_README if that is the right place besides ldap_table(5).
p@rick
>
> The ldap_table SASL patch works for me on postfix-2.8-20100913
>
> Sep 15 18:57:58 db slapd[1355]: do_bind: dn () SASL mech EXTERNAL
> Sep 15 18:57:58 db slapd[1355]: ==>slap_sasl2dn: converting SASL name cn=mx0.roessner-net.de to a DN
> Sep 15 18:57:58 db slapd[1355]: slap_parseURI: parsing cn=proxyuser,dc=roessner-net,dc=de
> Sep 15 18:57:58 db slapd[1355]: >>> dnNormalize: <cn=proxyuser,dc=roessner-net,dc=de>
> Sep 15 18:57:58 db slapd[1355]: <<< dnNormalize: <cn=proxyuser,dc=roessner-net,dc=de>
> Sep 15 18:57:58 db slapd[1355]: <==slap_sasl2dn: Converted SASL name to cn=proxyuser,dc=roessner-net,dc=de
> Sep 15 18:57:58 db slapd[1355]: slap_sasl_getdn: dn:id converted to cn=proxyuser,dc=roessner-net,dc=de
> Sep 15 18:57:58 db slapd[1355]: conn=3057 op=1 BIND authcid="cn=mx0.roessner-net.de" authzid="cn=mx0.roessner-net.de"
> Sep 15 18:57:58 db slapd[1355]: SASL Authorize [conn=3057]: proxy authorization allowed authzDN=""
> Sep 15 18:57:58 db slapd[1355]: send_ldap_sasl: err=0 len=-1
> Sep 15 18:57:58 db slapd[1355]: conn=3057 op=1 BIND dn="cn=proxyuser,dc=roessner-net,dc=de" mech=EXTERNAL sasl_ssf=0 ssf=128
> Sep 15 18:57:58 db slapd[1355]: do_bind: SASL/EXTERNAL bind: dn="cn=proxyuser,dc=roessner-net,dc=de" sasl_ssf=0
>
> I have to check, if I did a mistake with the patch itself, causing the man page errors, or if the patch needs little tweaks :) But at least the functionality is working. I am so happy! :)
>
> Christian
Victor Duchovni
> * Christian R??ner <c...@roessner-network-solutions.com>:
> > It works!
>
> Probably OT for this list and better suited for the developers list, but does
> it still work without any errors? Having EXTERNAL available in LDAP queries
> would be quite nice - you get TLS, authentication and authorization at once.
>
> Could this become part of Postfix if it works? I'd volunteer to add some
> documentation to SASL_README if that is the right place besides ldap_table(5).
This is not "EXTERNAL" support for the Postfix SASL server. Rather,
this is "EXTERNAL" support for the Postfix LDAP client, with the LDAP
server mapping the TLS client to some suitable authentication identity.
At this time, there is no code in the Postfix SMTP server to process
the client Subject DN or subjectAltName list to derive an external
identifier for SMTP SASL.
--
Viktor.
Patrick Ben Koetter
Yes, I know. I would be interested in LDAP queries to e.g. an OpenLDAP server
where Postfix as querying instance uses SASL EXTERNAL to authenticate.
I would be interested to have code in the Postfix SMTP server to process the
client Subject DN or subjectAltName, but that is not what I am after right
now.
p@rick
Victor Duchovni
> > This is not "EXTERNAL" support for the Postfix SASL server. Rather,
> > this is "EXTERNAL" support for the Postfix LDAP client, with the LDAP
> > server mapping the TLS client to some suitable authentication identity.
> >
> > At this time, there is no code in the Postfix SMTP server to process
> > the client Subject DN or subjectAltName list to derive an external
> > identifier for SMTP SASL.
>
> Yes, I know. I would be interested in LDAP queries to e.g. an OpenLDAP server
> where Postfix as querying instance uses SASL EXTERNAL to authenticate.
Authenticate what? Postfix cannot forge the connecting SMTP client's
private key to convince the LDAP server that it is the client via
"EXTERNAL" auth.
If you are talking about authenticating the Postfix LDAP client, so that
one does not to specify a "bind_pw", then I'll try to get this done in
the next month or two...
--
Viktor.
Christian Rößner
> private key to convince the LDAP server that it is the client via
> "EXTERNAL" auth.
>
> If you are talking about authenticating the Postfix LDAP client, so that
> one does not to specify a "bind_pw", then I'll try to get this done in
> the next month or two...
EXTERNAL for sure only prevents setting the bind_pw, what I am using right now :-)
The patch you recently sent here also includes SASL/GSSAPI. I haven't yet tested it with MIT-Kerberos. But it is on my TODO.
Best wishes