Hello list,
I am trying to authenticate my mail users against my ldap directory (slapd 2.4.17, debian squeeze). I have setup proxy authorization for user postfix as follow:
in slapd.conf ---- # SASL proxy authorization rewrite rule authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=linuxwall,dc=info??sub?(uid=$1)"
authz-policy to ----
ldif of user postfix ---- dn: cn=Postfix Administrator,ou=infrastructure,dc=linuxwall,dc=info authzto: ldap:///dc=linuxwall,dc=info??sub?(objectClass=inetOrgPerson) cn: Postfix Administrator [...] ----
I have a similar user with cyrus for cyrus-imapd.
My user postfix seem to have the authorization to act on behalf of other user.
---- # ldapwhoami -Y DIGEST-MD5 -U postfix -H ldap://localhost -R linuxwall.info -X u:julien
SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: u:julien SASL SSF: 128 SASL data security layer installed. dn:cn=julien vehent,ou=people,dc=linuxwall,dc=info ----
Thus, I set up the ldapdb driver from the sasl library in the chroot of postfix. I see connections from postfix to slapd, postfix user is properly authenticated, but then I have the following message (see trace below):
---- May 23 12:57:04 samchiel slapd[1431]: conn=109 fd=17 ACCEPT from IP=127.0.0.1:58349 (IP=127.0.0.1:389) May 23 12:57:04 samchiel slapd[1431]: conn=109 op=0 BIND dn="" method=163 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND dn="" method=163 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND authcid="postfix" authzid="postfix" May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND dn="cn=postfix administrator,ou=infrastructure,dc=linuxwall,dc=info" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 RESULT tag=97 err=0 text= May 23 12:57:04 samchiel slapd[1431]: conn=109 op=2 RESULT tag=120 err=123 text=not authorized to assume identity May 23 12:57:04 samchiel slapd[1431]: conn=109 op=2 do_extended: get_ctrls failed May 23 12:57:04 samchiel slapd[1431]: conn=109 op=3 UNBIND May 23 12:57:04 samchiel slapd[1431]: conn=109 fd=17 closed May 23 12:57:04 samchiel slapd[1431]: connection_read(17): no connection! ----
I don't understand this error 'not authorized to assume identity'... Since proxy authorization works fine when I test it with ldapwhoami. Also, on the same machine, I have a cyrus-imapd server that authenticates on the same slapd using the same ldapdriver. Thus, I don't think either slapd or cyrus-sasl are the problem, but since I don't understand the error.....
Can you guys give me a hand here ?
Thanks,
Julien
Hello list,
I am trying to authenticate my mail users against my ldap directory (slapd 2.4.17, debian squeeze). I have setup proxy authorization for user postfix as follow:
in slapd.conf
# SASL proxy authorization rewrite rule authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=linuxwall,dc=info??sub?(uid=$1)"
authz-policy to
ldif of user postfix
dn: cn=Postfix Administrator,ou=infrastructure,dc=linuxwall,dc=info authzto: ldap:///dc=linuxwall,dc=info??sub?(objectClass=inetOrgPerson) cn: Postfix Administrator [...]
I have a similar user with cyrus for cyrus-imapd.
My user postfix seem to have the authorization to act on behalf of other user.
# ldapwhoami -Y DIGEST-MD5 -U postfix -H ldap://localhost -R linuxwall.info -X u:julien
SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: u:julien SASL SSF: 128 SASL data security layer installed. dn:cn=julien vehent,ou=people,dc=linuxwall,dc=info
Thus, I set up the ldapdb driver from the sasl library in the chroot of postfix. I see connections from postfix to slapd, postfix user is properly authenticated, but then I have the following message (see trace below):
May 23 12:57:04 samchiel slapd[1431]: conn=109 fd=17 ACCEPT from IP=127.0.0.1:58349 (IP=127.0.0.1:389) May 23 12:57:04 samchiel slapd[1431]: conn=109 op=0 BIND dn="" method=163 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND dn="" method=163 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND authcid="postfix" authzid="postfix" May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 BIND dn="cn=postfix administrator,ou=infrastructure,dc=linuxwall,dc=info" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 May 23 12:57:04 samchiel slapd[1431]: conn=109 op=1 RESULT tag=97 err=0 text= May 23 12:57:04 samchiel slapd[1431]: conn=109 op=2 RESULT tag=120 err=123 text=not authorized to assume identity May 23 12:57:04 samchiel slapd[1431]: conn=109 op=2 do_extended: get_ctrls failed May 23 12:57:04 samchiel slapd[1431]: conn=109 op=3 UNBIND May 23 12:57:04 samchiel slapd[1431]: conn=109 fd=17 closed May 23 12:57:04 samchiel slapd[1431]: connection_read(17): no connection!
I don't understand this error 'not authorized to assume identity'... Since proxy authorization works fine when I test it with ldapwhoami. Also, on the same machine, I have a cyrus-imapd server that authenticates on the same slapd using the same ldapdriver. Thus, I don't think either slapd or cyrus-sasl are the problem, but since I don't understand the error.....
Can you guys give me a hand here ?
Can you check what exact operation is being attempted? I mean: what identity "cn=postfix administrator,ou=infrastructure,dc=linuxwall,dc=info" is trying to authorize as during conn=109 op=2? You should try to reproduce the authorization part of it, e.g. using ldapwhoami as the postfix administrator, and authorizing with exactly the same identity is being used in that operation, using "stats,trace,args" log level to see where it fails.
p.
Julien Vehent julien@linuxwall.info writes:
Hello list,
I am trying to authenticate my mail users against my ldap directory (slapd 2.4.17, debian squeeze). I have setup proxy authorization for user postfix as follow:
in slapd.conf
# SASL proxy authorization rewrite rule authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=linuxwall,dc=info??sub?(uid=$1)"
This regexp requires a uid attribute type.
authz-policy to
ldif of user postfix
dn: cn=Postfix Administrator,ou=infrastructure,dc=linuxwall,dc=info authzto: ldap:///dc=linuxwall,dc=info??sub?(objectClass=inetOrgPerson) cn: Postfix Administrator [...]
unless you cut it, cn=Postfix Administrator has no uid attribute type,
[...]
-Dieter
Julien Vehent julien@linuxwall.info writes:
Hello list,
I am trying to authenticate my mail users against my ldap directory (slapd 2.4.17, debian squeeze). I have setup proxy authorization for user postfix as follow:
in slapd.conf
# SASL proxy authorization rewrite rule authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=linuxwall,dc=info??sub?(uid=$1)"
This regexp requires a uid attribute type.
authz-policy to
ldif of user postfix
dn: cn=Postfix Administrator,ou=infrastructure,dc=linuxwall,dc=info authzto: ldap:///dc=linuxwall,dc=info??sub?(objectClass=inetOrgPerson) cn: Postfix Administrator [...]
unless you cut it, cn=Postfix Administrator has no uid attribute type,
This *should* have nothing to do, since binding as the Postfix administrator succeeds, according to the logging he produced. What's failing is the subsequent proxyauthz'ing (presumably as a user, but the original posting did not produce enough info).
p.
On Sun, 23 May 2010 18:35:21 +0200 (CEST), masarati@aero.polimi.it wrote:
Can you check what exact operation is being attempted? I mean: what identity "cn=postfix
administrator,ou=infrastructure,dc=linuxwall,dc=info"
is trying to authorize as during conn=109 op=2? You should try to reproduce the authorization part of it, e.g. using ldapwhoami as the postfix administrator, and authorizing with exactly the same identity is being used in that operation, using "stats,trace,args" log level to see where it fails.
Sweet, thanks for your help at debugging, I found the issue !
In the Slapd logs, when Postfix sends the UID of the user it wants to authenticate as, it sends the email address of the user, ie, for julien, it would send julien@linuxwall.info Therefore,slapd looks for a user that has julien@linuxwall.info in its UID, and obviously doesn't find it...
I asked the folks at the postfix mailing if they know anything about that, and if they have a correction for me.
---- May 24 11:55:30 samchiel slapd[13163]: => get_ctrls May 24 11:55:30 samchiel slapd[13163]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (critical) May 24 11:55:30 samchiel slapd[13163]: parseProxyAuthz: conn 3 authzid="u:julien@linuxwall.info" May 24 11:55:30 samchiel slapd[13163]: slap_sasl_getdn: conn 3 id=u:julien@linuxwall.info [len=23] May 24 11:55:30 samchiel slapd[13163]: slap_sasl_getdn: u:id converted to uid=julien@linuxwall.info,cn=DIGEST-MD5,cn=auth May 24 11:55:30 samchiel slapd[13163]: >>> dnNormalize: <uid=julien@linuxwall.info,cn=DIGEST-MD5,cn=auth> May 24 11:55:30 samchiel slapd[13163]: <<< dnNormalize: <uid=julien@linuxwall.info,cn=digest-md5,cn=auth> May 24 11:55:30 samchiel slapd[13163]: ==>slap_sasl2dn: converting SASL name uid=julien@linuxwall.info,cn=digest-md5,cn=auth to a DN May 24 11:55:30 samchiel slapd[13163]: [rw] authid: "uid=julien@linuxwall.info,cn=digest-md5,cn=auth" -> "ldap:///dc=linuxwall,dc=info??sub(uid=julien@linuxwall.info)" May 24 11:55:30 samchiel slapd[13163]: slap_parseURI: parsing ldap:///dc=linuxwall,dc=info??sub?(uid=julien@linuxwall.info) ----
(complete trace is attached)
Thanks, Julien
On Sun, 23 May 2010 18:35:21 +0200 (CEST), masarati@aero.polimi.it wrote:
Can you check what exact operation is being attempted? I mean: what identity "cn=postfix
administrator,ou=infrastructure,dc=linuxwall,dc=info"
is trying to authorize as during conn=109 op=2? You should try to reproduce the authorization part of it, e.g. using ldapwhoami as the postfix administrator, and authorizing with exactly the same identity is being used in that operation, using "stats,trace,args" log level to see where it fails.
Sweet, thanks for your help at debugging, I found the issue !
In the Slapd logs, when Postfix sends the UID of the user it wants to authenticate as, it sends the email address of the user, ie, for julien, it would send julien@linuxwall.info Therefore,slapd looks for a user that has julien@linuxwall.info in its UID, and obviously doesn't find it...
I asked the folks at the postfix mailing if they know anything about that, and if they have a correction for me.
May 24 11:55:30 samchiel slapd[13163]: => get_ctrls May 24 11:55:30 samchiel slapd[13163]: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (critical) May 24 11:55:30 samchiel slapd[13163]: parseProxyAuthz: conn 3 authzid="u:julien@linuxwall.info" May 24 11:55:30 samchiel slapd[13163]: slap_sasl_getdn: conn 3 id=u:julien@linuxwall.info [len=23] May 24 11:55:30 samchiel slapd[13163]: slap_sasl_getdn: u:id converted to uid=julien@linuxwall.info,cn=DIGEST-MD5,cn=auth May 24 11:55:30 samchiel slapd[13163]: >>> dnNormalize: <uid=julien@linuxwall.info,cn=DIGEST-MD5,cn=auth> May 24 11:55:30 samchiel slapd[13163]: <<< dnNormalize: <uid=julien@linuxwall.info,cn=digest-md5,cn=auth> May 24 11:55:30 samchiel slapd[13163]: ==>slap_sasl2dn: converting SASL name uid=julien@linuxwall.info,cn=digest-md5,cn=auth to a DN May 24 11:55:30 samchiel slapd[13163]: [rw] authid: "uid=julien@linuxwall.info,cn=digest-md5,cn=auth" -> "ldap:///dc=linuxwall,dc=info??sub(uid=julien@linuxwall.info)" May 24 11:55:30 samchiel slapd[13163]: slap_parseURI: parsing ldap:///dc=linuxwall,dc=info??sub?(uid=julien@linuxwall.info)
Just change your authz-regexp line to
authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=linuxwall,dc=info??sub?(|(uid=$1)(mail=$1))"
p.
On Mon, 24 May 2010 15:37:48 +0200 (CEST), masarati@aero.polimi.it wrote:
Just change your authz-regexp line to
authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=linuxwall,dc=info??sub?(|(uid=$1)(mail=$1))"
p.
YES ! I WORKS !
I couldn't be more grateful, I spent days trying to diagnose this, it's written nowhere in the postfix doc that it tries to authenticate using the mail value...
Thanks a lot.
Julien
thanks a lot !
openldap-technical@openldap.org
-
Dieter Kluenter -
Julien Vehent -
masarati＠aero.polimi.it