On Mon, Apr 24, 2017 at 12:22:02PM -0400, TomK wrote:
On 4/21/2017 9:48 PM, TomK wrote:
> Hey All,
>
> We are connecting a set of servers directly with AD. The AD computer
> object is created for the host and is associated to a service account.
> This service account works well with other hosts on the same domain.
>
> Since this is a direct SSSD to AD setup, we are using adcli to establish
> a connection to AD.
> adcli populates a /etc/krb5.keytab file with a number of entries including:
>
> * Added the entries to the keytab:
> host/longhostname-host01.xyz.abc.com(a)COMPANY.COM: FILE:/etc/krb5.keytab
>
> and runs successfully, without errors, to completion. However when
> starting up sssd, we see the following in the log files:
>
> .
> .
>
> [[sssd[ldap_child[11774]]]] [main] (0x0400): ldap_child started.
> [[sssd[ldap_child[11774]]]] [main] (0x2000): context initialized
> [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): total buffer size: 71
> [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): realm_str size: 12
> [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): got realm_str:
>
COMPANY.COM
> [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): princ_str size: 35
> [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): got princ_str:
> host/longhostname-host01.xyz.abc.co
> [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): keytab_name size: 0
> [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): lifetime: 86400
> [[sssd[ldap_child[11774]]]] [unpack_buffer] (0x0200): Will run as [0][0].
> [[sssd[ldap_child[11774]]]] [privileged_krb5_setup] (0x2000): Kerberos
> context initialized
> [[sssd[ldap_child[11774]]]] [main] (0x2000): Kerberos context initialized
> [[sssd[ldap_child[11774]]]] [become_user] (0x0200): Trying to become
> user [0][0].
> [[sssd[ldap_child[11774]]]] [become_user] (0x0200): Already user [0].
> [[sssd[ldap_child[11774]]]] [main] (0x2000): Running as [0][0].
> [[sssd[ldap_child[11774]]]] [main] (0x2000): getting TGT sync
> got princ_str: host/longhostname-host01.xyz.abc.com(a)COMPANY.COM
> .
> .
> Principal name is: [host/longhostname-host01.xyz.abc.com(a)COMPANY.COM]
> .
> .
>
> followed by:
>
> [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
> 1492661662.219837: Looked up etypes in keytab: des-cbc-crc, des,
> des-cbc-crc, rc4-hmac, aes128-cts, aes256-cts
> [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
> 1492661662.219898: Sending request (224 bytes) to
COMPANY.COM
> [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
> 1492661662.220151: Initiating TCP connection to stream 1.2.3.4:88
> [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
> 1492661662.222555: Sending TCP request to stream 1.2.3.4:88
> [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
> 1492661662.226128: Received answer from stream 1.2.3.4:88
> [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
> 1492661662.226205: Response was from master KDC
> [[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
> 1492661662.226238: Received error from KDC: -1765328378/Client not found
> in Kerberos database
>
>
> Verified that the krb5.keytab has the principal and it matches exactly.
> The OS is RHEL 6.7. Wondering if anyone ran into this and what could be
> some of the problems that could be causing this? Do we need something
> extra to be done on the AD side besides creating the computer object?
> We'd take it from there to dig further since I realize I can't provide
> all the details without first editing things out as I did above.
>
>
Hey All,
Solved the above by specifying the exact and ONLY keytab entries the AD
server needed, short-hostname(a)DOMAIN.COM, (autogenerated entries from
calling adcli were resulting in the above error message). Not sure why but
an incorrect keytab entry was being picked up from the krb5.keytab file even
though adcli was used to generate the krb5.keytab file. However now
Which id_provider did use? The AD provider should pick the right keytab
entry be default. As an alternative you can specify the right principal
with the ldap_sasl_authid option in the [domain/...] section of
sssd.conf (see man sssd-ldap for details).
receiving the following:
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313217: Received
error from KDC: -1765328359/Additional pre-authentication required
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313394: Processing
preauth types: 11, 19, 2, 16, 15
(Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
[sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313457: Selected
etype info: etype rc4-hmac, salt "", params ""
hm, maybe adding the 'allow_weak_crypto' option to /etc/krb5.conf might
help, see man krb5.conf for details.
HTH
bye,
Sumit
>
> The above eventually cascades into this:
>
> (Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
> [sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313894: Produced
> preauth for next request: 2
> (Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
> [sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.313965: Sending
> request (276 bytes) to
DOMAIN.COM
> (Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
> [sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.314134: Initiating
> TCP connection to stream 1.2.3.4:88
> (Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
> [sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.314426: Sending TCP
> request to stream 1.2.3.4:88
> (Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
> [sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.323829: Received
> answer from stream 1.2.3.4:88
> (Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
> [sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.323997: Response was
> from master KDC
> (Mon Apr 24 10:31:22 2017) [[sssd[ldap_child[21461]]]]
> [sss_child_krb5_trace_cb] (0x4000): [21461] 1493044282.324066: Received
> error from KDC: -1765328360/Preauthentication failed
>
> Part of debugging, the option "Do not require Kerberos preauthentication"
> was unchecked. Any tips for getting this to work with preauthentication are
> greately appreciated.
>
> --
> Cheers,
> Tom K.
>
-------------------------------------------------------------------------------------
>
> Living on earth is expensive, but it includes a free trip around the sun.
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org