[Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Chris Dagdigian]

< 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.org at 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.org at 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 at usaeilvdip001 sssd]#
>>
>>
>
> The logs indicate that the user actually come from the member domain in
> the forest: username at NAFTA.COMPANY.ORG. But the [capath] section you
> added to krb5.conf only contains the forest root.
>
>> COMPANY-AWS.ORG = {
>>
>>    COMPANY-IDM.ORG = COMPANY-AWS.ORG
>>
>> }
>>
>> COMPANY-IDM.ORG = {
>>
>>    COMPANY-AWS.ORG = COMPANY-AWS.ORG
>>
>> }
>>
>
> 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)
>
> COMPANY-AWS.ORG = {
>
>    COMPANY-IDM.ORG = COMPANY-AWS.ORG
>
> }
>
> COMPANY-IDM.ORG = {
>
>    COMPANY-AWS.ORG = COMPANY-AWS.ORG
>    NAFTA.COMPANY.ORG = COMPANY-AWS.ORG
> }
>
> NAFTA.COMPANY.ORG = {
>    COMPANY-IDM.ORG = COMPANY-AWS.ORG
> }

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 username at NAFTA.COMPANY.ORG
> kvno host/usaeilvdip001.company-aws.org at COMPANY-IDM.ORG
>
> If kvno returns an error please rerun as
>
> KRB5_TRACE=/dev/stdout kvno host/usaeilvdip001.company-aws.org at COMPANY-IDM.ORG
>
> and send the output.

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

>
> HTH
>
> bye,
> Sumit