On 4/25/2017 11:04 PM, TomK wrote:
On 4/25/2017 4:42 PM, Lukas Slebodnik wrote:
On (25/04/17 16:35), Tom wrote:
We managed to create the key tab entry that worked. We did this earlier and now are at the subject errors instead of the original one.

We simply added the working entry into the keytab as a suggested and that moved us to the subject errors.

The error code now is:

1765328360 which is preceeded by code 1765328359 .

Produced preauth for next request: 2

I checked this and the time on ad dc is same as on this virtual client.

Please provide sanitized log files. *_child.log might be useful as well.
And not only domain log file.

Please also provide version of sssd.


LS
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Thanks Lukas.  Sent you, Sumit the sanitized file + sssd versions etc.

sssd-krb5-common-1.13.3-56.el6.x86_64

sssd-ldap-1.13.3-56.el6.x86_64

sssd-client-1.13.3-56.el6.x86_64

sssd-common-1.13.3-56.el6.x86_64

sssd-common-pac-1.13.3-56.el6.x86_64

sssd-ad-1.13.3-56.el6.x86_64

sssd-krb5-1.13.3-56.el6.x86_64

sssd-1.13.3-56.el6.x86_64

python-sssdconfig-1.13.3-56.el6.noarch

sssd-ipa-1.13.3-56.el6.x86_64

sssd-proxy-1.13.3-56.el6.x86_64

sssd-krb5-common-1.13.3-56.el6.x86_64

krb5-workstation-1.10.3-65.el6.x86_64

krb5-libs-1.10.3-65.el6.x86_64

pam_krb5-2.3.11-9.el6.x86_64

sssd-krb5-1.13.3-56.el6.x86_64

krb5-devel-1.10.3-65.el6.x86_64


Hey All,

Bit late and this was resolved in early May but wanted to share the solution here that worked for us with the help of folks on this list.

All of the following 3 solutions worked.

1) Remove the option --computer-name=$LHOST from the adcli command.

2) Leave the --computer-name as is but ensure to specify the host value in uppercase. ( ie --computer-name=CLIENTSRV-01 instead of --computer-name=clientsrv-01 )

3) Creating the keytab in lowercase manually, also worked.

Best solution for us was #1 above.

For details around these solutions, see below. Thanks Sumit, Lukas, Justin.

--
Cheers,
Tom K.
-------------------------------------------------------------------------------------

Living on earth is expensive, but it includes a free trip around the sun.



On 5/4/2017 7:38 AM, Lukas Slebodnik wrote:
>
>> # klist -Ktke
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Timestamp         Principal
>> ---- ----------------- -------------------------------------------------------- >> 18 05/04/17 01:35:53 [email protected] (aes256-cts-hmac-sha1-96) (0x8e26720160dfd4935bf6aa2118ee30df64fb1b094dff1799f0189b585e95b5b1) >> 18 05/04/17 01:35:53 [email protected] (aes128-cts-hmac-sha1-96) (0x22e590f4eb6d50f9d7e2aa60525a9bb5) >> 18 05/04/17 01:35:53 [email protected] (des3-cbc-sha1) (0xd5ea25a86bc24fb945ef38e51649516e7fec6d6d7386970e) >> 18 05/04/17 01:35:53 [email protected] (arcfour-hmac) (0xbbbf7229dd21e44edccf31871c4edbc3) >> 18 05/04/17 01:35:53 [email protected] (des-cbc-md5) (0x7cad5883b589d57a) >> 18 05/04/17 01:35:53 [email protected] (des-cbc-crc) (0x7cad5883b589d57a)
>
> I do not know why byt UPN principal is lower-cased.
>
> It looks line workaround with ldap_sasl_authid worked well for main domain (DEV-DOMAIN)
>
> (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [sdap_set_sasl_options] (0x2000): authid contains realm [DEV-DOMAIN.COM] > (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [sdap_set_sasl_options] (0x0100): Will look for [email protected] in default keytab > (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab > (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [find_principal_in_keytab] (0x4000): Trying to find principal [email protected] in keytab. > (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [match_principal] (0x1000): Principal matched to the sample ([email protected]). > (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [select_principal_from_keytab] (0x0200): Selected primary: clientsrv-01$ > (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [select_principal_from_keytab] (0x0200): Selected realm: DEV-DOMAIN.COM > (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_authid set to clientsrv-01$ > (Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_realm set to DEV-DOMAIN.COM
>
>
> But it didn't work for the forest root(subdomain from sssd POV) dev-fi.local.
>
> (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [new_subdomain] (0x0400): Creating [dev-fi.local] as subdomain of [DEV-DOMAIN]! > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [link_forest_roots] (0x2000): [dev-fi.local] is a forest root > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [link_forest_roots] (0x2000): [dev-fi.local] is a forest root of [DEV-DOMAIN]
>
>
> (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [find_principal_in_keytab] (0x4000): Trying to find principal [email protected] in keytab. > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [find_principal_in_keytab] (0x0400): No principal matching [email protected] found in keytab. > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [find_principal_in_keytab] (0x4000): Trying to find principal [email protected] in keytab. > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [find_principal_in_keytab] (0x0400): No principal matching [email protected] found in keytab. > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/[email protected] in keytab. > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [match_principal] (0x1000): Principal matched to the sample (host/[email protected]). > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [select_principal_from_keytab] (0x0200): Selected primary: host/clientsrv-01.e01.subdomain.company.com > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [select_principal_from_keytab] (0x0200): Selected realm: DEV-DOMAIN.COM > (Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [sdap_set_sasl_options] (0x0100): Option ldap_sasl_authid set to host/clientsrv-01.e01.subdomain.company.com
>
>
>
> So the best would be to generate keytab with the principal '[email protected]'
>
> Sumit,
> could you confirm?

----------------------------------------------------------------------------------

Yes, I think you are right.

In an older post I found:

(LAB) root@clientsrv-01:~ # LHOST=$(hostname -s); adcli join


--host-fqdn=$LHOST.e01.subdomain.company.com --computer-name=$LHOST


--domain=dev-domain.com --login-user=ADACCOUNT01 -v


--domain-ou="OU=Linux,OU=Server


Infrastructure,OU=Servers,OU=DOMAIN,DC=D2-DOMAIN,DC=com"


--os-name=`lsb_release -si` --os-version=`lsb_release -sr`


    --show-details --show-password

So the computer-name is given on the command-line and I guess in
lower-case. If you use '--computer-name=CLIENTSRV-01' the keytab entry
should be upper case. Please note that adcli on purpose does not
automatically upper-case the name. It it a convention to use upper-case
for the NetBIOS names but it is nowhere enforced. But maybe the adcli
man page should be more explicit about the consequences.

If --computer-name is not given adcli will try the first component of
--host-fqdn or whatever gethostname() returns. In both cases the name
will be upper-cased automatically.

HTH

bye,
Sumit

>
> LS

----------------------------------------------------------------------------------

Allright. That was it. Ty. The piece that was throwing me off the most was when it printed "No principal matching".

Despite this message, a simple case sensitive grep showed that the principal DID in fact match the .keytab file yet in the sssd logs it said it didn't.

I simply removed the computer object name option from the adcli line and it worked fine. I haven't tried to add the uppercase computer object name directly. I'll write this up to the main thread more cleanly over the weekend filtering out anything else that I missed.

There were a set of permissions that were added to these objects as well along the line of this testing. I'll list those too.

Again, thanks again guy's!

--
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]

Reply via email to