[Freeipa-users] FreeIPA and FQDN requirements

Fri Aug 8 19:16:50 UTC 2014

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
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
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140808/0879f958/attachment.htm>