Server: FreeIPA 4.2.0 on Centos 7.2:
[root@server01 ~]# rpm -qa ipa-server ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64
Client: CentOS 6.5
[root@host01 ~]# rpm -qa ipa-client ipa-client-3.0.0-50.el6.centos.1.x86_64
FreeIPA Realm: IPA.EXAMPLE.COM DNS Domain: ipa.example.com FreeIPA servers: server01-5.ipa.wandisco.com
I have added TXT record _kerberos and SRV records _ldap._tcp/_kerberos._udp to example.com zone to enable DNS auto discovery.
Now I'm trying to enrol host01.domain.example.com to IPA:
[root@host01] # ipa-client-install Discovery was successful! Hostname: host01.domain.example.com Realm: IPA.EXAMPLE.COM DNS Domain: example.com IPA Server: server01.ipa.example.com BaseDN: dc=ipa,dc=example,dc=com
It seems that only DNS Domain wasn't discovered properly. It should be ipa.example.com and not example.com.
/var/log/ipaclient-install.log ipaclient-install.log
The snippet below is from our production environment:
[root@dns01 ~]# ipa-client-install --enable-dns-updates --mkhomedir Discovery was successful! Hostname: dns01.frem.wandisco.com Realm: IPA.WANDISCO.COM DNS Domain: wandisco.com IPA Server: ashb01.ipa.wandisco.com BaseDN: dc=ipa,dc=wandisco,dc=com Continue to configure the system with these values? [no]: yes
I've attached /var/log/ipaclient-install.log file.
Hello, IMHO, host dns01.frem.wandisco.com does not belong to ipa.wandisco.com domain, so actually wandisco.com is subdomain for hostname, but ipa.wandisco.com doesn't.
It is unclear what is the problem. The log indicates that enrollment succeeded. What exactly are you concerned about?
The problem is that the detected domain wandisco.com is not correct. Our DNS Domain configured on all other servers/clients is ipa.wandisco.com and even though the enrollment somehow succeeds, I would still expect for the domain to be consistent across all our realm.
Replying to [comment:7 spako]:
Your hostname is dns01.frem.wandisco.com. This cannot belong to ipa.wandisco.com dns zone.
As per our conversation with mbasti in #freeipa channel, I don't quite understand the point of the DNS Domain auto detection. I was under the impression that we're trying to detect an IPA domain here and not a domain of the host:
[root@node1 ~]# ipa-client-install Using existing certificate '/etc/ipa/ca.crt'. DNS discovery failed to determine your DNS domain Provide the domain name of your IPA server (ex: example.com):
Perhaps I should describe our environment a little bit more:
IPA Domain: ipa.wandisco.com IPA Realm: IPA.WANDISCO.COM IPA Servers: x.ipa.wandisco.com All IPA Clients: x.y.wandisco.com where x is hostname (e.g. dns01) and y is usually host location (e.g. frem for Fremont)
How can I make ipa-client-install correctly detect IPA domain ipa.wandisco.com instead of just wandisco.com?
Same result with the latest ipa-client package on Centos 7.2 client machine:
[root@node1 ~]# rpm -qa ipa-client ipa-client-4.2.0-15.0.1.el7.centos.17.x86_64 [root@node1 ~]# ipa-client-install Using existing certificate '/etc/ipa/ca.crt'. Discovery was successful! Client hostname: node1.shdc.wandisco.com Realm: IPA.WANDISCO.COM DNS Domain: wandisco.com IPA Server: shdc01.ipa.wandisco.com BaseDN: dc=ipa,dc=wandisco,dc=com Continue to configure the system with these values? [no]:
Okay, now I can see it. ipa-client-install is not able to automatically handle the case where IPA client is not in a sub-domain of IPA domain.
ipa-client-install
In this case the auto-detection should simply fail but it is passing in your case because you manually added SRV records to some other DNS domains. In any case, it will cause confusion in the code and failures here and there.
For now you need to call ipa-client-install --domain=<the DNS domain you used as argument for IPA server install>.
ipa-client-install --domain=<the DNS domain you used as argument for IPA server install>
Also, I would recommend you to delete all IPA-related SRV records from DNS domains other than <the DNS domain you used as argument for IPA server install>.
<the DNS domain you used as argument for IPA server install>
I hope it will help.
Closing this as duplicate of ticket:5729 which should be the ultimate solution of this and other problems.
The problem was detected on RHEL 6 and is still present in RHEL 7.2.
Metadata Update from @spako: - Issue assigned to someone - Issue set to the milestone: 0.0 NEEDS_TRIAGE