For the last two weeks I have been on a sojourn through the wonderful world of LDAP, Kerberos, and SASL, which has had me banging my head against the desk more often than not. Today I'm finally crying uncle and asking for some help.
We're running Centos 5.4, currently with OpenLDAP for user info and Kerberos for authentication, but we want to be able to use LDAP for authentication on a bunch of devices that can't use Kerberos natively. So I've been trying to get the passthrough auth working. So far, I think I've made a lot of progress, but I've run into a wall. Kerberos and LDAP are working in my testbed, and I can kinit and do an ldapwhoami no problem. testsaslauthd also gives me a success when I run it. However, when try to do a simple bind:
[chas@ldapsandbox]$ ldapwhoami -x -D 'uid=chas,ou=People,dc=test,dc=domain' -W Enter LDAP Password: ldap_bind: Invalid credentials (49) [chas@ldapsandbox]$
syslog shows this:
2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: conn=6 fd=15 ACCEPT from IP=10.17.136.50:55923 (IP=0.0.0.0:389) 2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: conn=6 op=0 BIND dn="uid=chas,ou=People,dc=test,dc=domain" method=128 2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: SASL [conn=6] Failure: cannot connect to saslauthd server: No such file or directory 2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: conn=6 op=0 RESULT tag=97 err=49 text= 2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: conn=6 fd=15 closed (connection lost)
Meanwhile, the saslauthd I'm running with /usr/sbin/saslauthd -a kerberos5 -d doesn't even show a connection or anything to the console. Any idea why it can't connect to the saslauthd server?
Here's my OpenLDAP slapd.conf:
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
TLSCACertificateFile /etc/openldap/cacert.crt TLSCertificateFile /etc/openldap/ldapsandbox.crt TLSCertificateKeyFile /etc/openldap/ldapsandbox.key
authz-regexp uid=([^/]*),cn=gssapi,cn=auth uid= $1,ou=People,dc=test,dc=domain
access to * by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write by * read
database bdb suffix "dc=test,dc=domain"
directory /var/lib/ldap
index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub
And here's my /etc/sasl2/slapd.conf:
pwcheck_method: saslauthd saslauthd_path: /var/run/sasl2/mux
Any ideas?
On 01/25/12 12:14 -0800, Chastity Blackwell wrote:
For the last two weeks I have been on a sojourn through the wonderful world of LDAP, Kerberos, and SASL, which has had me banging my head against the desk more often than not. Today I'm finally crying uncle and asking for some help.
[chas@ldapsandbox]$ ldapwhoami -x -D 'uid=chas,ou=People,dc=test,dc=domain' -W Enter LDAP Password: ldap_bind: Invalid credentials (49) [chas@ldapsandbox]$
syslog shows this:
2012-01-25T12:04:55-08:00 ldapsandbox slapd[14363]: SASL [conn=6] Failure: cannot connect to saslauthd server: No such file or directory
Meanwhile, the saslauthd I'm running with /usr/sbin/saslauthd -a kerberos5 -d doesn't even show a connection or anything to the console. Any idea why it can't connect to the saslauthd server?
And here's my /etc/sasl2/slapd.conf:
pwcheck_method: saslauthd saslauthd_path: /var/run/sasl2/mux
Verify (with netstat) that saslauthd is listening on '/var/run/sasl2/mux', and verify the user/group that slapd is running under has permissions to access /var/run/sasl2.
On Wed, 2012-01-25 at 17:16 -0500, Dan White wrote:
Verify (with netstat) that saslauthd is listening on '/var/run/sasl2/mux', and verify the user/group that slapd is running under has permissions to access /var/run/sasl2.
The permissions on /var/run/saslauthd look fine to me -- when I run netstat -a I see:
unix 2 [ ACC ] STREAM LISTENING 2435670 /var/run/saslauthd/mux
Which leads me to believe that's fine too. But for some reason LDAP isn't connecting to it. Am I missing something from my slapd.conf (for either OpenLDAP or SASL)?
On 01/26/12 11:43 -0800, Chastity Blackwell wrote:
On Wed, 2012-01-25 at 17:16 -0500, Dan White wrote:
Verify (with netstat) that saslauthd is listening on '/var/run/sasl2/mux', and verify the user/group that slapd is running under has permissions to access /var/run/sasl2.
The permissions on /var/run/saslauthd look fine to me -- when I run netstat -a I see:
unix 2 [ ACC ] STREAM LISTENING 2435670 /var/run/saslauthd/mux
That indicates a mistake in your /etc/sasl2/slapd.conf, which should have:
saslauthd_path: /var/run/saslauthd/mux
not /var/run/sasl2/mux
Which leads me to believe that's fine too. But for some reason LDAP isn't connecting to it. Am I missing something from my slapd.conf (for either OpenLDAP or SASL)?
On Thu, 2012-01-26 at 15:23 -0500, Dan White wrote:
That indicates a mistake in your /etc/sasl2/slapd.conf, which should have:
saslauthd_path: /var/run/saslauthd/mux
not /var/run/sasl2/mux
Well, now I just feel like an idiot. :) That did move things along a bit, though now I'm getting this error:
2012-01-26T13:48:28-08:00 ldapsandbox10-1-qa-sjc saslauthd[15889]: do_auth : auth failure: [user=chas@test.com] [service=ldap] [realm=test.com] [mech=kerberos5] [reason=saslauthd internal error]
I'm guessing the problem here is that the realm should match my Kerberos realm, which is called "KRBTEST", not test.com -- is this something that needs to be fixed with an authz-regexp?
On 26.01.2012 22:53, Chastity Blackwell wrote:
On Thu, 2012-01-26 at 15:23 -0500, Dan White wrote:
That indicates a mistake in your /etc/sasl2/slapd.conf, which should have:
saslauthd_path: /var/run/saslauthd/mux
not /var/run/sasl2/mux
Well, now I just feel like an idiot. :) That did move things along a bit, though now I'm getting this error:
2012-01-26T13:48:28-08:00 ldapsandbox10-1-qa-sjc saslauthd[15889]: do_auth : auth failure: [user=chas@test.com] [service=ldap] [realm=test.com] [mech=kerberos5] [reason=saslauthd internal error]
I'm guessing the problem here is that the realm should match my Kerberos realm, which is called "KRBTEST", not test.com -- is this something that needs to be fixed with an authz-regexp?
No, authz-regexp is to map a sasl dn to a real user account in your ldap directory.
But your user is chas@test.com with a realm named test.com, your userPassword should be {SASL}chas@KRBTEST and also exists as a principal on your kerberos db ;)
Raffael Sahli wrote:
On 26.01.2012 22:53, Chastity Blackwell wrote:
On Thu, 2012-01-26 at 15:23 -0500, Dan White wrote:
That indicates a mistake in your /etc/sasl2/slapd.conf, which should have:
saslauthd_path: /var/run/saslauthd/mux
not /var/run/sasl2/mux
Well, now I just feel like an idiot. :) That did move things along a bit, though now I'm getting this error:
2012-01-26T13:48:28-08:00 ldapsandbox10-1-qa-sjc saslauthd[15889]: do_auth : auth failure: [user=chas@test.com] [service=ldap] [realm=test.com] [mech=kerberos5] [reason=saslauthd internal error]
I'm guessing the problem here is that the realm should match my Kerberos realm, which is called "KRBTEST", not test.com -- is this something that needs to be fixed with an authz-regexp?
No, authz-regexp is to map a sasl dn to a real user account in your ldap directory.
But your user is chas@test.com with a realm named test.com, your userPassword should be {SASL}chas@KRBTEST
What the heck are you talking about? If the username is chas@test.com then that is what goes in the password:
userpassword: {SASL}chas@test.com
If the realm is actually KRBTEST then the username should be chas@KRBTEST.
and also exists as a principal on your kerberos db ;)
On Thu, 2012-01-26 at 17:38 -0500, Howard Chu wrote:
Raffael Sahli wrote:
No, authz-regexp is to map a sasl dn to a real user account in your ldap directory.
But your user is chas@test.com with a realm named test.com, your userPassword should be {SASL}chas@KRBTEST
What the heck are you talking about? If the username is chas@test.com then that is what goes in the password:
userpassword: {SASL}chas@test.com
If the realm is actually KRBTEST then the username should be chas@KRBTEST.
and also exists as a principal on your kerberos db ;)
Okay, I'm a little confused here now. So here's what I have in krb5.conf:
[libdefaults] default_realm = KRBTEST dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes
[realms] AKTEST = { kdc = ldapsandbox.test.com:88 admin_server = ldapsandbox.test.com:749 default_domain = test.com }
[domain_realm] .agkn.net = KRBTEST agkn.net = KRBTEST
And when I look at my principals in Kerberos, this is what I have:
kadmin: listprincs K/M@KRBTEST chas/admin@KRBTEST chas@KRBTEST host/ldapsandbox.test.com@KRBTEST kadmin/admin@AKTEST kadmin/changepw@AKTEST kadmin/history@AKTEST kadmin/ldapsandbox.test.com@KRBTEST krbtgt/KRBTEST@KRBTEST ldap/ldapsandbox.test.com@KRBTEST root/admin@KRBTEST
So what should the userPassword attribute be set to? I assumed it should be {SASL}chas@KRBTEST -- is that correct? I just want to make sure I'm on the right track there.
Chastity Blackwell wrote:
On Thu, 2012-01-26 at 17:38 -0500, Howard Chu wrote:
Raffael Sahli wrote:
No, authz-regexp is to map a sasl dn to a real user account in your ldap directory.
But your user is chas@test.com with a realm named test.com, your userPassword should be {SASL}chas@KRBTEST
What the heck are you talking about? If the username is chas@test.com then that is what goes in the password:
userpassword: {SASL}chas@test.comIf the realm is actually KRBTEST then the username should be chas@KRBTEST.
and also exists as a principal on your kerberos db ;)
Okay, I'm a little confused here now.
Clearly.
So here's what I have in krb5.conf:
Does kinit work for your chas@KRBTEST user? Judging from what you've pasted here, I don't think it should. Get your basic Kerberos installation working first. Take things one step at a time.
[libdefaults] default_realm = KRBTEST dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes
[realms] AKTEST = { kdc = ldapsandbox.test.com:88 admin_server = ldapsandbox.test.com:749 default_domain = test.com }
[domain_realm] .agkn.net = KRBTEST agkn.net = KRBTEST
And when I look at my principals in Kerberos, this is what I have:
kadmin: listprincs K/M@KRBTEST chas/admin@KRBTEST chas@KRBTEST host/ldapsandbox.test.com@KRBTEST kadmin/admin@AKTEST kadmin/changepw@AKTEST kadmin/history@AKTEST kadmin/ldapsandbox.test.com@KRBTEST krbtgt/KRBTEST@KRBTEST ldap/ldapsandbox.test.com@KRBTEST root/admin@KRBTEST
So what should the userPassword attribute be set to? I assumed it should be {SASL}chas@KRBTEST -- is that correct? I just want to make sure I'm on the right track there.
On Thu, 2012-01-26 at 18:40 -0500, Howard Chu wrote:
Does kinit work for your chas@KRBTEST user? Judging from what you've pasted here, I don't think it should. Get your basic Kerberos installation working first. Take things one step at a time.
It does:
[chas@ldapsandbox log]$ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 195) [chas@ldapsandbox log]$ kinit chas Password for chas@KRBTEST: [chas@ldapsandbox log]$ ldapwhoami SASL/GSSAPI authentication started SASL username: chas@KRBTEST SASL SSF: 56 SASL installing layers dn:uid=chas,ou=people,dc=test,dc=com Result: Success (0) [chas@ldapsandbox log]$
As I said, I think Kerberos and LDAP are all working on their own...it's the combination of the two doing the SASL passthrough that is confounding me.
Chastity Blackwell wrote:
On Thu, 2012-01-26 at 18:40 -0500, Howard Chu wrote:
Does kinit work for your chas@KRBTEST user? Judging from what you've pasted here, I don't think it should. Get your basic Kerberos installation working first. Take things one step at a time.
It does:
[chas@ldapsandbox log]$ ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 195) [chas@ldapsandbox log]$ kinit chas Password for chas@KRBTEST: [chas@ldapsandbox log]$ ldapwhoami SASL/GSSAPI authentication started SASL username: chas@KRBTEST SASL SSF: 56 SASL installing layers dn:uid=chas,ou=people,dc=test,dc=com Result: Success (0) [chas@ldapsandbox log]$
As I said, I think Kerberos and LDAP are all working on their own...it's the combination of the two doing the SASL passthrough that is confounding me.
Seems like it's working for the wrong reasons, then. Your krb5.conf:
[libdefaults] default_realm = KRBTEST dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes
[realms] AKTEST = { kdc = ldapsandbox.test.com:88 admin_server = ldapsandbox.test.com:749 default_domain = test.com }
[domain_realm] .agkn.net = KRBTEST agkn.net = KRBTEST
You defined a kdc for an "AKTEST" realm; you don't actually have any kdc defined for the "KRBTEST" realm so kinit should be failing.
On Thu, 2012-01-26 at 19:27 -0500, Howard Chu wrote:
Seems like it's working for the wrong reasons, then. Your krb5.conf:
[realms] AKTEST = { kdc = ldapsandbox.test.com:88 admin_server = ldapsandbox.test.com:749 default_domain = test.com
You defined a kdc for an "AKTEST" realm; you don't actually have any kdc defined for the "KRBTEST" realm so kinit should be failing.
*sigh* Yeah, that's another sanitization failure there -- that should be KRBTEST, not AKTEST. So it is defined. Sorry about that.
On 01/25/12 12:14 -0800, Chastity Blackwell wrote:
I've made a lot of progress, but I've run into a wall. Kerberos and LDAP are working in my testbed, and I can kinit and do an ldapwhoami no problem. testsaslauthd also gives me a success when I run it. However,
What does your testsaslauthd command look like? Are you passing a '-u user@example.com', or a '-r example.com', or both?
What is your default kerberos realm (/etc/krb5.conf), if any, on the box running slapd and saslauthd?
On 01/26/12 13:53 -0800, Chastity Blackwell wrote:
On Thu, 2012-01-26 at 15:23 -0500, Dan White wrote:
That indicates a mistake in your /etc/sasl2/slapd.conf, which should have:
saslauthd_path: /var/run/saslauthd/mux
not /var/run/sasl2/mux
Well, now I just feel like an idiot. :) That did move things along a bit, though now I'm getting this error:
2012-01-26T13:48:28-08:00 ldapsandbox10-1-qa-sjc saslauthd[15889]: do_auth : auth failure: [user=chas@test.com] [service=ldap] [realm=test.com] [mech=kerberos5] [reason=saslauthd internal error]
You might get more details from saslauthd -d.
Do your kerberos logs provide anything useful?
I'm guessing the problem here is that the realm should match my Kerberos realm, which is called "KRBTEST", not test.com -- is this something that needs to be fixed with an authz-regexp?
Where is test.com coming from? your userPassword entry?
On Thu, 2012-01-26 at 18:17 -0500, Dan White wrote:
What does your testsaslauthd command look like? Are you passing a '-u user@example.com', or a '-r example.com', or both?
[chas@ldapsandbox ~]$ /usr/sbin/testsaslauthd -u chas -p test -s ldap 0: OK "Success."
What is your default kerberos realm (/etc/krb5.conf), if any, on the box running slapd and saslauthd?
default_realm = KRBTEST as stated in my other email.
You might get more details from saslauthd -d.
Do your kerberos logs provide anything useful?
Unfortunately, either of these really provides much more than what I had already posted.
Where is test.com coming from? your userPassword entry?
That I'm not sure about -- I assumed it was coming from the LDAP domains.
On 01/26/12 15:11 -0800, Chastity Blackwell wrote:
On Thu, 2012-01-26 at 17:38 -0500, Howard Chu wrote: So what should the userPassword attribute be set to? I assumed it should be {SASL}chas@KRBTEST -- is that correct? I just want to make sure I'm on the right track there.
Try:
{SASL}chas
On 01/26/12 16:19 -0800, Chastity Blackwell wrote:
On Thu, 2012-01-26 at 18:17 -0500, Dan White wrote:
What does your testsaslauthd command look like? Are you passing a '-u user@example.com', or a '-r example.com', or both?
[chas@ldapsandbox ~]$ /usr/sbin/testsaslauthd -u chas -p test -s ldap 0: OK "Success."
What is your default kerberos realm (/etc/krb5.conf), if any, on the box running slapd and saslauthd?
default_realm = KRBTEST as stated in my other email.
You might get more details from saslauthd -d.
Do your kerberos logs provide anything useful?
Unfortunately, either of these really provides much more than what I had already posted.
Where is test.com coming from? your userPassword entry?
That I'm not sure about -- I assumed it was coming from the LDAP domains.
On Fri, 2012-01-27 at 10:30 -0500, Dan White wrote:
On 01/26/12 15:11 -0800, Chastity Blackwell wrote:
On Thu, 2012-01-26 at 17:38 -0500, Howard Chu wrote: So what should the userPassword attribute be set to? I assumed it should be {SASL}chas@KRBTEST -- is that correct? I just want to make sure I'm on the right track there.
Try:
{SASL}chas
Huh...well, what do you know, that works. Why is that though? I thought you had to specify a realm for it to work?
On 01/27/12 10:43 -0800, Chastity Blackwell wrote:
Huh...well, what do you know, that works. Why is that though? I thought you had to specify a realm for it to work?
Whether or not you use a realm is up to you. If you have multiple kerberos realms, then you're going to need to specify one.
However, the reason this works is that:
[chas@ldapsandbox ~]$ /usr/sbin/testsaslauthd -u chas -p test -s ldap 0: OK "Success."
is simply passing a username to saslauthd, with no realm or domain. The kerberos backend, via your kerberos libraries, is using the default realm to authenticate you.
To further trouble shoot why '{SASL}user@realm' does not work, you should first verify that it works with testsaslauthd (-u chas@REALM), and if it doesn't, bring the problem over to the cyrus-sasl@lists.andrew.cmu.edu list.
On Fri, 2012-01-27 at 14:56 -0500, Dan White wrote:
On 01/27/12 10:43 -0800, Chastity Blackwell wrote:
Huh...well, what do you know, that works. Why is that though? I thought you had to specify a realm for it to work?
Whether or not you use a realm is up to you. If you have multiple kerberos realms, then you're going to need to specify one.
However, the reason this works is that:
[chas@ldapsandbox ~]$ /usr/sbin/testsaslauthd -u chas -p test -s ldap 0: OK "Success."
is simply passing a username to saslauthd, with no realm or domain. The kerberos backend, via your kerberos libraries, is using the default realm to authenticate you.
To further trouble shoot why '{SASL}user@realm' does not work, you should first verify that it works with testsaslauthd (-u chas@REALM), and if it doesn't, bring the problem over to the cyrus-sasl@lists.andrew.cmu.edu list.
All right, that makes a lot of sense. I think actually I must have had something bad in the LDAP entry for me; replacing it with {SASL}chas@KRBTEST works as intended now. So, it looks like most of my problem was a lot of little errors that were tripping me up. I feel a bit stupid, but on the other hand, it's good to know I was at least on the right track. Thanks for all your help!
openldap-technical@openldap.org
-
Chastity Blackwell -
Dan White -
Howard Chu -
Raffael Sahli