solves the issue.
Now, when I look back for what caused me this hiccup, this has come to
my attention:
- in slapd-config(5):
olcSaslHost: <fqdn>
Used to specify the fully qualified domain name used for SASL processing.
... the description looks somewhat ambiguous to me. It would be less
confusion, if it were "Host running a LDAP server" or similar. Or
perhaps just warning of a possible pitfall - my five cents :).
And, of course, the Ubuntu tutorial page, that was plain whong, saying:
"#The FQDN of the Kerberos KDC.
olcSaslHost: kerberos.example.com"
at
But again, many thanks for a quick and helpful response!
Toomas
On Tue, Jan 17, 2012 at 10:16 PM, Dan White <dwhite(a)olp.net> wrote:
On 01/17/12 21:45 +0200, Toomas Vendelin wrote:
>
> The goal: to make an OpenLDAP server to authenticate using Kerberos V via
> GSSAPI
>
> Setup: several virtual machines running on freshly installed/updated
> Debian Squeeze
>
> A master KDC server
>
>
kdc.example.com
>
> A LDAP server, running OpenLDAP
>
>
ldap.example.com
>
> The problem:
>
> tom@ldap:~$ ldapsearch -b 'dc=example,dc=com'
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error
> (80)
> additional info: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure. Minor code may provide more information (Key
> table entry not found)
>
> One might suggest to add that keytab entry, but:
>
> ktutil: rkt /etc/ldap/ldap.keytab
> ktutil: list
> slot KVNO Principal
> ---- ----
> ---------------------------------------------------------------------
> 1 2 ldap/ldap.example.com(a)EXAMPLE.COM
> 2 2 ldap/ldap.example.com(a)EXAMPLE.COM
> 3 2 ldap/ldap.example.com(a)EXAMPLE.COM
> 4 2 ldap/ldap.example.com(a)EXAMPLE.COM
>
> So, the entry as suggested by the OpenLDAP manual is there allright.
> Deleting and re-creating both service principal and the keytab on
>
ldap.example.com didn't help, I get the same error. And before I make
> the keytab file readable by openldap, I get "Permission denied" error
> instead of the one in the subject. Which implies that the right keytab
> file is being accessed, as set in /etc/default/slapd.
>
> I have my doubts about the following part of slapd config:
>
> root@ldap:~# cat /etc/ldap/slapd.d/cn\=config.ldif | grep -v "^#"
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcArgsFile: /var/run/slapd/slapd.args
> olcLogLevel: 256
> olcPidFile: /var/run/slapd/slapd.pid
> olcToolThreads: 1
> structuralObjectClass: olcGlobal
> entryUUID: d6737f5c-d321-1030-9dbe-27d2a7751e11
> olcSaslHost:
kdc.example.com
I think you'll find that libsasl2 is searching for
ldap/kdc.example.com in
your credentials cache. Try changing this to:
olcSaslHost:
ldap.example.com
> olcSaslRealm:
EXAMPLE.COM
> olcSaslSecProps: noplain,noactive,noanonymous,minssf=56
> olcAuthzRegexp: {0}"uid=([^/]*),cn=EXAMPLE.COM,cn=GSSAPI,cn=auth"
> "uid=$1,ou=People,dc=example,dc=com"
> olcAuthzRegexp:
> {1}"uid=host/([^/]*).example.com,cn=example.com,cn=gssapi,cn=auth"
> "cn=$1,ou=hosts,dc=example,dc=com"
>
> A HOWTO at
>
https://help.ubuntu.com/community/OpenLDAPServer#Kerberos_Authentication
> mentiones:
>
> Also, it is frequently necessary to map the Distinguished Name
> (DN) of an authorized Kerberos client to an existing entry in the DIT.
>
> I fail to understand where in the tree this should be defined, what
> schema should be used, etc. After hours of googling, it's official:
> I'm stuck! Please, help.
When I was learning how to map entries, I found ldapwhoami to be very
useful. As an example, you might see this *before* creating any authz-regex
maps:
$ ldapwhoami -Y gssapi -H
ldap://ldap.example.com
SASL/GSSAPI authentication started
SASL username: ...
SASL SSF: 56
SASL data security layer installed.
dn:uid=jsmith@EXAMPLE.COM,cn=GSSAPI,cn=auth
Then, you can create your maps piecemeal wise until your identity becomes
what you really what it to be, e.g.:
dn:uid=jsmith,ou=people,dc=example,dc=com
See chapter 15 of the openldap administrator's guide for examples, and then
see the manpage for slapd-config for details on how to create the
corresponding olcAuthzRegexp entries.
--
Dan White