samba - Jun 2016 - ldapsearch & GSSAPI => Server not found in Kerberos database

Hi all,

I've got on AD DC using Samba 4.4.3 on Centos7 which accept Kerberos
connections (kinit is working), which accept ldapsearch with credentials
but which refuse ldapsearch with GSSAPI.

The issue does not seem to be coming from the client as I discovered this
issue writing a script to test all 22 DC, and all 21 others DC are working
well from that client.

The error:
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (Server
not found in Kerberos database)

I did reinstall the whole server ('cause I'm lazy, hoping the issue
disappear by itself) but the issue was the same, i did reinstall it again
(a script do that, I'm really lazy) but after demoting it from FSMO owner
with --remove-other-dead-server, same issue.

All DCs have same configuration file, as it'sa  script which manage
installation I expect they are all identical and so I'm totally puzzled
facing this issue. If anyone has some idea, some leads, I take it : )

More information, making me more crazy:
- ldapsearch without SASL is working from any host:
 ldapsearch  -D 'CN=user-ldapmodify,OU=OurUsers,DC=ad,DC=domain,dc=tld'
-w
Passw0rd -x -ZZ -b 'dc=ad,DC=domain,dc=tld' -h dc106
sAMAccountName=administrator dn

- ldapsearch with SASL is not working (Kerberos ticket existing following a
working kinit) from any host but it works when launched from the
non-working-server
kinit -k -t administrator.keytab administrator
ldapsearch -Y GSSAPI -b 'dc=ad,dc=domain,dc=tld' -h dc106
sAMAccountName=administrator dn -d256

- kinit works from any tested host (exporting KRB5_CONFIG variable to point
to a krb5.conf forcing usage of my non-working-server)
with config containing:
[libdefaults]
        default_realm = AD.DOMAIN.TLD

[realms]
        AD.DOMAIN.TLD = {
                kdc = 10.11.12.13
}



2016-06-07 15:29 GMT+02:00 mathias dufresne <infractory at gmail.com>:
> Hi all,
>
> I've got on AD DC using Samba 4.4.3 on Centos7 which accept Kerberos
> connections (kinit is working), which accept ldapsearch with credentials
> but which refuse ldapsearch with GSSAPI.
>
> The issue does not seem to be coming from the client as I discovered this
> issue writing a script to test all 22 DC, and all 21 others DC are working
> well from that client.
>
> The error:
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Local error (-2)
>         additional info: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (Server
> not found in Kerberos database)
>
> I did reinstall the whole server ('cause I'm lazy, hoping the issue
> disappear by itself) but the issue was the same, i did reinstall it again
> (a script do that, I'm really lazy) but after demoting it from FSMO
owner
> with --remove-other-dead-server, same issue.
>
> All DCs have same configuration file, as it'sa  script which manage
> installation I expect they are all identical and so I'm totally puzzled
> facing this issue. If anyone has some idea, some leads, I take it : )
>

Solved  : )

Reminder of the issue:
Every services (CIFS, Kerberos, LDAP, DNS, RPC) on one DC were working well
and ldapsearch using DN and password were also working.
The only thing which was not working was ldapsearch using GSSAPI
authentication with the following error:
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (Server
not found in Kerberos database)

This issue was happening only from one client, some Debian Jessie (8), it
wasn't happening on DC which all run Centos7.

The reason was simple: no reverse DNS configured for that DC.

The solution for us was to add this missing reverse DNS entry but it should
be possible to configure client to avoid using reverse DNS.

As for now I'm facing issue to delete reverse DNS entries (I'll describe
that in another mail as it's another topic) I can't perform test to make
it
work without that reverse DNS entry set up.

2016-06-07 17:50 GMT+02:00 mathias dufresne <infractory at gmail.com>:
> More information, making me more crazy:
> - ldapsearch without SASL is working from any host:
>  ldapsearch  -D
'CN=user-ldapmodify,OU=OurUsers,DC=ad,DC=domain,dc=tld' -w
> Passw0rd -x -ZZ -b 'dc=ad,DC=domain,dc=tld' -h dc106
> sAMAccountName=administrator dn
>
> - ldapsearch with SASL is not working (Kerberos ticket existing following
> a working kinit) from any host but it works when launched from the
> non-working-server
> kinit -k -t administrator.keytab administrator
> ldapsearch -Y GSSAPI -b 'dc=ad,dc=domain,dc=tld' -h dc106
> sAMAccountName=administrator dn -d256
>
> - kinit works from any tested host (exporting KRB5_CONFIG variable to
> point to a krb5.conf forcing usage of my non-working-server)
> with config containing:
> [libdefaults]
>         default_realm = AD.DOMAIN.TLD
>
> [realms]
>         AD.DOMAIN.TLD = {
>                 kdc = 10.11.12.13
> }
>
>
>
> 2016-06-07 15:29 GMT+02:00 mathias dufresne <infractory at
gmail.com>:
>
>> Hi all,
>>
>> I've got on AD DC using Samba 4.4.3 on Centos7 which accept
Kerberos
>> connections (kinit is working), which accept ldapsearch with
credentials
>> but which refuse ldapsearch with GSSAPI.
>>
>> The issue does not seem to be coming from the client as I discovered
this
>> issue writing a script to test all 22 DC, and all 21 others DC are
working
>> well from that client.
>>
>> The error:
>> SASL/GSSAPI authentication started
>> ldap_sasl_interactive_bind_s: Local error (-2)
>>         additional info: SASL(-1): generic failure: GSSAPI Error:
>> Unspecified GSS failure.  Minor code may provide more information
(Server
>> not found in Kerberos database)
>>
>> I did reinstall the whole server ('cause I'm lazy, hoping the
issue
>> disappear by itself) but the issue was the same, i did reinstall it
again
>> (a script do that, I'm really lazy) but after demoting it from FSMO
owner
>> with --remove-other-dead-server, same issue.
>>
>> All DCs have same configuration file, as it'sa  script which manage
>> installation I expect they are all identical and so I'm totally
puzzled
>> facing this issue. If anyone has some idea, some leads, I take it : )
>>
>
>