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) [[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
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
