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 -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>
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 clientsrv-01$(a)DEV-DOMAIN.COM
(aes256-cts-hmac-sha1-96)
(0x8e26720160dfd4935bf6aa2118ee30df64fb1b094dff1799f0189b585e95b5b1)
> 18 05/04/17 01:35:53 clientsrv-01$(a)DEV-DOMAIN.COM
(aes128-cts-hmac-sha1-96) (0x22e590f4eb6d50f9d7e2aa60525a9bb5)
> 18 05/04/17 01:35:53 clientsrv-01$(a)DEV-DOMAIN.COM
(des3-cbc-sha1)
(0xd5ea25a86bc24fb945ef38e51649516e7fec6d6d7386970e)
> 18 05/04/17 01:35:53 clientsrv-01$(a)DEV-DOMAIN.COM (arcfour-hmac)
(0xbbbf7229dd21e44edccf31871c4edbc3)
> 18 05/04/17 01:35:53 clientsrv-01$(a)DEV-DOMAIN.COM (des-cbc-md5)
(0x7cad5883b589d57a)
> 18 05/04/17 01:35:53 clientsrv-01$(a)DEV-DOMAIN.COM (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
clientsrv-01$(a)DEV-DOMAIN.COM 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
clientsrv-01$(a)DEV-DOMAIN.COM in keytab.
(Thu May 4 01:36:07 2017) [sssd[be[DEV-DOMAIN]]] [match_principal]
(0x1000): Principal matched to the sample (clientsrv-01$(a)DEV-DOMAIN.COM).
(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
clientsrv-01.e01.subdomain.company.com(a)DEV-DOMAIN.COM in keytab.
(Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]]
[find_principal_in_keytab] (0x0400): No principal matching
clientsrv-01.e01.subdomain.company.com(a)DEV-DOMAIN.COM found in keytab.
(Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]]
[find_principal_in_keytab] (0x4000): Trying to find principal
CLIENTSRV-01$(a)DEV-DOMAIN.COM in keytab.
(Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]]
[find_principal_in_keytab] (0x0400): No principal matching
CLIENTSRV-01$(a)DEV-DOMAIN.COM found in keytab.
(Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]]
[find_principal_in_keytab] (0x4000): Trying to find principal
host/clientsrv-01.e01.subdomain.company.com(a)DEV-DOMAIN.COM in keytab.
(Thu May 4 01:36:08 2017) [sssd[be[DEV-DOMAIN]]] [match_principal]
(0x1000): Principal matched to the sample
(host/clientsrv-01.e01.subdomain.company.com(a)DEV-DOMAIN.COM).
(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
'CLIENTSRV-01$(a)DEV-DOMAIN.COM'
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.