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
ipa-dnskeysyncd/server.example.com
$ 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
/etc/dirsrv/ds.keytab
If you manage to reproduce it, you can attach strace to the running
dirsrv
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.
Cheers,
b.
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?:
KRB5_CCNAME=/tmp/krb5cc_389
KRB5_KTNAME=/etc/dirsrv/ds.keytab
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:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
