On 01/16/2017 01:47 AM, Daniel Schimpfoessl wrote:
Anything else I should look for?

Hi Daniel,

did you see this mail thread [1]? They had the same issue and found a temporary workaround to enable dogtag to connect to LDAP. If the workaround works, it definitely means that the issue comes from the secured communications between Dogtag and LDAP, and the following could be checked:

- LDAPs port 636 is enabled and answering
- The server certificate used by the LDAP server is valid (nickname 'Server-Cert' in /etc/dirsrv/slapd-DOMAIN) - The Server certificate used by the LDAP server has been delivered by a CA trusted by Dogtag (CA cert must be in /etc/pki/pki-tomcat/alias) - The certificate used by Dogtag to authenticate to LDAP (nickname subsystemCert cert-pki-ca in /etc/pki/pki-tomcat/alias) is valid and stored in a corresponding user entry in LDAP (uid=pkidbuser,ou=people,o=ipaca). - The certificates must match the ones in /etc/pki/pki-tomcat/ca/CS.cfg (line ca.signing.cert=... must match the CA cert and ca.subsystem.cert=... must match subsystemCert cert-pki-ca).

If the system is configured with SE linux mode = enforcing, it may explain the renewal issues (see BZ 1365188 [2] and 1366915 [3]).

[1] https://www.redhat.com/archives/freeipa-users/2017-January/msg00215.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1366915

2017-01-11 22:33 GMT-06:00 Daniel Schimpfoessl <dan...@schimpfoessl.com


    these are all the errors found:
    grep 'RESULT err=' access | perl -pe 's/.*(RESULT\s+err=\d+).*/$1/g'
    | sort -n | uniq -c | sort -n
          2 RESULT err=6
         95 RESULT err=32
        200 RESULT err=14
       2105 RESULT err=0

    2017-01-05 8:10 GMT-06:00 Florence Blanc-Renaud <f...@redhat.com

        On 01/04/2017 07:24 PM, Daniel Schimpfoessl wrote:

            From the logs:
            ... a few warnings about cache size, NSACLPLugin and
            [04/Jan/2017:12:14:21.392642021 -0600] slapd started.
            Listening on All
            Interfaces port 389 for LDAP requests

            ... lots of entries, not sure what to look for some lines
            contain RESULT
            with err!=0
            [04/Jan/2017:12:18:01.753400307 -0600] conn=5 op=243 RESULT
            tag=101 nentries=0 etime=0
            [04/Jan/2017:12:18:01.786928085 -0600] conn=44 op=1 RESULT
            err=14 tag=97
            nentries=0 etime=0, SASL bind in progress

        Hi Daniel,

        are there any RESULT err=48 that could correspond to the error
        seen on pki logs?


            [04/Jan/2017:12:19:25.566022098 -0600] slapd shutting down -
            operation threads - op stack size 5 max work q size 2 max
            work q stack
            size 2
            [04/Jan/2017:12:19:25.572566622 -0600] slapd shutting down -
            down internal subsystems and plugins

            2017-01-04 8:38 GMT-06:00 Daniel Schimpfoessl
            <dan...@schimpfoessl.com <mailto:dan...@schimpfoessl.com>

                Do you have a list of all log files involved in IPA?
                Would be good to consolidate them into ELK for analysis.

                2017-01-04 2:48 GMT-06:00 Florence Blanc-Renaud
            <f...@redhat.com <mailto:f...@redhat.com>
                <mailto:f...@redhat.com <mailto:f...@redhat.com>>>:

                    On 01/02/2017 07:24 PM, Daniel Schimpfoessl wrote:

                        Thanks for your reply.

                        This was the initial error I asked for help a
            while ago and
                        did not get
                        resolved. Further digging showed the recent errors.
                        The service was running (using ipactl start
            --force) and
                        only after a
                        restart I am getting a stack trace for two
            primary messages:

                        Could not connect to LDAP server host
            wwgwho01.webwim.com <http://wwgwho01.webwim.com>
                        <http://wwgwho01.webwim.com> port 636 Error
                        Authentication failed (48)

                        Internal Database Error encountered: Could not
            connect to
                        LDAP server
                        host wwgwho01.webwim.com
            <http://wwgwho01.webwim.com> <http://wwgwho01.webwim.com>
                        <http://wwgwho01.webwim.com> port 636 Error
                        netscape.ldap.LDAPException: Authentication
            failed (48)

                        and finally:

                        2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud
                        <f...@redhat.com <mailto:f...@redhat.com>
            <mailto:f...@redhat.com <mailto:f...@redhat.com>>
                        <mailto:f...@redhat.com <mailto:f...@redhat.com>
            <mailto:f...@redhat.com <mailto:f...@redhat.com>>>>:

                            systemctl start pki-tomcatd@pki-tomcat.service

                    Hi Daniel,

                    the next step would be to understand the root cause
            of this
                    "Authentication failed (48)" error. Note the exact
            time of this
                    log and look for a corresponding log in the LDAP
            server logs
                    (/var/log/dirsrv/slapd-DOMAIN-COM/access), probably
            a failing
                    BIND with err=48. This may help diagnose the issue
            (if we can
                    see which certificate is used for the bind or if
            there is a
                    specific error message).

                    For the record, a successful bind over SSL would
            produce this
                    type of log where we can see the certificate subject
            and the
                    user mapped to this certificate:
                    [...] conn=47 fd=84 slot=84 SSL connection from
                    [...] conn=47 TLS1.2 128-bit AES; client CN=CA
                    Subsystem,O=DOMAIN.COM <http://DOMAIN.COM>
            <http://DOMAIN.COM>; issuer
                    CN=Certificate Authority,O=DOMAIN.COM
            <http://DOMAIN.COM> <http://DOMAIN.COM>
                    [...] conn=47 TLS1.2 client bound as
                    [...] conn=47 op=0 BIND dn="" method=sasl version=3
                    [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to