On 08/08/2014 01:16 PM, brendan kearney wrote:


Maybe I am reading too far into rfc 1178,


http://tools.ietf.org/html/rfc1178
"This memo provides information for the Internet
   community.  It does not specify any standard."

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.

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

On Aug 8, 2014 2:37 PM, "Rich Megginson" <rmegg...@redhat.com <mailto: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
    <mailto: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 <mailto: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 <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