[Freeipa-users] FreeIPA and FQDN requirements

Fri Aug 8 18:21:20 UTC 2014

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.

I have not run across a client that does cert validation using ldap.  Is
that IPA specific?

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.
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/544e2990/attachment.htm>