[Freeipa-users] FreeIPA and FQDN requirements
Rich Megginson
rmeggins at redhat.com
Fri Aug 8 19:29:57 UTC 2014
On 08/08/2014 01:16 PM, brendan kearney wrote:
>
> Maybe I am reading too far into rfc 1178,
>
http://tools.ietf.org/html/rfc1178
"This memo provides information for the Internet
community. It does not specify any standard."
I guess the upshot is - if you think that FreeIPA is being too
restrictive with its default policies about fqdn requirements for
hostnames, please file ticket(s) accordingly.
> 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
> <mailto: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
>> <mailto: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 <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/67140ab8/attachment.htm>
More information about the Freeipa-users
mailing list