Hi group,
I have been fighting the whole day already for something that I think is quite simple but I just can't get it to work: have slapd authenticate users against kerberos. Following many tutorials, trying many things, I give up on that and ask for your help.
System: Debian Lenny.
Situation: - workstation logins over the network authenticate against kerberos - credentials from LDAP - postfix has its alias database etc in LDAP, as are the groups and userIDs and everything - helps keeping uids the same on the workstations. Essential for NFS. - anything using pam will be authenticated against kerberos, including imap, postfix, etc.
Except LDAP. Then slapd authenticates by itself against the password stored there. And that's not what I want. There should be no passwords in LDAP any more, everything against kerberos. Then at least when a user changes their kerberos password, the same password is used everywhere. I just can't get this to work for some reason. I have followed many tutorials, so many that I forgot what I did, and it still doesn't work.
Slapd should use pam to authenticate, or directly talk to the kerberos server, whatever.
saslauthd has the gssapi module installed.
I have created an ldap/acorn.squirrel@SQUIRREL key, and added this keytab in /etc/defaults/slapd. acorn.squirrel is the fqdn of the server, SQUIRREL is its kerberos realm.
My clients all run Ubuntu 10.04 LTS (a nice desktop but shitty to get kerberos/ldap authentication work on amongst other griefs).
Current situation after all the hacking: $ ldapwhoami -x -D 'uid=wouter,ou=people,dc=squirrel' -W -h acorn.squirrel Enter LDAP Password: ldap_bind: Invalid credentials (49) when entering my Kerberos password; it accepts my credentials when I enter the LDAP stored password (a different password).
Then I just did: ======================= wouter@acorn:~$ ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) wouter@acorn:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000_5lYS4w Default principal: wouter@SQUIRREL
Valid starting Expires Service principal 09/08/10 22:42:07 09/09/10 08:42:07 krbtgt/SQUIRREL@SQUIRREL renew until 09/09/10 22:42:07 09/08/10 22:46:39 09/09/10 08:42:07 ldap/acorn.squirrel@SQUIRREL renew until 09/09/10 22:42:07
Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached =======================
OK it seems ldap gets it's ticket. Issued the moment I ran the above command. Still I get the bind error. But for some reason I do not have a ticket myself, interesting. Running kinit doesn't solve this strangely enough, on the workstations it does give me a ticket. And running kinit kills the ldap ticket. Appears strange to me.
Any ideas? I probably miss something very simple... it shouldn't be that hard to have slapd get its credentials from kerberos!
Thanks!
Wouter.
On 08/09/10 22:53 +0800, Wouter van Marle wrote:
Hi group,
I have been fighting the whole day already for something that I think is quite simple but I just can't get it to work: have slapd authenticate users against kerberos. Following many tutorials, trying many things, I give up on that and ask for your help.
System: Debian Lenny.
Situation:
- workstation logins over the network authenticate against kerberos
- credentials from LDAP
- postfix has its alias database etc in LDAP, as are the groups and
userIDs and everything - helps keeping uids the same on the workstations. Essential for NFS.
- anything using pam will be authenticated against kerberos,
including imap, postfix, etc.
Except LDAP. Then slapd authenticates by itself against the password stored there. And that's not what I want. There should be no passwords in LDAP any more, everything against kerberos. Then at least when a user changes their kerberos password, the same password is used everywhere. I just can't get this to work for some reason. I have followed many tutorials, so many that I forgot what I did, and it still doesn't work.
Slapd should use pam to authenticate, or directly talk to the kerberos server, whatever.
saslauthd has the gssapi module installed.
I have created an ldap/acorn.squirrel@SQUIRREL key, and added this keytab in /etc/defaults/slapd. acorn.squirrel is the fqdn of the server, SQUIRREL is its kerberos realm.
To have slapd use saslauthd for authentication, you'll need to create the file /usr/lib/sasl2/slapd.conf, with these contents:
pwcheck_method: saslauthd mech_list: plain login
and optionally
keytab: /etc/krb5.keytab (which is the standard location)
*If* you intend to perform a PLAIN sasl bind, you'll need this in your /etc/ldap/slapd.conf:
sasl-secprops none
If you're planning on supporting non-sasl binds, but still wish to authenticate via saslauthd, your userPassword entries should look like:
userPassword: {SASL}username@realm
and you'll need to verify that your slapd was compiled with the --enable-spasswd option. See section 4.5 (Pass-Through authentication) of the OpenLDAP Administrators Guide.
You could authenticate against a kerberos5 installation with saslauthd a couple of different ways:
1. Authenticate saslauthd against PAM. Edit /etc/default/saslauthd and specify 'pam' as your authentication backend. You'll then need to configure a kerberos pam module to do that actual work.
2. Authenticate saslauthd against kerberos5 ('kerberos5' in /etc/default/saslauthd). I'm not sure if you need to have a valid ticket granting ticket, or if a proper /etc/krb5.conf is all you need.
Current situation after all the hacking: $ ldapwhoami -x -D 'uid=wouter,ou=people,dc=squirrel' -W -h acorn.squirrel Enter LDAP Password: ldap_bind: Invalid credentials (49) when entering my Kerberos password; it accepts my credentials when I enter the LDAP stored password (a different password).
That requires pass-through authentication.
Then I just did:
wouter@acorn:~$ ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) wouter@acorn:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000_5lYS4w Default principal: wouter@SQUIRREL
Valid starting Expires Service principal 09/08/10 22:42:07 09/09/10 08:42:07 krbtgt/SQUIRREL@SQUIRREL renew until 09/09/10 22:42:07 09/08/10 22:46:39 09/09/10 08:42:07 ldap/acorn.squirrel@SQUIRREL renew until 09/09/10 22:42:07
Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached =======================
Do you have ldap/acorn.squirrel@SQUIRREL in /etc/krb5.keytab, on the server? Is it readable by the slapd user?
On 08/09/10 12:15 -0500, Dan White wrote:
To have slapd use saslauthd for authentication, you'll need to create the file /usr/lib/sasl2/slapd.conf, with these contents:
pwcheck_method: saslauthd mech_list: plain login
and optionally
keytab: /etc/krb5.keytab (which is the standard location)
Check that. That should be:
pwcheck_method: saslauthd mech_list: plain login gssapi external keytab: /etc/krb5.keytab
Do you have ldap/acorn.squirrel@SQUIRREL in /etc/krb5.keytab, on the server? Is it readable by the slapd user?
Also see:
http://www.cyrusimap.org/mediawiki/index.php/FAQ#Cyrus_SASL_Questions
Also see:
http://www.cyrusimap.org/mediawiki/index.php/FAQ#Cyrus_SASL_Questions
I followed those steps, finding out that the client didn't have the sasl gssapi module installed (apparently necessary?! I guessed the authentication is done by slapd on the server?).
All other tests mentioned check out fine.
However when I access my address book in Evolution it still only accepts my ldap stored password, not my kerberos password! What could possible be wrong?
Wouter.
To have slapd use saslauthd for authentication, you'll need to create the file /usr/lib/sasl2/slapd.conf, with these contents:
pwcheck_method: saslauthd mech_list: plain login
and optionally
keytab: /etc/krb5.keytab (which is the standard location)
Check. As per a previous trial I created the keytab in a different location; # cat /usr/lib/sasl2/slapd.conf pwcheck_method: saslauthd mech_list: plain login gssapi external keytab: /etc/ldap/ldap.keytab
# ls -l /usr/lib/sasl2/slapd.conf -rw-r--r-- 1 root root 95 2010-09-09 10:03 /usr/lib/sasl2/slapd.conf
# ls -l /etc/ldap/ldap.keytab -rw-r----- 1 root openldap 286 2010-09-08 16:03 /etc/ldap/ldap.keytab
*If* you intend to perform a PLAIN sasl bind, you'll need this in your /etc/ldap/slapd.conf:
sasl-secprops none
Check. Had some probs with SSL before so start with plain. Later I'm just going to close that port in the firewall, for internal use it's secure enough.
If you're planning on supporting non-sasl binds, but still wish to authenticate via saslauthd, your userPassword entries should look like:
userPassword: {SASL}username@realm
and you'll need to verify that your slapd was compiled with the --enable-spasswd option. See section 4.5 (Pass-Through authentication) of the OpenLDAP Administrators Guide.
This one I have no idea what that would do. My understanding is obviously not deep enough.
You could authenticate against a kerberos5 installation with saslauthd a couple of different ways:
- Authenticate saslauthd against PAM. Edit /etc/default/saslauthd and
specify 'pam' as your authentication backend. You'll then need to configure a kerberos pam module to do that actual work.
In /etc/default/saslauthd: MECHANISMS="pam"
Already configured like that. Other logins authenticate fine against pam using my kerberos password (like Cyrus IMAP, and Postfix's smtp authentication), so this part is working fine.
- Authenticate saslauthd against kerberos5 ('kerberos5' in
/etc/default/saslauthd). I'm not sure if you need to have a valid ticket granting ticket, or if a proper /etc/krb5.conf is all you need.
I prefer to stick to pam as in that case it can fall back to my local passwd file, where I have defined a password for root, so in case the krb server (or the network) fails at least I can log in!
Current situation after all the hacking: $ ldapwhoami -x -D 'uid=wouter,ou=people,dc=squirrel' -W -h acorn.squirrel Enter LDAP Password: ldap_bind: Invalid credentials (49) when entering my Kerberos password; it accepts my credentials when I enter the LDAP stored password (a different password).
That requires pass-through authentication.
I see. Well with the above instructions nothing seems to have changed. I have restarted saslauthd and slapd after making the changes, and when now accessing the ldap addressbook using Evolution, I still have to use the ldap stored password, not the krb password.
Wouter.
Then I just did:
wouter@acorn:~$ ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) wouter@acorn:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000_5lYS4w Default principal: wouter@SQUIRREL
Valid starting Expires Service principal 09/08/10 22:42:07 09/09/10 08:42:07 krbtgt/SQUIRREL@SQUIRREL renew until 09/09/10 22:42:07 09/08/10 22:46:39 09/09/10 08:42:07 ldap/acorn.squirrel@SQUIRREL renew until 09/09/10 22:42:07
Kerberos 4 ticket cache: /tmp/tkt1000 klist: You have no tickets cached =======================
Do you have ldap/acorn.squirrel@SQUIRREL in /etc/krb5.keytab, on the server? Is it readable by the slapd user?
Wouter van Marle wouter@squirrel-systems.com writes:
Hi group,
I have been fighting the whole day already for something that I think is quite simple but I just can't get it to work: have slapd authenticate users against kerberos. Following many tutorials, trying many things, I give up on that and ask for your help.
System: Debian Lenny.
Situation:
- workstation logins over the network authenticate against kerberos
- credentials from LDAP
- postfix has its alias database etc in LDAP, as are the groups and
userIDs and everything - helps keeping uids the same on the workstations. Essential for NFS.
- anything using pam will be authenticated against kerberos, including
imap, postfix, etc.
Except LDAP. Then slapd authenticates by itself against the password stored there. And that's not what I want. There should be no passwords in LDAP any more, everything against kerberos. Then at least when a user changes their kerberos password, the same password is used everywhere. I just can't get this to work for some reason. I have followed many tutorials, so many that I forgot what I did, and it still doesn't work.
Slapd should use pam to authenticate, or directly talk to the kerberos server, whatever.
saslauthd has the gssapi module installed.
[...]
Why did you design such a complicated setup? postfix supports sasl mechanism GSSAPI, openldap supports sasl mechanism GSSAPI, cyrus-imap supports sasl mechanism GSSAPI, ssh supports GSSAPI, pam login should use unix2 which supports GSSAPI.
saslauthd is not required, nor is a userpassword attribute value required in DIT. Just setup a proper kerberos V5 environment, create service principals, host pricipals and user principals, and configure clients to use either native krb5 implementation or GSSAPI mechanism.
-Dieter
openldap-technical@openldap.org
-
Dan White -
Dieter Kluenter -
Wouter van Marle