Okay, I believe that this is the problem:

On 21.12.2016 15:53, Brian J. Murrell wrote:
> [21/Dec/2016:09:39:12.003351818 -0500] conn=77028 fd=107 slot=107 connection 
> from local to /var/run/slapd-EXAMPLE.COM.socket
> [21/Dec/2016:09:39:12.064476101 -0500] conn=77028 op=0 BIND dn="" method=sasl 
> version=3 mech=GSSAPI
> [21/Dec/2016:09:39:12.067486416 -0500] conn=77028 op=0 RESULT err=49 tag=97 
> nentries=0 etime=0 - SASL(-1): generic failure: GSSAPI Error: Unspecified GSS 
> failure.  Minor code may provide more information (Permission denied)
> [21/Dec/2016:09:39:12.192506861 -0500] conn=77028 op=1 UNBIND
> [21/Dec/2016:09:39:12.192549740 -0500] conn=77028 op=1 fd=107 closed - U1

I have no idea why it is returning Permission denied.

Is it reproducible when you run this?
$ kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
$ ldapsearch -Y GSSAPI -H /var/run/slapd-EXAMPLE.COM.socket

We need to find out why it is blowing up on GSSAPI negotiation.

Wild guess is that /etc/dirsrv/ds.keytab could have wrong permissions. It
should have
-rw-------. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0

If you manage to reproduce it, you can attach strace to the running dirsrv
process and see what call is failing (if it is a system call)...

I'm CCing LDAP server gurus to see if it rings a bell.

Petr^2 Spacek

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to