On 04/14/17 17:40 +0200, Jaap Winius wrote:
Quoting Jaap Winius <jwinius@xxxxxxx>:
slapd[1668]: GSSAPI Error: Unspecified GSS failure. \
Minor code may provide more information \
(Server ldap/localhost@xxxxxxxxxxx not found in Kerberos database)
Maybe this is really a slapd issue, particularly if it's job here is
to interpret the value of the KRB5_KTNAME variable and then pass that
(or perhaps even the name of the Kerberos principal) on to the
SASL/GSSAPI functions. Well, either that or the latter aren't
processing the name of the file or principal properly.
I don't believe this is a ticket cache problem. I'm guessing slapd/sasl has
access to your cache, just not one which contains
ldap/localhost@xxxxxxxxxxx. I assume that the wrong service principal is
being requested, which you should see in your kdc logs corresponding with
an entry that it's not found in the database.
slapd should pass the serverFQDN in it's call to sasl_client_new, which
should ultimately result in a request for ldap/serverFQDN towards the kdc.
If you're not seeing anything useful in auth.debug, try increasing slapd
logging on the consumer.
Can you connect to the provider, from the consumer, over GSSAPI using ldap
client tools?
