[Freeipa-users] Asking for help with crashed freeIPA istance
Florence Blanc-Renaud
flo at redhat.com
Mon Jan 16 09:57:11 UTC 2017
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]).
Flo.
[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 <daniel at schimpfoessl.com
> <mailto:daniel at schimpfoessl.com>>:
>
> Flo,
>
> 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 <flo at redhat.com
> <mailto:flo at redhat.com>>:
>
> On 01/04/2017 07:24 PM, Daniel Schimpfoessl wrote:
>
> From the logs:
> /var/log/dirsrv/slapd-DOMAIN-COM/errors
> ... a few warnings about cache size, NSACLPLugin and
> schema-compat-plugin
> [04/Jan/2017:12:14:21.392642021 -0600] slapd started.
> Listening on All
> Interfaces port 389 for LDAP requests
>
> /var/log/dirsrv/slapd-DOMAIN-COM/access
> ... 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
> err=32
> 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?
>
> Flo
>
> /var/log/dirsrv/slapd-DOMAIN-COM/errors
> [04/Jan/2017:12:19:25.566022098 -0600] slapd shutting down -
> signaling
> 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 -
> closing
> down internal subsystems and plugins
>
>
> 2017-01-04 8:38 GMT-06:00 Daniel Schimpfoessl
> <daniel at schimpfoessl.com <mailto:daniel at schimpfoessl.com>
> <mailto:daniel at schimpfoessl.com
> <mailto:daniel at 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
> <flo at redhat.com <mailto:flo at redhat.com>
> <mailto:flo at redhat.com <mailto:flo at 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>
> <http://wwgwho01.webwim.com> port 636 Error
> netscape.ldap.LDAPException:
> 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:
> [02/Jan/2017:12:20:34][localhost-startStop-1]:
> CMSEngine.shutdown()
>
>
> 2017-01-02 3:45 GMT-06:00 Florence Blanc-Renaud
> <flo at redhat.com <mailto:flo at redhat.com>
> <mailto:flo at redhat.com <mailto:flo at redhat.com>>
> <mailto:flo at redhat.com <mailto:flo at redhat.com>
> <mailto:flo at redhat.com <mailto:flo at redhat.com>>>>:
>
> systemctl start pki-tomcatd at 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
> 10.34.58.150 to
> 10.34.58.150
> [...] 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
> uid=pkidbuser,ou=people,o=ipaca
> [...] conn=47 op=0 BIND dn="" method=sasl version=3
> mech=EXTERNAL
> [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0
> etime=0
> dn="uid=pkidbuser,ou=people,o=ipaca"
>
> Flo
>
>
>
>
>
>
More information about the Freeipa-users
mailing list