<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/08/2014 01:16 PM, brendan kearney
wrote:<br>
</div>
<blockquote
cite="mid:CAARxGtjRm=A80v1hEM4hoj6mWW8NZpPYtsXR7X2PjnOKU_nwSg@mail.gmail.com"
type="cite">
<p dir="ltr">Maybe I am reading too far into rfc 1178,</p>
</blockquote>
<br>
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc1178">http://tools.ietf.org/html/rfc1178</a><br>
"This memo provides information for the Internet<br>
community. It does not specify any standard."<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAARxGtjRm=A80v1hEM4hoj6mWW8NZpPYtsXR7X2PjnOKU_nwSg@mail.gmail.com"
type="cite">
<p dir="ltr">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</p>
<div class="gmail_quote">On Aug 8, 2014 2:37 PM, "Rich Megginson"
<<a moz-do-not-send="true" href="mailto:rmeggins@redhat.com">rmeggins@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 08/08/2014 12:21 PM, brendan kearney wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">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.</p>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote type="cite">
<p dir="ltr">I have not run across a client that does cert
validation using ldap. Is that IPA specific?</p>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite">
<p dir="ltr">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.</p>
</blockquote>
<br>
If requiring fully qualified hostnames violates RFCs or
other standards, I'd like to hear about it.<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">On Aug 8, 2014 1:43 PM, "Rich
Megginson" <<a moz-do-not-send="true"
href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 08/08/2014 11:17 AM, brendan kearney wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">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).</p>
<p dir="ltr">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?</p>
</blockquote>
<br>
Most clients will also do the additional step of
matching the hostname in the cert against the
originally given hostname. For example, with
ldapsearch:<br>
<br>
ldapsearch -xLLLZZ -h hostname ...<br>
<br>
This will fail if the server cert for hostname has
"cn=hostname.domain.tld"<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">On Aug 8, 2014 1:03 PM,
"Rich Megginson" <<a moz-do-not-send="true"
href="mailto:rmeggins@redhat.com"
target="_blank">rmeggins@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 08/08/2014 10:56 AM, brendan kearney
wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Arent all of those lookups
done in dns?</p>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote type="cite">
<p dir="ltr">Wouldnt that mean hostnames
being fqdn's is irrelevant? </p>
</blockquote>
<br>
Not sure what you mean.<br>
<br>
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.<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">On Aug 8, 2014
12:11 PM, "Rich Megginson" <<a
moz-do-not-send="true"
href="mailto:rmeggins@redhat.com"
target="_blank">rmeggins@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 08/08/2014 08:57 AM, brendan
kearney wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Kerberos is dependent
on A records in dns. The
instance (as in
principal/instance@REALM) should
match the A record in dns.</p>
<p dir="ltr">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.</p>
<p dir="ltr">This seems to be an
artificial requirement in
FreeIPA that is wrong.</p>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">On Aug 8,
2014 8:54 AM, "Bruno Henrique
Barbosa" <<a
moz-do-not-send="true"
href="mailto:bruno-barbosa@prodesan.com.br"
target="_blank">bruno-barbosa@prodesan.com.br</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div
style="font-family:tahoma,new
york,times,serif;font-size:12pt;color:#000000">Hello everyone,<br>
<br>
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 "<a
moz-do-not-send="true"
href="http://server.example.com"
target="_blank">server.example.com</a>".
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:<br>
<br>
____________<br>
<br>
[root@server ~]# hostname<br>
server<br>
[root@server ~]# hostname
-f<br>
<a moz-do-not-send="true"
href="http://server.example.com" target="_blank">server.example.com</a><br>
[root@server ~]#
ipa-client-install<br>
Discovery was successful!<br>
Hostname: <a
moz-do-not-send="true"
href="http://server.example.com"
target="_blank">server.example.com</a><br>
Realm: <a
moz-do-not-send="true"
href="http://EXAMPLE.COM"
target="_blank">EXAMPLE.COM</a><br>
DNS Domain: <a
moz-do-not-send="true"
href="http://example.com"
target="_blank">example.com</a><br>
IPA Server: <a
moz-do-not-send="true"
href="http://ipa01.example.com"
target="_blank">ipa01.example.com</a><br>
Base DN: dc=example,dc=com<br>
<br>
Continue to configure the
system with these values?
[no] yes<br>
User authorized to enroll
computers: admin<br>
Synchronizing time with
KDC...<br>
Unable to sync time with
IPA NTP Server, assuming
the time is in sync.
Please check that port 123
UDP is opened.<br>
Password for <a
moz-do-not-send="true"
href="mailto:admin@EXAMPLE.COM"
target="_blank">admin@EXAMPLE.COM</a>:
<br>
Joining realm failed: The
hostname must be
fully-qualified: server<br>
Installation failed.
Rolling back changes.<br>
IPA client is not
configured on this system.<br>
<br>
________________<br>
<br>
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.<br>
<br>
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.<br>
<br>
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."<br>
I've also found this
message <a
moz-do-not-send="true"
href="http://osdir.com/ml/freeipa-users/2012-03/msg00006.html"
target="_blank">http://osdir.com/ml/freeipa-users/2012-03/msg00006.html</a>
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?<br>
<br>
Thank you and sorry for
the wall of a text.<br>
<br>
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).<br>
<br>
RPMs:<br>
libipa_hbac-1.9.2-129.el6_5.4.x86_64<br>
libipa_hbac-python-1.9.2-129.el6_5.4.x86_64<br>
python-iniparse-0.3.1-2.1.el6.noarch<br>
ipa-pki-common-theme-9.0.3-7.el6.noarch<br>
ipa-pki-ca-theme-9.0.3-7.el6.noarch<br>
ipa-admintools-3.0.0-37.el6.x86_64<br>
ipa-server-selinux-3.0.0-37.el6.x86_64<br>
ipa-server-3.0.0-37.el6.x86_64<br>
ipa-python-3.0.0-37.el6.x86_64<br>
ipa-client-3.0.0-37.el6.x86_64<br>
<br>
<br>
</div>
</div>
<br>
--<br>
Manage your subscription for
the Freeipa-users mailing
list:<br>
<a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/freeipa-users"
target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go To <a
moz-do-not-send="true"
href="http://freeipa.org"
target="_blank">http://freeipa.org</a>
for more info on the project<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
</div>
<br>
--<br>
Manage your subscription for the
Freeipa-users mailing list:<br>
<a moz-do-not-send="true"
href="https://www.redhat.com/mailman/listinfo/freeipa-users"
target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go To <a moz-do-not-send="true"
href="http://freeipa.org"
target="_blank">http://freeipa.org</a>
for more info on the project<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>