All-
I'm interested in what the state of Kerberos (external) password storage scheme is, as mentioned in the Admin Guide, section 14.4.7.
We're currently using openldap 2.3.mumble (it's old) and will be upgrading to 2.4.21 or later soon, on RHEL 5.x.
We don't currently do user or application authentication to our OpenLDAP. Because of the number of applications we're seeing that support "ldap authentication" but don't have any way to do true or even fake Kerberos V authentication, I've been asked to determine what would be involved in allowing ldap authentication, but having slapd use our MIT krb5 infrastructure behind the scenes.
Section 14.4.7 of the admin guide seems to indicate that OpenLDAP can already do exactly what we need, but no additional details are provided. Searching the openldap-software archives, Kurt Zeilenga provides a bit more info on how I might go about configuring this here:
http://www.openldap.org/lists/openldap-software/200010/msg00462.html
grep'ing the source for '{KERBEROS}', the only place that shows up is in contrib/slapd-modules/passwd/kerberos.c.
Can anyone shed any more light on what state this is in? Kurt's 9 year old post and the current admin guide seem to imply that using an external kerberos password store for userPasswords is a standard part of OpenLDAP, but the source seems to imply otherwise. If the {KERBEROS}princ@REALM method works and isn't completely deprecated I would choose that route, otherwise I suppose I'll have to investigate SASL as described in section 14.4.6 and 14.5 of the admin guide.
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.
Thanks,
Tim
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-s... http://cvs.rutgers.edu/cgi-bin/viewvc.cgi/trunk/source-patches/sasl-rukrb5-s...
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.
we use pam_krb5.so to achieve this.. (no mods necessary)
auth sufficient pam_krb5.so no_user_check account required pam_krb5.so no_user_check
then we configure slapd to use saslauthd and then set saslauthd to use pam
and then use {SASL}principal@REALM as the userpassword
we use saslauthd to cache credentials, etc
Tom
-----Original Message----- From: openldap-software-bounces+tomryan=camlaw.rutgers.edu@openldap.org on behalf of Aaron Richton Sent: Tue 2/2/2010 5:40 PM To: Tim Mooney Cc: openldap-software@openldap.org Subject: 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-s... http://cvs.rutgers.edu/cgi-bin/viewvc.cgi/trunk/source-patches/sasl-rukrb5-s...
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.
On Tuesday, 2 February 2010 23:40:47 Aaron Richton wrote:
- 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.)
I built 2.4.21 with internal db4.8 before going on leave, but didn't have time to upload them. Having recently returned from leave, I hope to upload them over the weekend.
Regards, Buchan
openldap-software@openldap.org
-
Aaron Richton -
Buchan Milne -
Tim Mooney -
Tom Ryan