[Freeipa-users] ipa trust-fetch-domains failing.

[pgb205]

Alexander, 
regarding your comment about putting stanza on each client.In our case clients are not on the same network as the Active Directory domain controller.My plan was to have the Freeipa server as the bridge-head server 
AD DC <-> FIPA server  <-> Linux clients
as it sits on the network that has access to both environments.
1. If each client has to go out to AD DC to authenticate than what is the purpose of FreeIPA server ? I thought it would act as a proxy to forward authentication requests to AD.
2. What would be my options in the above situation to get around this requirement -- direct connectivity to Active Directoryenvironment by clients?
thanks 

      From: Alexander Bokovoy <abokovoy at redhat.com>
 To: pgb205 <pgb205 at yahoo.com> 
Cc: Freeipa-users <freeipa-users at redhat.com>
 Sent: Monday, July 4, 2016 12:02 AM
 Subject: Re: [Freeipa-users] ipa trust-fetch-domains failing.
   
On Mon, 04 Jul 2016, pgb205 wrote:
>Selinux is disabled on the server. However, I managed to fix the problem buy adding the AD.DOMAIN {} 
>section to my krb5.conf in addition to IPA.DOMAIN {}. So it now looks like [realms]IPA.DOMAIN{master_kdc=ipa.dc.ipadomain:portauth_kdc=ipa.dc.ipadomain:port...}
>AD.DOMAIN{master_kdc=ad.dc.addomain:portauth_kdc=ad.dc.addomain:port...}
>this had the desired effect although I am not 100 clear on why this worked.
>My theory is that we have multiple domain controllers and of course the
>addomain.com forward zone that was configured prior returns a full
>list. Only the ports to the one ad.dc.addomain.com server have been
>opened between the ipa and ad servers and so when trust command is
>executed connection goes to some domain controller that IPA can't
>connect to, eventually generating an error.  Just a theory for now.
It is a totally plausible theory -- when we do trust-fetch-domains, we
try to use Kerberos authentication against AD DCs. Forcing IPA master to
use specific domain controller via krb5.conf should help here.

Note that you'll need to have a similar stanza on each IPA client as
well because authentication happens directly to AD DCs and SSSD on IPA
clients will have to do the same job using AD user credentials in case
of password logons.



>thanks
>
>      From: Alexander Bokovoy <abokovoy at redhat.com>
> To: pgb205 <pgb205 at yahoo.com>
>Cc: "bentech4you at gmail.com" <bentech4you at gmail.com>; Freeipa-users <freeipa-users at redhat.com>
> Sent: Friday, July 1, 2016 3:37 AM
> Subject: Re: [Freeipa-users] ipa trust-fetch-domains failing.
>
>On Thu, 30 Jun 2016, pgb205 wrote:
>>Ben, do you mind sharing your solution as I am affected by the exact same error when fetching AD domains.
>I'm currently on vacation and don't have access to my lab, but you need
>to check if there are any problems with SELinux. 'ipa
>trust-fetch-domains' calls out via DBus to another script. It is
>functionally equivalent to the following command run as root:
>
># oddjob_request -s com.redhat.idm.trust -o / -i com.redhat.idm.trust com.redhat.idm.trust.fetch_domains ad.test
>
>where ad.test is your AD root domain.
>
>If you add 'log level = 100' in /usr/share/ipa/smb.conf.empty, then this
>run will generate a lot of debug information.
>
>
>-- 
>/ Alexander Bokovoy
>
>
>

>-- 
>Manage your subscription for the Freeipa-users mailing list:
>https://www.redhat.com/mailman/listinfo/freeipa-users
>Go to http://freeipa.org for more info on the project


-- 
/ Alexander Bokovoy


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160719/4d4d77bc/attachment.htm>