[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldapsearch + read-only domain controller: cannot bind
- To: Mark Pröhl <mark@mproehl.net>, "openldap-technical@openldap.org" <openldap-technical@openldap.org>
- Subject: Re: ldapsearch + read-only domain controller: cannot bind
- From: l@avc.su
- Date: Tue, 21 Jun 2016 11:55:35 +0300
- Authentication-results: mxback1o.mail.yandex.net; dkim=pass header.i=@avc.su
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=avc.su; s=mail; t=1466499335; bh=EqAJzhdWrF7eOw4DHQLtqhGS+fOmyOZyZiJdBLJrTy0=; h=X-Yandex-Sender-Uid:From:To:In-Reply-To:References:Subject: MIME-Version:Message-Id:X-Mailer:Date:Content-Transfer-Encoding: Content-Type; b=NO4xcWxF8LG7+b4f8XVUoCecYgXcZAl3ReDfqwz/ktdIXfSNw9t/UUVhhpwcq6ovh 9ZpDjnj90H43Bx8jNwLOCiJtDXrdK41WXzi6WKdi7PkiV8w/FCqQ/a1gvFOpW7pvSf N5WKr/UIN7trNDnNWAUrIwSuN6C4PYGwn4PRrXS0=
- In-reply-to: <57654311.7030500@mproehl.net>
- References: <3550941465644446@web21h.yandex.ru> <57654311.7030500@mproehl.net>
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