[Freeipa-users] FreeIPA and FQDN requirements

Simo Sorce simo at redhat.com
Fri Aug 8 20:51:05 UTC 2014 

On Fri, 2014-08-08 at 15:16 -0400, brendan kearney wrote:
> Maybe I am reading too far into rfc 1178, but I hardly think making
> hostnames required to be fqdns is in anybodys interest.  It is not a
> requirement now in any other technology anywhere, so what is the impetus to
> push it?  I dont see any value in it

A number of kerberized services used to use gethostname() and then
troll /etc/krb5.keytab to find a suitable key. This obviously fail if
your hostname is not a fqdn.

Now in time we are trying to avoid application from using direct
kerberos calls and for GSSAPI applications that still insist using
gethostname() to construct the local server name and the pass it to the
acceptor (for example openssh) we have the little hack of setting
ignore_acceptor_hostname top true ion krb5.conf

I think we are getting close to be able to work without forcing the
hostname to be a fqdn on the client, provided you have a way to tell
what is the fqdn at freeipa-client-install time.

We did not want to force all machines to belong to the same DNS domain
as the kerberos realm so we cannot do like windows and force the fqdn to
be lower(hostname.REALM) like windows does.

Perhaps we could use hostname -f and hope we get something sensible on
join or simply force users to always pass --hostname

Please open a RFE to consider dropping the requirement on the client.

Simo.

> On Aug 8, 2014 2:37 PM, "Rich Megginson" <rmeggins at redhat.com> wrote:
> 
> >  On 08/08/2014 12:21 PM, brendan kearney wrote:
> >
> > Double check your example.  -h means the hostname of the ldap server to
> > connect to and issue your query to.  Man page calls it ldaphost.
> >
> >
> > Yes.
> >
> >  I have not run across a client that does cert validation using ldap.  Is
> > that IPA specific?
> >
> >
> > I'm not talking about cert validation using ldap.  I'm talking about the
> > fact that, by default, the ldapsearch client will expect the hostname you
> > pass in to match the hostname in the ssl server cert subject DN.
> >
> >  It seems that a lot of effort is being spent to justify a dependency on
> > fully qualified hostnames, when there is no reason to require it.  In fact,
> > it may even break somethings or even violate some rfc.
> >
> >
> > If requiring fully qualified hostnames violates RFCs or other standards,
> > I'd like to hear about it.
> >
> >  On Aug 8, 2014 1:43 PM, "Rich Megginson" <rmeggins at redhat.com> wrote:
> >
> >>  On 08/08/2014 11:17 AM, brendan kearney wrote:
> >>
> >> The cert should have the fqdn, just like the kerberos instance, but the
> >> hostname is not required to be fq'd.  The lookup of a short name, as well
> >> as and more specifically the IP, in dns will result in the fqdn being
> >> returned by dns (the short name resolution being affected by domain and
> >> search directives in resolv.conf and the origin directive in dns if either
> >> of those are absent).
> >>
> >> Back to the point, dns lookup for cert matching is not dependent on
> >> hostnames.  PTR lookups will always return fqdns, so a dependency on fqdns
> >> as hostnames is artificial,  no?
> >>
> >>
> >> Most clients will also do the additional step of matching the hostname in
> >> the cert against the originally given hostname.  For example, with
> >> ldapsearch:
> >>
> >> ldapsearch -xLLLZZ -h hostname ...
> >>
> >> This will fail if the server cert for hostname has
> >> "cn=hostname.domain.tld"
> >>
> >>  On Aug 8, 2014 1:03 PM, "Rich Megginson" <rmeggins at redhat.com> wrote:
> >>
> >>>  On 08/08/2014 10:56 AM, brendan kearney wrote:
> >>>
> >>> Arent all of those lookups done in dns?
> >>>
> >>>
> >>> Yes.
> >>>
> >>>  Wouldnt that mean hostnames being fqdn's is irrelevant?
> >>>
> >>>
> >>> Not sure what you mean.
> >>>
> >>> I guess if you issued your server certs with a subject DN of
> >>> "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR
> >>> lookups configured so that w.x.y.z returned "hostname" instead of
> >>> "hostname.domain.tld", then TLS/SSL would work.
> >>>
> >>>  On Aug 8, 2014 12:11 PM, "Rich Megginson" <rmeggins at redhat.com> wrote:
> >>>
> >>>>  On 08/08/2014 08:57 AM, brendan kearney wrote:
> >>>>
> >>>> Kerberos is dependent on A records in dns.  The instance (as in
> >>>> principal/instance at REALM) should match the A record in dns.
> >>>>
> >>>> There is absolutely no Kerberos dependency on hostnames being fully
> >>>> qualified.  I have all my devices named with short names and I have no
> >>>> issues with Kerberos ticketing.
> >>>>
> >>>> This seems to be an artificial requirement in FreeIPA that is wrong.
> >>>>
> >>>>
> >>>> The other hostname requirement is for TLS/SSL, for MITM checking.  By
> >>>> default, when an SSL server cert is issued, the subject DN contains cn=fqdn
> >>>> as the leftmost component.  clients use this fqdn to verify the server.
> >>>> That is, client knows the IP address of the server - client does a reverse
> >>>> lookup (i.e. PTR) to see if the server returned by that lookup matches the
> >>>> cn=fqdn in the server cert.  This requires reverse lookups are configured
> >>>> and that the fqdn is the first name/alias returned.
> >>>>
> >>>>  On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" <
> >>>> bruno-barbosa at prodesan.com.br> wrote:
> >>>>
> >>>>>  Hello everyone,
> >>>>>
> >>>>> I'm running through an issue where an application needs its server's
> >>>>> hostname to be in short name format, such as "server" and not "
> >>>>> server.example.com". When I started deploying FreeIPA in the very
> >>>>> beginning of this year, I remember I couldn't install freeipa-client with a
> >>>>> bare "ipa-client install", because of this:
> >>>>>
> >>>>> ____________
> >>>>>
> >>>>> [root at server ~]# hostname
> >>>>> server
> >>>>> [root at server ~]# hostname -f
> >>>>> server.example.com
> >>>>> [root at server ~]# ipa-client-install
> >>>>> Discovery was successful!
> >>>>> Hostname: server.example.com
> >>>>> Realm: EXAMPLE.COM
> >>>>> DNS Domain: example.com
> >>>>> IPA Server: ipa01.example.com
> >>>>> Base DN: dc=example,dc=com
> >>>>>
> >>>>> Continue to configure the system with these values? [no] yes
> >>>>> User authorized to enroll computers: admin
> >>>>> Synchronizing time with KDC...
> >>>>> Unable to sync time with IPA NTP Server, assuming the time is in sync.
> >>>>> Please check that port 123 UDP is opened.
> >>>>> Password for admin at EXAMPLE.COM:
> >>>>> Joining realm failed: The hostname must be fully-qualified: server
> >>>>> Installation failed. Rolling back changes.
> >>>>> IPA client is not configured on this system.
> >>>>>
> >>>>> ________________
> >>>>>
> >>>>> So, using the short name as hostname didn't work for install, I then
> >>>>> make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N",
> >>>>> and it installs and works like a charm, BUT it updates the machine's
> >>>>> hostname to FQDN.
> >>>>>
> >>>>> What I tested and, at first, worked: after deploying and ipa-client
> >>>>> installation with those parameters which work, renaming the machine back to
> >>>>> a short name AT FIRST is not causing any problems. I can login with my ssh
> >>>>> rules perfectly, but I don't find any IPA technical docs saying it
> >>>>> will/won't work if I change the hostname back to short name and not FQDN.
> >>>>>
> >>>>> Searching for it, I found on RedHat guide: "The hostname of a system
> >>>>> is critical for the correct operation of Kerberos and SSL. Both of these
> >>>>> security mechanisms rely on the hostname to ensure that communication is
> >>>>> occurring between the specified hosts."
> >>>>> I've also found this message
> >>>>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems
> >>>>> to be related to my case, but what I need to know is: where does it state
> >>>>> FQDN is a mandatory requirement in order to FreeIPA to work and/or is there
> >>>>> anything else (a patch, update, whatever) to solve this issue, so I don't
> >>>>> need to change my applications?
> >>>>>
> >>>>> Thank you and sorry for the wall of a text.
> >>>>>
> >>>>> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is
> >>>>> not the same server as IPA (it forwards to a Windows DC).
> >>>>>
> >>>>> RPMs:
> >>>>> libipa_hbac-1.9.2-129.el6_5.4.x86_64
> >>>>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64
> >>>>> python-iniparse-0.3.1-2.1.el6.noarch
> >>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch
> >>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> >>>>> ipa-admintools-3.0.0-37.el6.x86_64
> >>>>> ipa-server-selinux-3.0.0-37.el6.x86_64
> >>>>> ipa-server-3.0.0-37.el6.x86_64
> >>>>> ipa-python-3.0.0-37.el6.x86_64
> >>>>> ipa-client-3.0.0-37.el6.x86_64
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Manage your subscription for the Freeipa-users mailing list:
> >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
> >>>>> Go To http://freeipa.org for more info on the project
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Manage your subscription for the Freeipa-users mailing list:
> >>>> https://www.redhat.com/mailman/listinfo/freeipa-users
> >>>> Go To http://freeipa.org for more info on the project
> >>>>
> >>>
> >>>
> >>
> >


-- 
Simo Sorce * Red Hat, Inc * New York

More information about the Freeipa-users mailing list