[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Getting LDAP and SASL (digest-md5) to play nice
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=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
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" 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.
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 -
----------------------------------------------------------------------