I'm sure I'm not the only person having this issue, but I absolutely cannot seem to get SASL and LDAP to work. I want SASL to authenticate using the passwords in LDAP, but in the classic chicken-and-egg scenario, you can't talk to LDAP without having SASL working first.
I have the authz-regexp stuff set up and the ldapwhoami seems to show me as being converted from the "uid=username,cn=digest-md5,cn=auth" thing to "uid=username,ou=people,dc=mydomain,dc=com", but ONLY if I've put a user and password into the saslpasswd2 database. If I don't do that, I get invalid SASL credentials on the ldapwhoami.
I'm sure this is really farking simple, but I've googled the kapok out this thing and gotten nowhere.
---------------------------------------------------------------------- - Rick Stevens, Unix Geek rps2@socal.rr.com - - - - Reality: A crutch for those who can't handle science fiction - ----------------------------------------------------------------------
Rick Stevens writes:
I'm sure I'm not the only person having this issue, but I absolutely cannot seem to get SASL and LDAP to work. I want SASL to authenticate using the passwords in LDAP, but in the classic chicken-and-egg scenario, you can't talk to LDAP without having SASL working first.
Hmm, this could use a mention in the Admin Guide.
I haven't tried it myself, but: In addition to setting up slapd to use SASL, you must set up SASL to use LDAP. In Cyrus SASL, that is described in doc/install.html: Build with LDAP support (the circular dependency shows up here too), then use the LDAPDB auxprop plugin.
Hallvard B Furuseth wrote:
I haven't tried it myself, but: In addition to setting up slapd to use SASL, you must set up SASL to use LDAP. In Cyrus SASL, that is described in doc/install.html: Build with LDAP support (the circular dependency shows up here too), then use the LDAPDB auxprop plugin.
If you just want to send a SASL bind request with DIGEST-MD5 mech this is not needed.
Ciao, Michael.
Hallvard B Furuseth wrote:
Rick Stevens writes:
I'm sure I'm not the only person having this issue, but I absolutely cannot seem to get SASL and LDAP to work. I want SASL to authenticate using the passwords in LDAP, but in the classic chicken-and-egg scenario, you can't talk to LDAP without having SASL working first.
Hmm, this could use a mention in the Admin Guide.
No.
I haven't tried it myself, but: In addition to setting up slapd to use SASL, you must set up SASL to use LDAP. In Cyrus SASL, that is described in doc/install.html: Build with LDAP support (the circular dependency shows up here too), then use the LDAPDB auxprop plugin.
The ldapdb plugin is only needed by other SASL-enabled services that are meant to use LDAP for authentication. It does not deserve mention in the OpenLDAP Admin Guide because it is strictly a SASL administrator's concern. That's also why we moved the ldapdb code from the OpenLDAP source tree into the Cyrus SASL source tree, and why the ldapdb plugin is only documented in the Cyrus SASL documentation. Don't muddy the picture by dragging in irrelevant elements.
For SASL authentication within OpenLDAP software, all of the necessary components are already intrinsic to libldap and slapd.
Howard Chu wrote:
Hallvard B Furuseth wrote:
Rick Stevens writes:
I'm sure I'm not the only person having this issue, but I absolutely cannot seem to get SASL and LDAP to work. I want SASL to authenticate using the passwords in LDAP, but in the classic chicken-and-egg scenario, you can't talk to LDAP without having SASL working first.
Hmm, this could use a mention in the Admin Guide.
No.
I haven't tried it myself, but: In addition to setting up slapd to use SASL, you must set up SASL to use LDAP. In Cyrus SASL, that is described in doc/install.html: Build with LDAP support (the circular dependency shows up here too), then use the LDAPDB auxprop plugin.
The ldapdb plugin is only needed by other SASL-enabled services that are meant to use LDAP for authentication. It does not deserve mention in the OpenLDAP Admin Guide because it is strictly a SASL administrator's concern. That's also why we moved the ldapdb code from the OpenLDAP source tree into the Cyrus SASL source tree, and why the ldapdb plugin is only documented in the Cyrus SASL documentation. Don't muddy the picture by dragging in irrelevant elements.
For SASL authentication within OpenLDAP software, all of the necessary components are already intrinsic to libldap and slapd.
That's where I'm getting hosed, guys. I know that SUPPOSEDLY it's all there (this is an F8 install). I have all the passwords set up as cleartext in the userPassword attribute. If I try to authenticate as "root" WITHOUT an entry in sasldb for root, the ldapwhoami NEVER authenticates:
[root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
So, that's pretty obvious that it's NOT looking in LDAP for the password, isn't it? Now, WITH a password in the sasldb:
[root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started SASL username: root SASL SSF: 128 SASL installing layers dn:uid=root,cn=digest-md5,cn=auth Result: Success (0)
So, SASL is happy with an entry in the sasldb, but obviously that DN isn't in the LDAP database. So, I added an authz-regexp:
authz-regexp uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=people,ou=People,dc=gbsbilling,dc=com
Now, ldapwhoami gives me:
[root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started SASL username: root SASL SSF: 128 SASL installing layers dn:uid=root,ou=people,ou=people,dc=gbsbilling,dc=com Result: Success (0)
Isn't that grand! That's what I want (I think), but it requires me to put an entry in the sasldb and I don't think that's necessary from what I gather from the docs. However, without it, I can't authenticate at all, and therefore can't even get to LDAP.
That being said, even that doesn't appear to be enough as I have an access rule:
access to attrs=userPassword by dn="uid=root,ou=people,dc=gbsbilling,dc=com" write by dn="cn=manager,dc=gbsbilling,dc=com" write by dn="cn=manager,ou=aliases,dc=gbsbilling,dc=com" write by anonymous auth by self write by * none
and an ldapsearch as the root user (even using the root DN) will NOT display the userPassword fields. It only will display if I include a rule:
by dn="uid=root,cn=digest-md5,cn=auth" write
as the first rule. So, the rewrite isn't being used in the "access to" stuff at all.
I'm sure I'm spectacularly dense on this but in the immortal words of my boss, "what the fark is going on here?" ---------------------------------------------------------------------- - Rick Stevens, Unix Geek rps2@socal.rr.com - - - - Jimmie crack corn and I don't care...what kind of lousy attitude - - is THAT to have, huh? -- Dennis Miller - ----------------------------------------------------------------------
Rick Stevens wrote:
So, SASL is happy with an entry in the sasldb, but obviously that DN isn't in the LDAP database. So, I added an authz-regexp:
authz-regexp uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=people,ou=People,dc=gbsbilling,dc=com
Now, ldapwhoami gives me:
[root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started SASL username: root SASL SSF: 128 SASL installing layers dn:uid=root,ou=people,ou=people,dc=gbsbilling,dc=com Result: Success (0)
Isn't that grand! That's what I want (I think),
Is that really what you think? Look closely.
dn:uid=root,ou=people,ou=people,dc=gbsbilling,dc=com
but it requires me to put an entry in the sasldb and I don't think that's necessary from what I gather from the docs. However, without it, I can't authenticate at all, and therefore can't even get to LDAP.
That being said, even that doesn't appear to be enough as I have an access rule:
access to attrs=userPassword by dn="uid=root,ou=people,dc=gbsbilling,dc=com" write
And again, look closely.
by dn="uid=root,ou=people,dc=gbsbilling,dc=com" write
by dn="cn=manager,dc=gbsbilling,dc=com" write by dn="cn=manager,ou=aliases,dc=gbsbilling,dc=com" write by anonymous auth by self write by * none
Pay attention to what you're doing.
Howard Chu wrote:
Rick Stevens wrote:
So, SASL is happy with an entry in the sasldb, but obviously that DN isn't in the LDAP database. So, I added an authz-regexp:
authz-regexp uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=people,ou=People,dc=gbsbilling,dc=comNow, ldapwhoami gives me:
[root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started SASL username: root SASL SSF: 128 SASL installing layers dn:uid=root,ou=people,ou=people,dc=gbsbilling,dc=com Result: Success (0)
Isn't that grand! That's what I want (I think),
Is that really what you think? Look closely.
dn:uid=root,ou=people,ou=people,dc=gbsbilling,dc=com
D'oh! Yeah, with all the editing I've done, I'm amazed it's not worse. After making appropriate edits, it still won't work without an entry in sasldb, though:
(after edits and without sasldb entry): [root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
(after edits and WITH an entry in sasldb): [root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started SASL username: root SASL SSF: 128 SASL installing layers dn:uid=root,ou=people,dc=gbsbilling,dc=com Result: Success (0)
So the rewrite is correct now...IF I have sasldb populated. Is there a way to trace if SASL is indeed talking to LDAP and I have other stuff screwed up? I know this seems trivial to you, but I'm just so damned flustered over this that I'm probably making other errors that are obvious to you but clear as mud to me.
but it requires me to put an entry in the sasldb and I don't think that's necessary from what I gather from the docs. However, without it, I can't authenticate at all, and therefore can't even get to LDAP.
That being said, even that doesn't appear to be enough as I have an access rule:
access to attrs=userPassword by dn="uid=root,ou=people,dc=gbsbilling,dc=com" writeAnd again, look closely.
by dn="uid=root,ou=people,dc=gbsbilling,dc=com" writeby dn="cn=manager,dc=gbsbilling,dc=com" write by dn="cn=manager,ou=aliases,dc=gbsbilling,dc=com" write by anonymous auth by self write by * nonePay attention to what you're doing.
Yeah, I know. I've been editing the heck out of these files and some of the cut and paste stuff got hosed.
However, the rewrite still isn't working correctly. Without the special "by dn="uid=root,cn=digest-md5,cn=auth" write" rule:
[root@prophead ~]# ldapsearch -v -w unix__gort -b "ou=people,dc=gbsbilling,dc=com" uid=root (fluff trimmed) # root, People, gbsbilling.com dn: uid=root,ou=People,dc=gbsbilling,dc=com uid: root cn: root objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13938 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 0 gidNumber: 0 homeDirectory: /root gecos: root
WITH the special rule:
[root@prophead ~]# ldapsearch -v -w unix__gort -b "ou=people,dc=gbsbilling,dc=com" uid=root (fluff trimmed) # root, People, gbsbilling.com dn: uid=root,ou=People,dc=gbsbilling,dc=com uid: root cn: root objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13938 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 0 gidNumber: 0 homeDirectory: /root gecos: root userPassword:: dW5peF9fZ29ydA==
So I still can't see the userPassword entry without the special rule.
Please be gentle! I know this seems trivial to you, but it's causing my brain to bleed and I'm tired of washing the pillow cases every day!
---------------------------------------------------------------------- - Rick Stevens, Unix Geek rps2@socal.rr.com - - - - The problem with being poor is that it takes up all of your time - ----------------------------------------------------------------------
Rick Stevens wrote:
Howard Chu wrote:
by dn="cn=manager,dc=gbsbilling,dc=com" write by dn="cn=manager,ou=aliases,dc=gbsbilling,dc=com" write by anonymous auth by self write by * nonePay attention to what you're doing.
Yeah, I know. I've been editing the heck out of these files and some of the cut and paste stuff got hosed.
Without really testing it your ACL looks bogus to me.
At the end it should be something like [..] by dn="cn=manager,ou=aliases,dc=gbsbilling,dc=com" write by self write by * auth
Anyway I would make the userPassword attribute write-only. Example:
access to attrs=userPassword by group="cn=Password Admins,ou=Groups,dc=stroeder,dc=local" =wx by self =wx by * =x
Also take note of http://www.openldap.org/its/index.cgi?findid=5400 when running with OpenLDAP 2.4.x.
Ciao, Michael.
Rick Stevens wrote:
Howard Chu wrote:
Rick Stevens wrote:
So, SASL is happy with an entry in the sasldb, but obviously that DN isn't in the LDAP database. So, I added an authz-regexp:
authz-regexp uid=([^,]*),cn=[^,]*,cn=auth uid=$1,ou=people,ou=People,dc=gbsbilling,dc=comNow, ldapwhoami gives me:
[root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started SASL username: root SASL SSF: 128 SASL installing layers dn:uid=root,ou=people,ou=people,dc=gbsbilling,dc=com Result: Success (0)
Isn't that grand! That's what I want (I think),
Is that really what you think? Look closely.
dn:uid=root,ou=people,ou=people,dc=gbsbilling,dc=com
D'oh! Yeah, with all the editing I've done, I'm amazed it's not worse. After making appropriate edits, it still won't work without an entry in sasldb, though:
(after edits and without sasldb entry): [root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
(after edits and WITH an entry in sasldb): [root@prophead ~]# ldapwhoami -w unix__gort SASL/DIGEST-MD5 authentication started SASL username: root SASL SSF: 128 SASL installing layers dn:uid=root,ou=people,dc=gbsbilling,dc=com Result: Success (0)
So the rewrite is correct now...IF I have sasldb populated. Is there a way to trace if SASL is indeed talking to LDAP and I have other stuff screwed up? I know this seems trivial to you, but I'm just so damned flustered over this that I'm probably making other errors that are obvious to you but clear as mud to me.
but it requires me to put an entry in the sasldb and I don't think that's necessary from what I gather from the docs. However, without it, I can't authenticate at all, and therefore can't even get to LDAP.
That being said, even that doesn't appear to be enough as I have an access rule:
access to attrs=userPassword by dn="uid=root,ou=people,dc=gbsbilling,dc=com" writeAnd again, look closely.
by dn="uid=root,ou=people,dc=gbsbilling,dc=com" writeby dn="cn=manager,dc=gbsbilling,dc=com" write by dn="cn=manager,ou=aliases,dc=gbsbilling,dc=com" write by anonymous auth by self write by * nonePay attention to what you're doing.
Yeah, I know. I've been editing the heck out of these files and some of the cut and paste stuff got hosed.
However, the rewrite still isn't working correctly. Without the special "by dn="uid=root,cn=digest-md5,cn=auth" write" rule:
[root@prophead ~]# ldapsearch -v -w unix__gort -b "ou=people,dc=gbsbilling,dc=com" uid=root (fluff trimmed) # root, People, gbsbilling.com dn: uid=root,ou=People,dc=gbsbilling,dc=com uid: root cn: root objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13938 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 0 gidNumber: 0 homeDirectory: /root gecos: root
WITH the special rule:
[root@prophead ~]# ldapsearch -v -w unix__gort -b "ou=people,dc=gbsbilling,dc=com" uid=root (fluff trimmed) # root, People, gbsbilling.com dn: uid=root,ou=People,dc=gbsbilling,dc=com uid: root cn: root objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13938 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 0 gidNumber: 0 homeDirectory: /root gecos: root userPassword:: dW5peF9fZ29ydA==
So I still can't see the userPassword entry without the special rule.
Please be gentle! I know this seems trivial to you, but it's causing my brain to bleed and I'm tired of washing the pillow cases every day!
- Rick Stevens, Unix Geek rps2@socal.rr.com -
-- The problem with being poor is that it takes up all of your time -
Ok, I found the glitch. The slapd.conf file doesn't really "ignore" lines starting with a "#". My "access to attrs=userPassword" line was immediately followed by a commented out rule. The parser didn't like that so it ignored the "access to" stuff completely. When I deleted that line, SASL started to authenticate against LDAP.
SHEESH!
Thanks for putting up with my incredible stupidity. I hope I don't need to bother you chaps again.
---------------------------------------------------------------------- - Rick Stevens, Unix Geek rps2@socal.rr.com - - - - You possess a mind not merely twisted, but actually sprained. - - Mine was removed long ago! - ----------------------------------------------------------------------
On Friday 07 March 2008 00:18:13 Rick Stevens wrote:
Ok, I found the glitch. The slapd.conf file doesn't really "ignore" lines starting with a "#".
It does. But, if you have a single statement running over multiple lines, the *first* line that doesn't start with a leading space terminates the statement. Always consider how a statement would look if you wrote it on one line, e.g.:
access to attrs=userPassword by cn=root,dc=mydomain,dc=com write # by group="cn=Account Admins,dc=mydomain,dc=com write by self write by * auth
is going to end up terminating at the # ...
I note that no comment lines appeared in the ACLs you posted ... if you had included the exact contents, this could probably have been resolved a lot sooner ...
Regards, Buchan
Rick Stevens skrev, on 06-03-2008 20:37:
[...]
[root@prophead ~]# ldapsearch -v -w unix__gort -b "ou=people,dc=gbsbilling,dc=com" uid=root (fluff trimmed) # root, People, gbsbilling.com dn: uid=root,ou=People,dc=gbsbilling,dc=com uid: root cn: root objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13938 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 0 gidNumber: 0 homeDirectory: /root gecos: root userPassword:: dW5peF9fZ29ydA==
You need one more attribute there, an operational attribute that you can add with ldapmodify: authzTo. Did you read your rps2@socal.rr.com mail today? I sent you a link off list to a complete HOWIDIDIT I wrote in 2004.
Best,
--Tonni
Tony Earnshaw wrote:
Rick Stevens skrev, on 06-03-2008 20:37:
[...]
[root@prophead ~]# ldapsearch -v -w unix__gort -b "ou=people,dc=gbsbilling,dc=com" uid=root (fluff trimmed) # root, People, gbsbilling.com dn: uid=root,ou=People,dc=gbsbilling,dc=com uid: root cn: root objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13938 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 0 gidNumber: 0 homeDirectory: /root gecos: root userPassword:: dW5peF9fZ29ydA==
You need one more attribute there, an operational attribute that you can add with ldapmodify: authzTo. Did you read your rps2@socal.rr.com mail today? I sent you a link off list to a complete HOWIDIDIT I wrote in 2004.
Yes, I did see it. I'm sorry I didn't respond directly when I got it.
I've got things working more or less at this point. I'll get the authzTo thing sorted out tomorrow.
Thanks again for the help. ---------------------------------------------------------------------- - Rick Stevens, Unix Geek rps2@socal.rr.com - - - - Try to look unimportant. The bad guys may be low on ammo. - ----------------------------------------------------------------------
Tony Earnshaw wrote:
You need one more attribute there, an operational attribute that you can add with ldapmodify: authzTo.
No, the authzTo attribute has nothing to do with mapping a SASL identity to a LDAP entry DN!
It is used for specifying the set of possible authz-DNs for a specific authc-DN when proxy authorization control is sent along with a LDAP request by this identity. This is a totally different thing.
Ciao, Michael.
Michael Ströder skrev, on 07-03-2008 11:41:
You need one more attribute there, an operational attribute that you can add with ldapmodify: authzTo.
No, the authzTo attribute has nothing to do with mapping a SASL identity to a LDAP entry DN!
It is used for specifying the set of possible authz-DNs for a specific authc-DN when proxy authorization control is sent along with a LDAP request by this identity. This is a totally different thing.
Funnily enough this is what I use it for ...
Best,
--Tonni
Tony Earnshaw wrote:
Michael Ströder skrev, on 07-03-2008 11:41:
You need one more attribute there, an operational attribute that you can add with ldapmodify: authzTo.
No, the authzTo attribute has nothing to do with mapping a SASL identity to a LDAP entry DN!
It is used for specifying the set of possible authz-DNs for a specific authc-DN when proxy authorization control is sent along with a LDAP request by this identity. This is a totally different thing.
Funnily enough this is what I use it for ...
But you definitely don't need it for SASL authc-DN mapping to authz-DN (user entry). So please don't give this wrong/misleading advice to someone who is just starting to get familiar with all this.
Ciao, Michael.
Rick Stevens wrote:
I'm sure I'm not the only person having this issue, but I absolutely cannot seem to get SASL and LDAP to work. I want SASL to authenticate using the passwords in LDAP, but in the classic chicken-and-egg scenario, you can't talk to LDAP without having SASL working first.
It works for me.
I have the authz-regexp stuff set up and the ldapwhoami seems to show me as being converted from the "uid=username,cn=digest-md5,cn=auth" thing to "uid=username,ou=people,dc=mydomain,dc=com", but ONLY if I've put a user and password into the saslpasswd2 database. If I don't do that, I get invalid SASL credentials on the ldapwhoami.
I have no saslpasswd2 file at all. Make sure you store the password as clear-text in attribute userPassword.
Ciao, Michael.
openldap-software@openldap.org
-
Buchan Milne -
Hallvard B Furuseth -
Howard Chu -
Michael Ströder -
Rick Stevens -
Tony Earnshaw