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 <dan...@schimpfoessl.com
<mailto:dan...@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 <f...@redhat.com
<mailto:f...@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
<dan...@schimpfoessl.com <mailto:dan...@schimpfoessl.com>
<mailto: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>
<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
<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
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
--
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
