[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapsearch + read-only domain controller: cannot bind



Hi Mark.

Thank you, looks like the problem is not related to OpenLDAP package. I've tried to get a service ticket for ldap/dc.contoso.com@CONTOSO.COM, but to no avail:

assuming I've got valid TGT:
[root@centos7] # KRB5_TRACE=/dev/stdout kvno ldap/dc.contoso.com@CONTOSO.COM
Getting credentials user@CONTOSO.COM -> ldap/dc.contoso.com@CONTOSO.COM using ccache FILE:/tmp/krb5cc_0
Retrieving user@CONTOSO.COM -> ldap/dc.contoso.com@CONTOSO.COM from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found
Retrieving user@CONTOSO.COM -> krbtgt/CONTOSO.COM@CONTOSO.COM from FILE:/tmp/krb5cc_0 with result: 0/Success
Starting with TGT for client realm: user@CONTOSO.COM -> krbtgt/CONTOSO.COM@CONTOSO.COM
Requesting tickets for ldap/dc.contoso.com@CONTOSO.COM, referrals on
Generated subkey for TGS request: aes256-cts/BECF
etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
Encoding request body and padata into FAST request
Sending request (2185 bytes) to CONTOSO.COM
Resolving hostname dc.contoso.com
Initiating TCP connection to stream 192.168.0.100:88
Sending TCP request to stream 192.168.0.100:88
Resolving hostname dc.contoso.com
Sending initial UDP request to dgram 192.168.0.100:750
Sending initial UDP request to dgram 192.168.0.100:88
Sending retry UDP request to dgram 192.168.0.100:88
Sending retry UDP request to dgram 192.168.0.100:88
Terminating TCP connection to stream 192.168.0.100:88
kvno: A service is not available that is required to process the request while getting credentials for ldap/dc.contoso.com@CONTOSO.COM

At the first sight, it looks like a network problem. However, tcpdump + wireshark revealed that the packets are being sent and received with no errors, and dc.contoso.com answers with 'KRB Error: KRB5KDC_ERR_SVC_UNAVAILABLE'. So it looks like a problem on the DC itself. However, there are no failures logged.
I think it somehow related to Kerberos FAST protocol and its implementation on Windows Server side.
I'll keep digging.


18.06.2016, 15:48, "Mark Pröhl" <mark@mproehl.net>:
> On 06/11/2016 01:27 PM, l@avc.su wrote:
>>  Hello.
>>
>>  I'm seeing very strange behavior with ldapsearch with GSSAPI on CentOS 7
>>  and Microsoft Windows 2012R2 Read-only Domain Controller.
>>  I can obtain Kerberos ticket with no errors, with my user's credentials,
>>  or with machine's keytab.
>>
>>  However, when I'm trying to make LDAP request with GSSAPI bind, i'm
>>  getting an error:
>>
>>  ldapsearch -Y GSSAPI -H ldap://dc.contoso.com/ -b "dc=contoso,dc=com"
>>  "(sAMAccountName=user)"
>>  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 (A service is not
>>  available that is required to process the request)
>>
>>  openldap-clients ver. 2.4.40 release 9.el7_2
>>
>>  Here's the -d1 output:
>>
>>  ldap_url_parse_ext(ldap://dc.contoso.com/)
>>  ldap_create
>>  ldap_url_parse_ext(ldap://dc.contoso.com:389/??base)
>>  ldap_sasl_interactive_bind: user selected: GSSAPI
>>  ldap_int_sasl_bind: GSSAPI
>>  ldap_new_connection 1 1 0
>>  ldap_int_open_connection
>>  ldap_connect_to_host: TCP dc.contoso.com:389
>>  ldap_new_socket: 3
>>  ldap_prepare_socket: 3
>>  ldap_connect_to_host: Trying 192.168.0.100:389
>>  ldap_pvt_connect: fd: 3 tm: -1 async: 0
>>  attempting to connect:
>>  connect success
>>  ldap_int_sasl_open: host=dc.contoso.com
>>  SASL/GSSAPI authentication started
>>  ldap_msgfree
>>  ldap_err2string
>>  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 (A service is not
>>  available that is required to process the request)
>>  ldap_free_connection 1 1
>>  ldap_send_unbind
>>  ber_flush2: 7 bytes to sd 3
>>  ldap_free_connection: actually freed
>>
>>  This problem does not appear with regular DC servers. I can bind and
>>  search to them with no errors.
>>
>>  How can I debug this problem?
>
> Hi,
>
> Maybe you can turn on kerberos tracing and repeat the failing ldapsearch
> from CentOS7 and send us the output?
>
> I.e.:
>
> KRB5_TRACE=/dev/stdout ldapsearch -Y GSSAPI -H ldap://dc.contoso.com/ -b
> "dc=contoso,dc=com" "(sAMAccountName=user)"
>
> Cheers,
>
> Mark