< huge log sample deleted >

Sumit Bose wrote:
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [validate_tgt] (0x0020): TGT failed verification using key for [host/usaeilvdip001.company-aws....@company-idm.org].

ok, it is the ticket validation which fails. You can get around this for
testing by setting 'krb5_validate = false' in the [domain/...] section
of sssd.conf. But please use this only for testing because this error
indicates that there are issues in your setup/configuration.

Much appreciated. Will test today.
But your host principal
host/usaeilvdip001.company-aws....@company-idm.org looks odd as well.
Why is the host in the AD DNS domain, this calls for trouble.
Additionally I wonder why the realm part '@company-idm.org' was created
in lower-case while joining the IPA this should be created upper-case.
Or is this all due to sanitation?

{ Capitalization problem was a sanitation error }

At the time we set up the IPA environment the only AD domain we had administrative control over was already in use and could not easily be reconfigured to meet the best practices for having an
IPA server sit in the same domain name and realm

After reading the documentation and a lot of posts on redhat.com we decided that the IPA server would have to be in a completely new autonomous domain name, DNS zone and Kerberos realm. The IPA instructions (and ipa-client-install options) all seem to indicate that although not a best practice it is something that was supported although there is a loss of functionality to be expected.

So we run servers as FQDN members of company-aws.org but they are IPA clients of company-ipa.org

My understanding is that if we:

 1. Bind a Linux IPA client to company-ipa.com
2. But configure the Linux client to have a hostname of client.company-aws.com

.. then what we primarily lose is kerberos related service functionality for logged-in users

Since our core need was for AD password authentication and RBAC control over Linux hosts we
decided to move forward with this odd config.

Would be greatly interested if I'm way off base on use of totally autonomous IPA realms and domain names.

(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [get_and_save_tgt]
(0x0020): 1242: [-1765328377][Server not found in Kerberos database]
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [map_krb5_error]
(0x0020): 1303: [-1765328377][Server not found in Kerberos database]
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data]
(0x0200): Received error code 1432158209
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [pack_response_packet]
(0x2000): response packet size: [20]
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data]
(0x4000): Response sent.
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400):
krb5_child completed successfully
[root@usaeilvdip001 sssd]#

The logs indicate that the user actually come from the member domain in
the forest: usern...@nafta.company.org. But the [capath] section you
added to krb5.conf only contains the forest root.







Please try to add the member domain as well. The result might look like
this: (assuming COMPANY-AWS is the forest root, NAFTA is the member
domain and COMPANY-IDM is the IPA domain)







Thank you. I don't think our Linux client picked up the CAPATH changes needed but I think the IPA server did the proper thing deep down in that include directory that
is referenced at the top of sssd.com.

Will check and verify.

You can test the configuration independent of SSSD by calling

kdestroy -A
kinit usern...@nafta.company.org
kvno host/usaeilvdip001.company-aws....@company-idm.org

If kvno returns an error please rerun as

KRB5_TRACE=/dev/stdout kvno host/usaeilvdip001.company-aws....@company-idm.org

and send the output.

Again, thanks for the time, attention and helpful replies.



Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to