#4305 ipa-server-install runs the IPA-self-enrollment part which can autodiscover completely different server due to realm/domain clash
Closed: Fixed None by adelton. Opened 4 years ago by adelton.

I have run ipa-server-install for testing purposes with domain and realm of existing domain.

The command failed with

Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain the-domain.net --server the-hostname --realm THE_REALM --hostname the-hostname' returned non-zero exit status 1

and in the /var/log/ipaclient-install.log I've found

2014-04-08T19:20:57Z DEBUG Starting IPA discovery with domain=the-domain.net, servers=['the-hsotname'], hostname=the-hostname
2014-04-08T19:20:57Z DEBUG Server and domain forced
2014-04-08T19:20:57Z DEBUG [Kerberos realm search]
2014-04-08T19:20:57Z DEBUG Search DNS for TXT record of _kerberos.the-domain.net
2014-04-08T19:20:57Z DEBUG DNS record found: "v=spf1 -all"
2014-04-08T19:20:57Z DEBUG Search DNS for SRV record of _kerberos._udp.v=spf1 -all
2014-04-08T19:20:57Z DEBUG DNS record not found: NXDOMAIN
2014-04-08T19:20:57Z DEBUG SRV record for KDC not found! Realm: v=spf1 -all, SRV record: _kerberos.the-domain.net
2014-04-08T19:20:57Z DEBUG [LDAP server check]
2014-04-08T19:20:57Z DEBUG Verifying that the-hostname (realm v=spf1 -all) is an IPA server
2014-04-08T19:20:57Z DEBUG Init LDAP connection to: the-hostname
2014-04-08T19:20:57Z DEBUG Search LDAP server for IPA base DN
2014-04-08T19:20:57Z DEBUG Check if naming context 'dc=the-realm,dc=net' is for IPA
2014-04-08T19:20:57Z DEBUG Naming context 'dc=the-realm,dc=net' is a valid IPA context
2014-04-08T19:20:57Z DEBUG Search for (objectClass=krbRealmContainer) in dc=the-realm,dc=net (sub)
2014-04-08T19:20:57Z DEBUG Found: cn=THE-REALM.NET,cn=kerberos,dc=the-realm,dc=net
2014-04-08T19:20:57Z WARNING Skip the-hostname: cannot verify if this is an IPA server
2014-04-08T19:20:57Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, domain=the-domain.net, kdc=None, basedn=dc=the-realm,dc=net
2014-04-08T19:20:57Z DEBUG Validated servers: 
2014-04-08T19:20:57Z ERROR Failed to verify that the-hostname is an IPA Server.
2014-04-08T19:20:57Z ERROR This may mean that the remote server is not up or is not reachable due to network or firewall settings.

(Domain, REALM, and hostname censored; ping me if you need the exact values.)

I understand that I should use LAN.TEST or something similar for testing but on the other hand, the use case may be admin preparing the replacement of existing production environment, in which case the IPA server installation process should not contact the existing environment.

In other words, if the --on-master ipa-client-install is run, it really should talk to its own master and not get confused by autodiscovery.


I think the problems start in this part:

2014-04-08T19:20:57Z DEBUG [Kerberos realm search]
2014-04-08T19:20:57Z DEBUG Search DNS for TXT record of _kerberos.the-domain.net
2014-04-08T19:20:57Z DEBUG DNS record found: "v=spf1 -all"
2014-04-08T19:20:57Z DEBUG Search DNS for SRV record of _kerberos._udp.v=spf1 -all
2014-04-08T19:20:57Z DEBUG DNS record not found: NXDOMAIN
2014-04-08T19:20:57Z DEBUG SRV record for KDC not found! Realm: v=spf1 -all, SRV record: _kerberos.the-domain.net

I wonder why we do search for TXT and SRV records of the domain when we are running --on-master and have all values passed in by ipa-server-install

During processing of remaining tickets in 4.2 Backlog, this ticket was found as suitable to be fixed in the nearest bugfixing branch - which is 4.2.x.

FreeIPA 4.2.1 was released, moving to 4.2.x.

Just FYI, it probably grants a separate ticket but worth mentioning here since it crossed my horizon...

Consider the following use case: an admin wants to deploy an IPA as a CA. He does not want to use this IPA instance for anything else other than a CA. On the other side this CA is on a machine that it a part of a different IPA domain. In this case the IPA CA instance should actually do not touch the SSSD configuration that is already there from the time the machine was configured as a member of the different domain.

A different RFE I assume?

Definitely. The separate CA use case will be a bigger beast to tame.

ipa-4-3:

  • b81f333 only search for Kerberos SRV records when autodiscovery was requested

master:

  • 8290d4b only search for Kerberos SRV records when autodiscovery was requested

Metadata Update from @adelton:
- Issue assigned to mbabinsk
- Issue set to the milestone: FreeIPA 4.3.1

2 years ago

Login to comment on this ticket.

Metadata