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 <mailto: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
    <mailto: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
        <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@server ~]# hostname
        server
        [root@server ~]# hostname -f
        server.example.com <http://server.example.com>
        [root@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 ad...@example.com <mailto: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





    --
    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

Reply via email to