<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/08/2014 12:21 PM, brendan kearney
wrote:<br>
</div>
<blockquote
cite="mid:CAARxGtj5ywPvnnv43+F2WVbsMhwEqkQQocMsoWa-N-GJefnqLQ@mail.gmail.com"
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
cite="mid:CAARxGtj5ywPvnnv43+F2WVbsMhwEqkQQocMsoWa-N-GJefnqLQ@mail.gmail.com"
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
cite="mid:CAARxGtj5ywPvnnv43+F2WVbsMhwEqkQQocMsoWa-N-GJefnqLQ@mail.gmail.com"
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
cite="mid:CAARxGtj5ywPvnnv43+F2WVbsMhwEqkQQocMsoWa-N-GJefnqLQ@mail.gmail.com"
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">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>
</body>
</html>