Hi all,
I'm new to this so forgive me for any stupid questions/assumptions or if I miss anything out. :)
I'm trying to set up a Krb5 authenticated OpenLDAP server, mainly for educational purposes, so I've been trying to merge together various guides on the internet to a working setup. Unfortunately, I'm now getting the following error:
cameron@gimli:~$ ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2)
No additional information or anything. ldapsearch -x works as expected.
My setup is currently all on one system: Ubuntu Server 8.10, slapd/ldap-utils 2.4.11, MIT krb5-kdc 1.6.
This is my config file (slapd.d format):
root@gimli:~# cat /etc/ldap/slapd.d/cn=config.ldif dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 olcTLSCACertificateFile: /etc/ldap/ssl/server.pem olcTLSCertificateFile: /etc/ldap/ssl/server.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/server.pem olcTLSVerifyClient: allow olcSaslRealm: LOCAL olcSaslHost: ldap.local structuralObjectClass: olcGlobal entryUUID: ccd3335c-5da4-102d-9155-ed2c61020a96 creatorsName: cn=config createTimestamp: 20081213210021Z entryCSN: 20081213210021.939004Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20081213210021Z
I'm using ldaps://ldap.local as the service URL, and that all seems to be working okay as indicated by the simple authentication. ldap.local has an entry in the DNS server.
Any ideas on where I can go from here?
Thanks,
Cameron Harris
Cameron Harris wrote:
I'm trying to set up a Krb5 authenticated OpenLDAP server, mainly for educational purposes, so I've been trying to merge together various guides on the internet to a working setup. Unfortunately, I'm now getting the following error:
cameron@gimli:~$ ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2)
Did you obtain a TGT before? What's the output of command klist?
Ciao, Michael.
On Sun, Dec 14, 2008 at 11:31 AM, Michael Ströder michael@stroeder.comwrote:
Did you obtain a TGT before? What's the output of command klist?
Ciao, Michael.
I did obtain a TGT with kinit:
cameron@gimli:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: cameron@LOCAL
Valid starting Expires Service principal 12/14/08 00:40:14 12/14/08 10:40:14 krbtgt/LOCAL@LOCAL renew until 12/15/08 00:40:12
There is an entry for ldap/ldap.local@LOCAL in /etc/krb5.keytab, and openldap has permission to read it, but it isn't giving me a ticket when I connect as various articles on the internet implied it should. Additionally, strace-ing ldap didn't show it opening or reading the keytab (if it should), nor doing anything else SASL related other than loading the libraries.
Thanks, Cameron Harris
Cameron Harris wrote:
On Sun, Dec 14, 2008 at 11:31 AM, Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote:
Did you obtain a TGT before? What's the output of command klist?
I did obtain a TGT with kinit:
Hmm, I vaguely remember having to use "kinit -A" to avoid the local error.
Ciao, Michael.
On Sun, Dec 14, 2008 at 3:34 PM, Michael Ströder michael@stroeder.comwrote:
Cameron Harris wrote:
On Sun, Dec 14, 2008 at 11:31 AM, Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote:
Did you obtain a TGT before? What's the output of command klist?
I did obtain a TGT with kinit:
Hmm, I vaguely remember having to use "kinit -A" to avoid the local error.
Ciao, Michael.
Didn't work, unfortunately. Same error. :(
Cameron Harris
Cameron Harris wrote:
On Sun, Dec 14, 2008 at 3:34 PM, Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote:
Cameron Harris wrote: > On Sun, Dec 14, 2008 at 11:31 AM, Michael Ströder <michael@stroeder.com <mailto:michael@stroeder.com> > <mailto:michael@stroeder.com <mailto:michael@stroeder.com>>> wrote: > > > Did you obtain a TGT before? What's the output of command klist? > > I did obtain a TGT with kinit: Hmm, I vaguely remember having to use "kinit -A" to avoid the local error. Ciao, Michael.
Didn't work, unfortunately. Same error. :(
Cameron Harris
Cameron,
Here are some sanity checks to try:
Query your LDAP server to make sure that it is offering GSSAPI:
ldapsearch -H ldap://ldap.example.net -x -b "" -s base -LLL supportedSASLMechanisms
dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: NTLM supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: OTP supportedSASLMechanisms: CRAM-MD5
If GSSAPI is not listed, verify configuration on the server. Check that the GSSAPI SASL mechanism is installed:
~# pluginviewer | grep -i gssapi pluginviewer: SASL Other: OTP: auxprop backend can't store properties LOGIN DIGEST-MD5 NTLM GSSAPI OTP PLAIN ANONYMOUS CRAM-MD5 EXTERNAL Plugin "gssapiv2" [loaded], API version: 4 SASL mechanism: GSSAPI, best SSF: 56, supports setpass: no LOGIN DIGEST-MD5 NTLM GSSAPI OTP PLAIN ANONYMOUS CRAM-MD5 EXTERNAL Plugin "gssapiv2" [loaded], API version: 4 SASL mechanism: GSSAPI, best SSF: 56
Verify configuration of your slapd.conf SASL config:
~# cat /usr/lib/sasl2/slapd.conf keytab: /etc/krb5.keytab-ldap pwcheck_method: auxprop saslauthd auxprop_plugin: slapd
(The location of your SASL slapd.conf config is dependant on how your SASL libraries are compiled). Your config doesn't have to match mine. You might want to explicitly set the location of your keytab, and verify that you do not have a restricive 'mech_list'. *If* you have a mech_list defined, make sure it includes GSSAPI.
If your server config looks Ok, verify that you have the GSSAPI mechanism installed correctly on your client system with the (Cyrus SASL) pluginviewer command.
Verify that you are retrieving the ldap/ldap.local@LOCAL service ticket from the KDC on your client (with klist). If not, you may not not be specifying a fully qualified domain name in your URI statement within your ldap.conf config. Make sure your URI statement is a FQDN (and not an IP address or ldapi:///) or that you're specifying one within the ldapsearch statement.
Most likely the error you're receiving can be traced down to a Cyrus SASL or Kerberos misconfiguration. Check your syslog and auth.log on the server and client for possible additional errors.
- Dan
openldap-software@openldap.org