SASL/OTP woes...

[David Pisoni <dpisoni@lrn.com>]

Hello again,

I'm going to document my attempts at implementing SASL/OTP authentication
with OpenLDAP, in the hope that someone can shed some light on the subject.

FYI - I am running OpenLDAP 2.1.9, Cyrus-SASL 2.1.7, and Opie 2.4 on RedHat
Linux 8.0 (kernel 2.4.18).

I would like to be able to use SASL/OTP with all data in the directory.  I
suppose it would be acceptable to use the sasldb, but the directory would be
ideal.  Here is what I have discovered thus far:

here is my ACL in slapd.conf, for reference:

sasl-regexp
  uid=(.*),cn=.*,cn=auth
  uid=$1,ou=People,dc=lrn,dc=com

access to attr=userpassword
	by self write
	by * compare

access to attr=cmusaslsecretOTP
	by self write
	by * compare

access to *
	by self write
	by users read
	by anonymous read

--------

If I created a sasldb entry (with saslpasswd2) corresponding to the uid I am
attempting to authenticate, the OTP process will initiate through OpenLDAP,
though it will ultimately torpedo slapd (SIGSEGV) after it succeeds.  Of
course, with this procedure, both the secret at the OTP stuff is held in the
sasldb.)
so...

$ saslpasswd2 -c dpisoni
 (lets say password '123123')
$ ldapsearch -Y OTP -U dpisoni -b 'dc=lrn,dc=com' -s one '(objectclass=*)'
SASL/OTP authentication started
Challenge: otp-md5 498 lo1450 ext
Please enter your one-time password: 54FF 7EAE 7E21 9C38
ldap_sasl_interactive_bind_s: Can't contact LDAP server (81)

At this point slapd has stopped without logging its death or leaving a core
file.  But if you restart slapd and run ldapsearch again, the OTP counter is
decremented to 497 -- evidence that the authentication completed.

-----------

Next, I discovered a kluge which would allow me to put the OTP data in the
directory:  I created an attributeType called "cmusaslsecretOTP", which
matches what sasl is creating in sasldb after the first OTP exchange
(above.)  I then copied from the sasldb the contents of said attribute and
inserted that into my "person" entry.  Then I deleted the user from sasldb.

$ ldapmodify -x -D 'cn=Manager,dc=lrn,dc=com' -W
Enter LDAP Password:
changetype: modify
dn: uid=dpisoni,ou=People,dc=lrn,dc=com
cmusaslsecretOTP:: bWQ1ADA0OTgAbG8xNDUwAFQAfgB+IQk4AAAAAA==
userPassword: 123123

modifying entry "uid=dpisoni,ou=People,dc=lrn,dc=com"
$ saslpasswd2 -d dpisoni

(The value above is the base64 encoded contents of the cmusaslsecretOTP for
dpisoni in sasldb.)

This has a peculiar result -- the sasl library, after failing to find the
aforementioned field in sasldb looks for it in the directory and finds it!
(Sounds like someone got lazy with the matching for userPassword, so
anything Cyrus looks for might match.)  Here's what happens :

$ ldapsearch -Y OTP -U dpisoni -b 'dc=lrn,dc=com' -s one '(objectclass=*)'
SASL/OTP authentication started
Challenge: otp-md5 497 lo1450 ext
Please enter your one-time password: C268 F670 4DFA 040B
ldap_sasl_interactive_bind_s: Invalid credentials (49)
        additional info: SASL(-13): authentication failure: user:
dpisoni@localhost.localdomain property: md5 not found in sasldb

So we're reading the cmusaslsecretOTP, but not the userPassword.  And "md5
not found in sasldb"?  Huh?  That error doesn't make much sense to me at
all. There is no "md5" attribute anywhere, nor should there be.  Why won't
it read the userPassword?

-----------

So that's where I am now.  Any ideas?

Thanks,
David Pisoni
Sr. Software Engineer
LRN, The Legal Knowledge Company
http://www.lrn.com/