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 ipa-dnskeysyncd/server.example.com $ 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: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
