[Freeipa-users] FreeIPA and FQDN requirements
Rich Megginson
rmeggins at redhat.com
Fri Aug 8 17:03:06 UTC 2014
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/03d17ce0/attachment.htm>
More information about the Freeipa-users
mailing list