[Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Martin Babinsky]

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.com at EXAMPLE.COM
>
> Valid starting     Expires            Service principal
> 21/12/16 13:05:16  22/12/16 13:02:12  ldap/server.example.com at EXAMPLE.COM
> 21/12/16 13:02:12  22/12/16 13:02:12  krbtgt/EXAMPLE.COM at 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