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

Tue Jan 15 23:55:15 UTC 2013

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 
>
> Thank you!
>
>
> -- 
> Sylvain Angers
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130115/fe6a518a/attachment.htm>