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]
