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

Sumit Bose sbose at redhat.com
Wed Nov 23 13:18:08 UTC 2016


On Wed, Nov 23, 2016 at 07:38:49AM -0500, Chris Dagdigian wrote:
> 
> < 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.

NO. It is the other way round.

It is _not_ recommended and will not even work properly to use the same
DNS domain for IPA and AD. Even worse with using the same realm for
both, this cannot work at all.

It is required to have a different realm name for the IPA domain and it
is important to use a different DNS domain as well (a bit is possible
with hosts in the same DNS domain but you loose functionality here).

Where did you find the recommendation to user the same DNS domain and
realm?

bye,
Sumit

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




More information about the Freeipa-users mailing list