On 4/24/2017 9:40 PM, TomK wrote:
> On 4/24/2017 12:41 PM, Sumit Bose wrote:
>> 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
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>>
> Hey Sumit,
>
> Thanks.
>
> id_provider = ad
>
> It's direct from SSSD to AD in this environment. Tried the
> allow_weak_crypto anyway but no effect.
>
> We typically didn't have to use ldap_sasl_authid with these configs to
> work. So hence my earlier question: if using keytabs for authentication
> between Linux and AD, what is the correct procedure to setup the AD
> objects? Would like to find out what is missing on that side since the
> object doesn't appear to be created in the same manner as the ones done
> earlier. For example, we can run kinit against something like this:
> verylong-hostname(a)DOMAIN.COM but not:
> /host/verylong-hostname(a)DOMAIN.COM or
> /host/verylong-hostname.sub.domain.com(a)DOMAIN.COM etc.
>
> Could some change have occurred to the AD Service Account to cause these?
>
I should add that prior to the difference between the working and non
working hosts were that the non working one picked up the following
principle:
got princ_str: verylong-hostname
whereas the non working one always picked the following one:
got princ_str: host/verylong-hostname.subdomain.domain.com(a)DOMAIN.COM
Not sure if this helps.
*Correction*
Working one picked up this:
got princ_str: verylong-hostname
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.