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

Re: simple bind with external Kerberos V password store

On Tue, 2 Feb 2010, Tim Mooney wrote:


grep'ing the source for '{KERBEROS}', the only place that shows up is
in contrib/slapd-modules/passwd/kerberos.c.
[...]
I understand the warning at the end of the section in the admin guide,
that using a krb5 KDC as a fancy network-based password checking database
is not Kerberos at all, and that if we go this route we'll want to make
certain that at a minimum binds are done over TLS.
Well, the second paragraph is the important one, so with that incorporated on the record...
The more common way to do this nowadays is via the {SPASSWD} SASL simple bind integration. Some broad steps to go that route:
1. Compile saslauthd to interface with your existing KDC. Generally the included SASL mechs will work. However, on my servers, I make things even uglier than usual by not even dealing with the tickets for simple binds. To do this we have our own mech in saslauthd. If you're interested start with: 

http://cvs.rutgers.edu/cgi-bin/viewvc.cgi/trunk/SPECS/cyrus-sasl.spec
http://cvs.rutgers.edu/cgi-bin/viewvc.cgi/trunk/source-patches/sasl-rukrb5-source.patch
http://cvs.rutgers.edu/cgi-bin/viewvc.cgi/trunk/source-patches/sasl-rukrb5-support.patch
2. If you're using our mech, configure your krb5.conf, and Cyrus's slapd.conf should have "pwcheck_method:saslauthd" -- then start "saslauthd -a rukrb5". 

3. Regardless of your mech,
testsaslauthd -s slapd -r REALM.EXAMPLE.COM -u uid -p secret should return success.
4. OK, now it's time for OpenLDAP. Grab Buchan's packages (or something based off them); you can steal a 2.4.21 incarnation of those from koji.rutgers.edu if you want. (I don't know if he got to 2.4.21 yet.) The important part here is making sure that --enable-spasswd is there. 

5. Install OpenLDAP. Add an entry with:

  userPassword: {SASL}uid@REALM.EXAMPLE.COM
and try to bind. Turn up saslauthd and/or slapd debugging if there are issues.