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 <[email protected]> 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 <[email protected]> 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/[email protected]: >>>>>>>> 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/[email protected] >>>>>>>> . >>>>>>>> . >>>>>>>> Principal name is: [host/[email protected]] >>>>>>>> . >>>>>>>> . >>>>>>>> >>>>>>>> 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, [email protected], (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 -- [email protected] >>>>>>> To unsubscribe send an email to [email protected] >>>>>> _______________________________________________ >>>>>> sssd-users mailing list -- [email protected] >>>>>> To unsubscribe send an email to [email protected] >>>>>> >>>>> 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: >>>>> [email protected] but not: >>>>> /host/[email protected] or >>>>> /host/[email protected] 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/[email protected] >>>> >>>> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >> _______________________________________________ >> sssd-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
