Wondering if there are any more suggestions on this topic?
Cheers,
Tom
Sent from my iPhone
On Apr 25, 2017, at 3:17 AM, TomK <tk(a)mdevsys.com> wrote:
> On 4/25/2017 2:00 AM, TomK wrote:
>> 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.
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org