[Pkg-openldap-devel] ldap/localhost TGS requested for remote ldapsearch request

Tue Apr 17 17:52:53 BST 2018

I solved the issue.

Thank for your help.
I add the AD FQDN in /etc/hosts to get the reverse name and the error has disapeared.

For your information, I have done other investigations to solve this issue and I find that SPN *may* be set in openldap.
I don't know if such element can be used to improve OpenLdap or Cyrus.

I found something that seem interesting and that should have solve my issue in gssapi.c but, it seems ldapsearch prefer to use sasl.c.

In openldap-2.4.44+dfsg.orig.tar.gz package, in the libraries/libldap/gssapi.c (all following details come from this file), the SPN seems to be defined in the "guess_service_principal" function.

This function may use its "dnsHostname" argument (it depends on ldapServiceName value).
Because "guess_service_principal" function is only called in "ldap_int_gss_spnego_bind_s" function,
it appears that "dnsHostName" is defined in "ldap_gssapi_get_rootdse_infos" function, "like ldapServiceName" var.

This function is calling "ldap_values" function 3 times.
One for "supportedSASLMechanisms", one for "ldapServiceName" and one for "dnsHostName".

If I check manually the value, they are OK.

# ldapsearch -H ldap://SRV_B.domain.tld -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
# ldapsearch -H ldap://SRV_B.domain.tld -x -b "" -s base -LLL ldapServiceName
dn:
ldapServiceName: domain.tld:SRV_B$@REALM
# ldapsearch -H ldap://SRV_B.domain.tld -x -b "" -s base -LLL dnsHostName
dn:
dnsHostName: SRV_B.domain.tld

I I look in the strace dump, i have done, I get :
# grep supportedSASLMechanisms dump.log
write(3<TCP:[SRV_A:43210->SRV_B:389]>, "0>\2\1\1c9\4\0\n\1\0\n\1\0\2\1\0\2\1\0\1\1\0\207\vobjectclass0\31\4\27supportedSASLMechanisms", 64) = 64
read(3<TCP:[SRV_A:43210->SRV_B:389]>, "\1d\204\0\0\0W\4\0000\204\0\0\0O0\204\0\0\0I\4\27supportedSASLMechanisms1\204\0\0\0*\4\6GSSAPI\4\nGSS-SPNEGO\4\10EXTERNAL\4\nDIGEST-MD5", 94) = 94
# grep ldapServiceName dump.log
# grep dnsHostName dump.log

So, according to this incoherency, this is not the executed source code. 

supportedSASLMechanisms is also available in libraries/libldap/sasl.c without other part in "ldap_pvt_sasl_getmechs" function,
in this same file, this function is only called in "ldap_sasl_interactive_bind" and call "ldap_int_sasl_bind" (in libraries/libldap/cyrus.c).
In this last function, i was able to find printed string "SASL/ authentication started"

My point is to identify where the "ldap" part of the SPN is defined to identify whether the issue is related to openldap.
Searching for "ldap" in cyrus.c point to sasl_client_new( "ldap", host, NULL, NULL, client_callbacks, 0, &ctx);

After an overview of "ldap_int_sasl_bind" and "sasl_client_new", it seems that SPN is build by SASL layer from
"ldap" and host arguments and it is frustrating to see ldap GSSAP solve the issue but not Cyrus SASL.

Thank you for your reading.

17 avril 2018 17:49 "Dan White" <dwhite at olp.net> a écrit:

> On 04/17/18 12:05 +0000, marlox at ouda.fr wrote:
> 
>> When I query ldap service on SRV_B with ldapsearch from SRV_A,
>> the requested TGS to the KDC is ldap/localhost or ldap/SRV_A.REALM and
>> not ldap/SRV_B.REALM.
>> I expect to send ldap/SRV_B.REALM TGS but I may miss something in the intended behaviour.
>> 
>> Here is a transcript (from SRV_A) : (REALM = DOMAIN.TLD)
>> 
>> # kinit user
>> Password for user at REALM:
>> # klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: user at REALM
>> 
>> Valid starting Expire Service principal
>> ********** ****** krbtgt/REALM at REALM
>> renew until ******
>> # ldapsearch -H ldap://SRV_B.domain.tld -LLL -b dc=domain,dc=tld
>> # strace yy -y -s 128 -o dump.log ldapsearch -H ldap://SRV_B.domain.tld -LLL -b dc=domain,dc=tld
>> # grep :88 dump.log | tail -n2 # Anonymised
>> read(5<TCP:[IP_SRV_A:5####->IP_SRV_B:88]>, "...\17REALM\252)...ldap\33srv_a.domain.tld..., 343) =
>> 343
>> close(5<TCP:[IP_SRV_A:5####->IP_SRV_B:88]>) = 0
> 
> This has the feel of a DNS/host resolution issue. Do you have PTR records
> configured appropriately?
> 
>> In my first investigation, i had ldap/localhost that was requested and I have done the following
>> modification.
>> In /etc/hosts, i also SRV_A.domain.tls with 127.0.0.1
> 
> This seems problematic. From the perspective of your KDC, it will have
> difficulty establishing which service tickets to provide without a clear
> distinction/delineation as to which host owns which IP.
> 
> I suggest moving away from any mention of 127.0.0.1 as least from the KDC's perspective.
> 
>> In [domain_realms] section of REALM, i added the following statement,
>> localhost = REALM
>> 
>> For information, SRV_A is integrated in domain through SSSD and SRV_B is a domain controller.
>> Configuration file are :
>> /etc/ldap/ldap.conf:
>> BASE dc=domain,dc=tld
>> URI ldap://SRV_B.domain.tld
>> EOF
>> 
>> /etc/krb5.conf:
>> [libdefaults]
>> default_realm = REALM
>> rdns = false
> 
> Be sure you know what you're doing here. This does not appear to be default
> configuration.
> 
> Please review https://web.mit.edu/kerberos/krb5-1.13/doc/admin/princ_dns.html
> 
>> Other system information:
>> 
>> I use Debian 9.1 linux 4.9.0-3-amd64 and following packages:
>> * libc6 2.24-11+deb9u1
>> * libldap-common 2.4.44+dfsg-5+deb9u1
>> (idem version for libldap-*)
>> * krb5-config 2.5
>> * krb5-usr 1.15-1+deb9u1
>> (idem version for libkrb5* and ssd-krb5*)
>> * libsasl2-2 2.1.27~101-g0780600+dfsg-3
>> (idem version for libsasl2-modules*)
>> 
>> I have to admit that I don't know if the issue is related to ldap-utils, cyrus-sasl or kerberos but
>> ldap-utils packages seems to be the most relevant one.
> 
> Most likely if this behavior is the result of a bug, it is either with
> cyrus-sasl or the underlying kerberos library (mit).