Hello,
On 8.8.2014 21:16, brendan kearney wrote:
Maybe I am reading too far into rfc 1178, 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
First of all, feel free to experiment with FreeIPA and let us know what we did
wrong. Messages like 'I have removed all the checks and it still passes all
test even with short name!' are welcome :-)
As you said, Kerberos technically does not require FQDN but it is important to
note that the machine name have to be stable and unique inside given Kerberos
realm because the name is used as lookup key in keytab file and KDC database.
Assume that FQDN is constructed as static hostname.domainname from DHCP or via
reverse DNS lookup. What happens if the machine (laptop) moves from one
network to another? What if the machine have multiple interfaces?
As a result, any change in FQDN will break your Kerberos setup.
See $ man 1 domainname
" THE FQDN
[...]
If a machine has multiple network interfaces/addresses or is used in a mobile
environment, then it may either have multiple FQDNs/domain names or none at
all. Therefore avoid using hostname --fqdn, hostname --domain and
dnsdomainname. hostname --ip-address is subject to the same limitations so it
should be avoided as well.
"
Ideas and patches solving this problem are welcome. Have a nice day!
Petr^2 Spacek
On Aug 8, 2014 2:37 PM, "Rich Megginson" <rmegg...@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" <rmegg...@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" <rmegg...@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" <rmegg...@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@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-barb...@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@server ~]# hostname
server
[root@server ~]# hostname -f
server.example.com
[root@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 ad...@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
