[Date Prev][Date Next] [Chronological] [Thread] [Top]

SASL secrets in LDAP (I did review the archive on this...)



Hi List-

About 7 or 8 months ago, I started learning in earnest about OpenLDAP. 
Then in March, I posted to this list with some conceptual questions
about LDAP on which Tony/Tonni Earnshaw most graciously helped me out. 
One of his suggestions was to get GQ and fiddle and learn that way. 
This worked wonders for me and I really appreciate your help, Tonni.

I also asked about getting OpenLDAP integrated with MIT Kerberos and
OpenAFS and with some help from this list, I got that one figured out
too.  Again, many thanks to you terrific folks here.

Now I'm trying to get SASL secrets stored in the LDAP directory itself
(vice the sasldb2), and while I see from the archives that this topic
has come up before, I'm not seeing the results of success that some
others have reported when I do the same things they did (at least I
think I'm doing the same thing...).

So, my apologies if this is beating a dead horse, but I've struggled
with this for the entire day today and while I have made much progress,
I can't seem to solve the problem of making SASL look in the LDAP
directory itself for secrets.

I'm successfully doing simple authentication, SASL authentication with
the GSSAPI mechanism against a MIT Kerberos 5 KDC, and SASL
authentication with the DIGEST-MD5 mechanism against the sasldb2.

Among many other documents, I read the SASL sysadmin.html that comes
with that package (in particular about the default configuration file
which I presume in this case should be /usr/lib/sasl2/slapd.conf) and
the OpenLDAP Admin Guide at
http://www.openldap.org/doc/admin22/sasl.html#DIGEST-MD5 and payed extra
attention to the sasl-regexp bits on searching through the directory for
a DN.  I also found Howard Chu's comments on the lists' archives at:
http://www.openldap.org/lists/openldap-devel/200205/msg00043.html
http://www.openldap.org/lists/openldap-software/200207/msg00288.html

along with many others, but these seemed to be the most relevant to the
issue, and I did what Andrew Findlay did (and what is mentioned in the
other docs I read above), namely:
> /usr/lib/sasl2/slapd.conf :
> 
>       # SASL2 config file for slapd
> 
>       # Tell slapd to use itself for secret storage
>       auxprop_plugin: slapd
tombstone root # ls -l /usr/lib/sasl2/slapd.conf
-rw-r--r--  1 root root 22 Oct 16 21:44 /usr/lib/sasl2/slapd.conf

...but in spite of everything, I'm quite certain that slapd is not
consulting the directory for the secrets.

It may be that the most likely cause is my sasl-regexp (I have a limited
understanding of regexp's in general, but the examples in the Admin
Guide and in the archive seemed pretty straightforward, but maybe I
screwed them up somehow).

I've tried some 5 or 8 different sasl-regexp's, but the one that I think
is correct is here:

sasl-regexp
 uid=(.*),cn=asciolla.com,cn=digest-md5,cn=auth
 ldap:///ou=people,dc=asciolla,dc=com??sub?(mail=$1)

It's very close to an example in the Admin Guide.

One thing to take note of is that I've tried to design a smart directory
layout for keeping track of virtual domains (although I'm sure it could
be improved quite alot), and I'm using the following in my directory
(apologies is there's more here than is needed, but I suppose the
problem could also be in my directory design):

=====================================
tombstone root # ldapsearch -I -Y DIGEST-MD5 -b "dc=asciolla,dc=com"
SASL/DIGEST-MD5 authentication started
SASL Interaction
Please enter your authorization name: joepost@asciolla.com
Default: root
Please enter your authentication name: joepost@asciolla.com
Please enter your password:
SASL username: joepost@asciolla.com
SASL SSF: 128
SASL installing layers
# extended LDIF
#
# LDAPv3
# base <dc=asciolla,dc=com> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# asciolla.com
dn: dc=asciolla,dc=com
dc: asciolla
objectClass: dcObject
objectClass: organization
o: Asciolla Family Dentistry, Inc.

# people, asciolla.com
dn: ou=people,dc=asciolla,dc=com
ou: people
krb5RealmName: ASCIOLLA.COM
objectClass: organizationalUnit
objectClass: krb5Realm

# abuse, asciolla.com
dn: cn=abuse,dc=asciolla,dc=com
cn: abuse
objectClass: organizationalRole
objectClass: simpleSecurityObject
objectClass: CourierMailAlias
userPassword:: <snip>
mail: abuse@asciolla.com
maildrop: abuse
roleOccupant: mail=joepost@asciolla.com,ou=people,dc=asciolla,dc=com

# postmaster, asciolla.com
dn: cn=postmaster,dc=asciolla,dc=com
cn: postmaster
objectClass: organizationalRole
objectClass: simpleSecurityObject
objectClass: CourierMailAlias
userPassword:: <snip>
mail: postmaster@asciolla.com
maildrop: postmaster
roleOccupant: mail=joepost@asciolla.com,ou=people,dc=asciolla,dc=com

# webmaster, asciolla.com
dn: cn=webmaster,dc=asciolla,dc=com
cn: webmaster
objectClass: organizationalRole
objectClass: simpleSecurityObject
objectClass: CourierMailAlias
userPassword:: <snip>
mail: webmaster@asciolla.com
maildrop: webmaster
roleOccupant: mail=joepost@asciolla.com,ou=people,dc=asciolla,dc=com

# userone@asciolla.com, people, asciolla.com
dn: mail=userone@asciolla.com,ou=people,dc=asciolla,dc=com
objectClass: inetOrgPerson
objectClass: krb5Principal
objectClass: krb5KDCEntry
objectClass: posixAccount
objectClass: CourierMailAccount
cn: User One
sn: One
uid: userone
mail: userone@asciolla.com
homeDirectory: /var/spool/imap/domain
uidNumber: 1003
gidNumber: 101
mailbox: /a/asciolla.com/u/user/userone
krb5PrincipalName: userone@ASCIOLLA.COM
krb5KeyVersionNumber: 1
userPassword:: <snip>

# joepost@asciolla.com, people, asciolla.com
dn: mail=joepost@asciolla.com,ou=people,dc=asciolla,dc=com
objectClass: inetOrgPerson
objectClass: krb5Principal
objectClass: krb5KDCEntry
objectClass: posixAccount
objectClass: CourierMailAccount
cn: Joe Postmaster
sn: Postmaster
uid: joepost
mail: joepost@asciolla.com
homeDirectory: /var/spool/imap/domain
uidNumber: 1004
gidNumber: 101
mailbox: /a/asciolla.com/j/user/joepost
krb5PrincipalName: joepost@ASCIOLLA.COM
krb5KeyVersionNumber: 1
userPassword:: <snip>
=====================================

I currently have two other similar-looking bases as will be apparent in
my /etc/openldap/slapd.conf file:

=====================================
tombstone root # cat /etc/openldap/slapd.conf|grep -v ^\#
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/java.schema
include         /etc/openldap/schema/corba.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/openldap.schema
include         /etc/openldap/schema/samba.schema
include         /etc/openldap/schema/ksf-zeus/krb5-kdc.schema
include         /etc/openldap/schema/courier.schema

loglevel        296
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

include         /etc/openldap/slapd.access
srvtab          /etc/krb5.keytab
sasl-realm      GNOSYS.US

referral        ldap://root.openldap.org:389

database        bdb
suffix          "dc=gnosys,dc=us"
rootdn          "uid=ldap/admin,cn=GNOSYS.US,cn=gssapi,cn=auth"
directory       /var/lib/openldap-data
index   objectClass     eq
index   uidNumber               eq
index   gidNumber               eq
index   cn,sn,mail              eq,sub
index   departmentNumber        eq
cachesize               2000

database        bdb
suffix          "dc=folkvang,dc=biz"
rootdn          "uid=ldap/admin,cn=GNOSYS.US,cn=gssapi,cn=auth"
directory       /var/lib/openldap/folkvang.biz
index           objectClass     eq
index           uidNumber               eq
index           gidNumber               eq
index           cn,sn,mail              eq,sub
index           departmentNumber        eq
cachesize       2000

database        bdb
suffix          "dc=asciolla,dc=com"
rootdn          "uid=ldap/admin,cn=GNOSYS.US,cn=gssapi,cn=auth"
directory       /var/lib/openldap/asciolla.com
index           objectClass     eq
index           uidNumber               eq
index           gidNumber               eq
index           cn,sn,mail              eq,sub
index           departmentNumber        eq
cachesize       2000

password-hash                   {CLEARTEXT}
=====================================

the sasl-regexp above is in the slapd.access file, along with several
others that I tried (but commented out so that they didn't accidentally
match).

The error messages that I'm getting seem pretty unambiguous:

tombstone root # ldapsearch -I -Y DIGEST-MD5 -b "dc=asciolla,dc=com"
SASL/DIGEST-MD5 authentication started
SASL Interaction
Please enter your authorization name: joepost@asciolla.com
Default: root
Please enter your authentication name: joepost@asciolla.com
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
        additional info: SASL(-13): authentication failure: client
response doesn't match what we generated
tombstone root # ldapsearch -I -Y DIGEST-MD5 -b "dc=asciolla,dc=com"
SASL/DIGEST-MD5 authentication started
SASL Interaction
Please enter your authorization name: userone@asciolla.com
Default: root
Please enter your authentication name: userone@asciolla.com
Please enter your password:
ldap_sasl_interactive_bind_s: Internal (implementation specific) error
(80)
        additional info: SASL(-13): user not found: no secret in
database
tombstone root # ldapsearch -I -Y DIGEST-MD5 -b "dc=asciolla,dc=com"
SASL/DIGEST-MD5 authentication started
SASL Interaction
Please enter your authorization name: userone@ASCIOLLA.COM
Default: root
Please enter your authentication name: userone@ASCIOLLA.COM
Please enter your password:
ldap_sasl_interactive_bind_s: Internal (implementation specific) error
(80)
        additional info: SASL(-13): user not found: no secret in
database

In the first attempt, I'm using the password that is stored in the
directory (which is different from the one stored in sasldb2 for that
user) and getting invalid credentials---apparently because it doesn't
match the password in sasldb (in spite of my /usr/lib/sasl2/slapd.conf
file).

In the second, I'm using a second user that exists only in the directory
and not in the sasldb2 and obviously getting no user found.

I tried the third because I read some reports about case sensitivity,
and I do have a capitalized krb5RealmName in the directory, but I don't
think that's being consulted here anyway, and in any case, I found no
success here either.

When I look at the syslog comments, the logged messages seem to be
saying pretty much the same thing (I'll gladly post them if someone
asks).

Can anyone help me out here?  Am I forgetting something obvious? 
Perhaps I've been struggling with this problem for so long that I've
lost perspective and am missing something that's staring me in the face.

Any suggestions would be most appreciated and regardless, many thanks to
you folks for making OpenLDAP and for the several helpful email messages
helping me solve other problems in the past.

-Kevin

PS. I'm using the following distribution & package versions:
Gentoo Linux (with recently updated packages for most everything)
openldap-2.1.30-r3
cyrus-sasl-2.1.19-r1
cyrus-imapd-2.2.8
mit-krb5-1.3.5
gq-1.0_beta1