On 12/21/2016 07:22 PM, Brian J. Murrell wrote:
On Wed, 2016-12-21 at 17:50 +0100, Petr Spacek wrote:
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

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ipa-dnskeysyncd/server.example....@example.com

Valid starting     Expires            Service principal
21/12/16 13:05:16  22/12/16 13:02:12  ldap/server.example....@example.com
21/12/16 13:02:12  22/12/16 13:02:12  krbtgt/example....@example.com

# ldapsearch -Y GSSAPI -H ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE.COM.socket
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)

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

# ls -lZ /etc/dirsrv/ds.keytab
-rw-------. dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 

If you manage to reproduce it, you can attach strace to the running

By that I assume you mean the ns-slapd.

The strace (minus poll/select/futex noise) is attached.

process and see what call is failing (if it is a system call)...

Perhaps this one:

[pid 13449] open("/etc/krb5.keytab", O_RDONLY) = -1 EACCES (Permission denied)

# ls -lZ /etc/krb5.keytab
-rw-------. root root system_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab

But looking into the backup of this system, even a week and a month
ago, that file had the same permissions/ownership.  And changing it to
644 temporarily doesn't fix the "ldap_sasl_interactive_bind_s: Invalid
credentials (49)" from ldapsearch.


Hi Brian,

DS should use /etc/sysconfig/dirsrv to set its KRB5_KTNAME env variable to /etc/dirsrv/ds.keytab. I guess that it cannot get this info from the file, thus it falls back to Kerberos library default which is /etc/krb5.keytab. That obviosuly fails because it is accesible only to root and contains keys only to host/, nfs/, and cifs/ (if you have Samba) principals.

Can you please verify that /etc/sysconfig/dirsrv file exists and that it contains the following lines?:


If not, please add this line to the file, restart dirsrv and try IPA commands again.

Martin^3 Babinsky

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

Reply via email to