Sumit, I have set the names of all the Domain Controllers to be resolvable to the IP of the one reachable Domain Controller in /etc/hosts /etc/hosts:Reachable_IP_BOX 172.10.10.1DC1 172.10.10.1DC2 172.10.10.1...... However, I still see the followingMarking SRV lookup of service 'gc_addomain.local' as 'neutral' Marking server dc1.addomain.local' as 'name not resolved'
Additionally I have configured [domain/ipa.internal] with subdomain_inherit = ldap_user_principalldap_user_principal = nosuchattr As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be the old hostname of the IPA KDC.After much troubleshooting I believe I got this fixed by deleting extra folders in /var/named/dyndb-ldap/ipa/masterRight now the only two folders are ipa.internal and <ip.adddr>.in-addr.arpa. I think this is what helped with this issue. but can you please confirm if it sounds reasonable. Ssh is still failing, possibly due to the problem 1 above. Is there anything else I can do to force ipa to pay attention to the /etc/hosts ?Or is this some other issue? thanks From: Sumit Bose <sb...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: Sumit Bose <sb...@redhat.com>; Freeipa-users <freeipa-users@redhat.com> Sent: Wednesday, July 13, 2016 5:43 AM Subject: Re: [Freeipa-users] Unable to ssh after establishing trust 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