[Freeipa-users] FreeIPA and FQDN requirements

Fri Aug 8 17:43:11 UTC 2014

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 
> <mailto: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
>>     <mailto: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
>>>         <mailto: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
>>>             <http://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 <http://server.example.com>
>>>             [root at server ~]# ipa-client-install
>>>             Discovery was successful!
>>>             Hostname: server.example.com <http://server.example.com>
>>>             Realm: EXAMPLE.COM <http://EXAMPLE.COM>
>>>             DNS Domain: example.com <http://example.com>
>>>             IPA Server: ipa01.example.com <http://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 <mailto: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
>>
>

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