On Tue, Jul 12, 2016 at 06:40:22PM +0000, pgb205 wrote:
> +freeipa-users list
> 
>       From: pgb205 <pgb...@yahoo.com>
>  To: Sumit Bose <sb...@redhat.com> 
>  Sent: Tuesday, July 12, 2016 2:12 PM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>    
> Sumit, thanks for replying
> So the first issue is my fault, probably from when I was sanitizing logs. 
> our active directory domain is ad_domain.local, but users would expect to 
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is 
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> ewr-fipa_server used to be old trial server so I am not sure why it's still 
> in the dns lookup results. I'll check this part further.
> Lastly. only the connection to one of the domain controllers on AD side is 
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf, a connection to this single, accessible domain controller. 
> Are there any other files where I would needto lock down the connections 
> between ipa->ad so that all traffic goes to specific active directory domain 
> controller?
> thanks again for replying so quickly.

Currently it is not possible to specify individual AD DC SSSD on the IPA
server should talk to. We have ticket
https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
later versions of SSSD. 

Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
get a list of AD DC, then picks one to get the next nearest site for the
IPA domain and finally tries to lookup a DC from the matching site (if
any).

According to your logs SSSD was able to find 18 DCs with the SRV lookup.
A call like

    dig SRV _ldap._tcp.ad_domain.local

on the IPA server should return the same list of 18 DCs.

As a work-around, or better a hack, you might want to try to set the IP
address of all the 18 DC returned to the IP address of the only
accessible DC in /etc/hosts. This way SSSD should have no chance to
connect to a different DC.

bye,
Sumit

> 
>       From: Sumit Bose <sb...@redhat.com>
>  To: pgb205 <pgb...@yahoo.com> 
> Cc: Sumit Bose <sb...@redhat.com>
>  Sent: Tuesday, July 12, 2016 5:37 AM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>   
> On Mon, Jul 11, 2016 at 09:14:03PM +0000, pgb205 wrote:
> > Sumit, 
> > sssd log files attached with debug=10 in all sections.I have attempted 
> > several logins for comparison as well as kinit commands
> 
> I came across two issues in the logs.
> 
> First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt
> but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the
> AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently
> FreeIPA cannot resolve those principals correctly. It was planned for
> IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will
> be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime
> please try to work-around suggested at the end of
> http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to
> authenticate with user@AD_DOMAIN.COM SSSD looks for a server called
> ewr-fipa_server.ad_domain.com but cannot find it an return the error code
> for "Cannot contact any KDC for requested realm".
> 
> Second there are some issues access AD DCs via LDAP. SSSD tries to
> connect to mm-sfdc01.ad_domain.local and mm-tokyo-02.ad_domain.local but
> both fails. It is not clear from the logs if already the DNS lookup for
> those fails or if the connection itself runs into a timeout. In the
> former case you should make sure that the names can be resolved in the
> IPA server in the latter you can try to increase ldap_network_timeout
> (see man sssd-ldap for details). Since SSSD cannot connect to the DCs it
> switches the AD domains to offline. The authentication request is
> handled offline as well but since there are no cached credentials you
> get the permission denied error.
> 
> HTH
> 
> bye,
> Sumit
> 
> > 
> >      From: Sumit Bose <sb...@redhat.com>
> >  To: pgb205 <pgb...@yahoo.com> 
> > Cc: "Freeipa-users@redhat.com" <Freeipa-users@redhat.com>
> >  Sent: Monday, July 11, 2016 3:06 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >    
> > On Mon, Jul 11, 2016 at 03:46:57AM +0000, pgb205 wrote:
> > > I have successfully established trust and am able to obtain ticket 
> > > granting ticketkinit user@AD_DOMAIN.COMI can also do kinit 
> > > admin@IPA_DOMAIN.COMssh admin@IPA_DOMAIN.COM also works
> > > however, ssh user@AD_DOMAIN.COM or user@ad_domain.com fails
> > > I have checked that there are no hbac rules other then the default 
> > > allow_all rule
> > > in sssd_ssh.log see
> > > permission denied (6) error in sssd_ipa.domain.log file I see
> > > pam_handler_callback 6 permission_denied
> > > in sssd_nss.log Unable to get information from Data ProviderError: 3 
> > > Account info lookup failedWill try to return what we have in cache
> > > in /var/log/secure received for user user@AD_DOMAIN.COM: 6 (Permission 
> > > denied) 
> > > 
> > > I can provided full logs if necessary to diagnose the above problem.
> > 
> > Yes, full SSSD logs with debug_level=10 would be best.
> > 
> > > ----------Additionally, I would like to be able to login as user not 
> > > user@AD_DOMAIN.COM
> > > My understanding that only thing that I have to change to make this 
> > > happen is /etc/krb5.conffor line 
> > > [libdefaults] default_realm=AD_DOMAN.COM and then restarting ipa services.
> > 
> > No, please do not change the default_realm. This is not related to the
> > issues you are seeing.
> > 
> > bye,
> > Sumit
> > 
> > > However, when I do this I get failure to restart Samba service
> > 
> > > -- 
> > > 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
> > 
> > 
> > 
> >  
> 
> 
> 
> 
>    
> 
>   

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

Reply via email to