Re: [Freeipa-users] error: Realm not local to KDC
Hello, as Dmitri said, this problem is probably related to DNS. I would recommend to run tcpdump/wireshark on the client, capture all network traffic during client enrolment and check IP addresses. You will probably see IP address of AD server more often than you should ... Petr^2 Spacek On 16.1.2013 00:55, Dmitri Pal wrote: 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)
Re: [Freeipa-users] error: Realm not local to KDC
On Tue, 2013-01-15 at 17:57 -0500, Sylvain Angers wrote: 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 Because you are putting machines in the top domain I suspect your client is trying to resolve the realm via SRV records and finds those of the AD server. You may want to statically configure the default _realm and the [domain_realm] section in your client krb5.conf and turn off dns discovery in krb5.conf for those client. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] error: Realm not local to KDC
On 01/16/2013 08:55 AM, Simo Sorce wrote: On Tue, 2013-01-15 at 17:57 -0500, Sylvain Angers wrote: 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 Because you are putting machines in the top domain I suspect your client is trying to resolve the realm via SRV records and finds those of the AD server. You may want to statically configure the default _realm and the [domain_realm] section in your client krb5.conf and turn off dns discovery in krb5.conf for those client. Simo. Not only that. The fact that getent failed might mean that LDAP connection was not established or was attempted against the wrong server. -- 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
Re: [Freeipa-users] error: Realm not local to KDC
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)
