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