On 01/15/2013 05:57 PM, Sylvain Angers wrote: > Hello > > Please help me troubleshot this following issue, thank you in advance! > > Some rhel6.2 have problem with authenticating against IPA v2.2 > while some others on same domain do not have issue but still get the > same error "Failed to init credentials: Realm not local to KDC" > > hostname of client that work = mtl-vdi02d.cnppd.lab > hostname of client that does not work = mtl-vdi08d.cnppd.lab > all vm on RHEV > > ipa server (mtl-ipa01d.unix.cnppd.lab) is on unix.cnppd.lab because > we have AD > ip client are on cnppd.lab > Windows machine are also on cnppd.lab connected to "Active directory" >
Issues like this are usually related to DNS. We recommend that you delegate a zone from AD to IPA and install IPA with DNS to manage this zone. With the setup like yours you have a high chance of AD responding to the UNIX client requests. You can avoid this but it would require a bit of manual configuration. The following recommendation is written for trusts but AFAIU it is applicable to this use case too. There are two main options: take advantage of the IPA'sown DNS or not. Configuration with IPA DNS: * The recommended configuration is to take advantage of the IPA DNS and to delegate a zone from the DNS server (most likely AD DNS) to IPA. It should be possible to resolve the names in the AD domain via forwarders. This configuration does not differ from the normal DNS configuration we recommend and can be fully automated. Linux clients in this case become machines in the IPA DNS domain. * The alternative can be that IPA would be in the completely separate namespace.In this case the AD DNS server needs a conditional forwarder to resolve IPA names and the IPA DNS server needs a forwarder to resolve AD names. * An alternative solution, which would scale better in environments with many domains, would be a common forwarder as described in http://freeipa.org/page/IPAv3_testing_AD_trust#Adding_a_common_forwarder) <http://freeipa.org/page/IPAv3_testing_AD_trust#Adding_a_common_forwarder%29>.Cross forwarding is the only solution unless a common higher level DNS server delegates both the AD and IPA zones to the respective servers. * dns-a.example.com has a forwarder for example.net -> dns-b.example.net * dns-b.example.net has a forwader for example.com -> dna-a.example.com Configuration without IPA DNS: * It is possible to use an AD DNS for the deployment and not configure IPA DNS. In this case: * The AD DNS should be updated to have all the names of the IPA servers registered as Arecords(PTR records are not mandatory but are useful). * The IPA clients (SSSD) should be configured not to use service discovery but rather use the list of the IPA server names explicitely. * Client entries would also have to be added to the AD domain * If you prefer to use service discovery a subdomain can be allocated for IPA servers. Service (SRV) records can be created for that domain that would point to the list of the IPA servers. The clients can be then configured to use service discovery but every client would have to be added to the AD DNS directly too. * DNS-based service discovery should be seen as a preferred way for configuration without IPA DNS. There are too many places in both Windows and on Linux where default assumptions are made when resolving services that manual configuration should be discouraged. HTH > so we have a stub that redirect request for unix.cnppd.lab onto our ipa > > client can resolve ipa and vice versa > > [root@mtl-vdi08d log]# nslookup mtl-ipa01d.unix.cnppd.lab > Server: 165.115.58.16 > Address: 165.115.58.16#53 > > Non-authoritative answer: > Name: mtl-ipa01d.unix.cnppd.lab > Address: 165.115.118.21 > > [root@mtl-vdi08d log]# nslookup unix.cnppd.lab > Server: 165.115.58.16 > Address: 165.115.58.16#53 > > Non-authoritative answer: > Name: unix.cnppd.lab > Address: 165.115.118.21 > > [root@mtl-vdi08d log]# cat /etc/resolv.conf > # Generated by NetworkManager > domain cnppd.lab > search cnppd.lab cn.ca <http://cn.ca> > nameserver 165.115.58.16 > > > > we all get this message in our logs > > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1943]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1944]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1945]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1946]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:11:46 2013) [[sssd[ldap_child[1947]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1954]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:55 2013) [[sssd[ldap_child[1955]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1956]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1957]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > (Tue Jan 15 17:12:56 2013) [[sssd[ldap_child[1958]]]] > [ldap_child_get_tgt_sync] (0): Failed to init credentials: Realm not > local to KDC > > > while I can reinstall ipa-client on mtl-vdi02d and it will still work > > if I do the same with mtl-vdi08d, it will still not work > > > > > [root@mtl-vdi08d ~]# ipa-client-install > --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB --mkhomedir > Discovery was successful! > Hostname: mtl-vdi08d.cnppd.lab > Realm: UNIX.CNPPD.LAB > DNS Domain: UNIX.CNPPD.LAB > IPA Server: mtl-ipa01d.unix.cnppd.lab > BaseDN: dc=unix,dc=cnppd,dc=lab > > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Password for ad...@unix.cnppd.lab: > > Enrolled in IPA realm UNIX.CNPPD.LAB > Created /etc/ipa/default.conf > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB > SSSD enabled > Unable to find 'admin' user with 'getent passwd admin'! > Recognized configuration: SSSD > NTP enabled > Client configuration complete. > [root@mtl-vdi08d ~]# > > > > > see the "Unable to find 'admin' user with 'getent passwd admin'!" message > > [root@mtl-vdi08d log]# getent passwd t154793 > [root@mtl-vdi08d log]# > > > [root@mtl-vdi02d t154793]# getent passwd t154793 > t154793:*:1947600004:1947600004:Sylvain Angers:/home/t154793:/bin/bash > [root@mtl-vdi02d t154793]# > > > What could be the cause? > Any assistance would be appreciate > > Thank you! > > > -- > Sylvain Angers > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users