Re: Server ldap/[email protected] not found in Kerberos database
Dan White <[email protected]>
| Newsgroups | gmane.comp.security.cyrus.sasl |
|---|---|
| Message-ID | <[email protected]> |
On 04/14/17Â 17:40Â +0200, Jaap Winius wrote: >Quoting Jaap Winius <[email protected]>: > >> slapd[1668]: GSSAPI Error: Unspecified GSS failure. \ >> Minor code may provide more information \ >> (Server ldap/[email protected] 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/[email protected]. 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?