Thank you for the hint. However, I'm not running slapd since this is Microsoft AD environment + Linux clients. I've tried to obtain a ticket for service upn as root and got the TGT, so it doesn't look like permissions issue.

15.06.2016, 23:06, "Dieter Klünter" dieter@dkluenter.de:

Am Sun, 12 Jun 2016 17:34:47 +0300 schrieb l@avc.su:

...

Hi Dieter.

I've tried performing this search from CentOS6 machine, with my own  UPN, with machine UPN, and it were successful. Accessing SPN  ldap/dc.contoso.com@CONTOSO.COM Keytab is located  in /etc/krb5.keytab, owned by root, access mode 0600. Dumped traffic  from the problem server. On myTGS-REQ, DC responds with  'krb5kdc_err_svc_unavailable' packet.  12.06.2016, 10:41, "Dieter Klünter" dieter@dkluenter.de:

Am Sat, 11 Jun 2016 14:27:26 +0300  schrieb l@avc.su:

[...]

the user, slapd runs as, needs to read keytab. Check with klist whether a ldap service principal ticket is available.

-Dieter

-- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

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

On 06/22/2016 10:28 AM, Dieter Klünter wrote:

Am Tue, 21 Jun 2016 11:55:35 +0300 schrieb l@avc.su:

...

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:

[...]

As i mentioned in my first post, linux kerberized clients require a host principal and a service principal. Read the Microsoft docs on kerberos services for Unix.

you do not need a kerberized linux client for performing a kerberized ldapsearch command in this scenario. No host principal or any other service principals for the linux systems are required to do this. The ldapsearch command fails to retrieve the LDAP service ticket for the RODC.

- Mark