[Freeipa-users] error: Realm not local to KDC

Wed Jan 16 08:11:10 UTC 2013

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 at 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 at 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 at 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 at 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 admin at 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 at mtl-vdi08d ~]#
>>
>>
>>
>>
>> see the "Unable to find 'admin' user with 'getent passwd admin'!" message
>>
>> [root at mtl-vdi08d log]# getent passwd t154793
>> [root at mtl-vdi08d log]#
>>
>>
>> [root at mtl-vdi02d t154793]# getent passwd t154793
>> t154793:*:1947600004:1947600004:Sylvain Angers:/home/t154793:/bin/bash
>> [root at mtl-vdi02d t154793]#
>>
>>
>> What could be the cause?
>> Any assistance would be appreciate