Is it possible to email the configuration and logs to RH only?
Cheers,
Tom
Sent from my iPhone
On Apr 25, 2017, at 4:22 PM, Justin Stephenson
<jstephen(a)redhat.com> wrote:
SSSD searches for a principal to use in the keytab based on the following priority:
* Priority of lookup:
1) our.hostname@REALM or host/our.hostname@REALM depending on the input
2) SHORT.HOSTNAME$@REALM (AD domain)
3) host/our.hostname@REALM
4) foobar$@REALM (AD domain)
5) host/foobar@REALM
6) host/foo@BAR
7) pick the first principal in the keytab
I expect on the system where SSSD is choosing host/hostname there are no keytab
principals which match the first 2 choices listed above and therefore SSSD uses the
host/hostname principal. You can run 'klist -k' to check, or you can add -v to the
adcli join command to see which principals are added. If there is a difference between
systems, I would check the system hostname and also check if the '-N' argument is
used which can modify the principal names added to the /etc/krb5.keytab during the join.
Also, you can add the --user-principal argument to the adcli join command which will
allow you to get a TGT with the host/our.hostname@REALM principal
Kind regards,
Justin Stephenson
> On 04/25/2017 03:26 PM, Tom wrote:
> 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
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org