Ian Harding wrote: > On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote: >> On 08/01/2017 03:11 PM, Ian Harding wrote: >>> On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote: >>>> On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote: >>>>> >>>>> >>>>> On 07/31/2017 11:34 AM, Rob Crittenden wrote: >>>>>> Ian Harding via FreeIPA-users wrote: >>>>>>> I had an unexpected restart of an IPA server that had apparently had >>>>>>> updates run but had not been restarted. ipactl says pki-tomcatd >>>>>>> would >>>>>>> not start. >>>>>>> >>>>>>> Strangely, the actual service appears to be running: >>>>>>> >>>>>> >>>>>> dogtag is an application within tomcat so tomcat can run without >>>>>> dogtag >>>>>> running. >>>>>> >>>>>> We need to see more of the dogtag debug log to see what is going on. >>>>>> >>>>> >>>>> It looks like an authentication problem... >>>>> >>>>> [28/Jul/2017:10:08:47][localhost-startStop-1]: SSL handshake happened >>>>> Could not connect to LDAP server host seattlenfs.bpt.rocks port 636 >>>>> Error netscape.ldap.LDAPException: Authentication failed (49) >>>>> >>>> >>>> Hi, >>>> >>>> dogtag stores its internal data in the LDAP server and needs to >>>> establish a secure LDAP connection. You can check how this >>>> connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, look for >>>> the lines: >>>> >>>> internaldb.ldapauth.authtype=SslClientAuth >>>> internaldb.ldapauth.bindDN=cn=Directory Manager >>>> internaldb.ldapauth.bindPWPrompt=internaldb >>>> internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca >>>> internaldb.ldapconn.host=vm-... >>>> internaldb.ldapconn.port=636 >>>> internaldb.ldapconn.secureConn >>>> >>>> authtype can be SslClientAuth (authentication with a ssl >>>> certificate) or BasicAuth (authentication with a bind DN and >>>> password stored in /var/lib/pki/pki-tomcat/conf/password.conf). >>>> >>>> You can use this information to manually check the credentials. For >>>> instance with sslclientauth: >>>> >>>> export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias >>>> export LDAPTLS_CERT='subsystemCert cert-pki-ca' >>>> >>>> ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL >>>> (provide the password from /etc/pki/pki-tomcat/alias/pwdfile.txt) >>>> >>> >>> I found this: >>> >>> internaldb.ldapauth.authtype=SslClientAuth >>> internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca >>> internaldb.ldapauth.bindPWPrompt=internaldb >>> internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca >>> internaldb.ldapconn.cloneReplicationPort=389 >>> ... >>> >>> and when I try the ldapsearch I am presented with a prompt to provide >>> a pin/password >>> >>> Please enter pin, password, or pass phrase for security token 'ldap(0)': >>> >>> but there is no password file... >>> >> Hi, >> >> you are right, in 4.4. there is no pwdfile.txt and the password can be >> found in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag >> internal=...) >> >> Can you check if the password with the tag internal=... allows to read >> the keys from the NSS db? >> certutil -K -d /etc/pki/pki-tomcat/alias >> (provide password) > > That works... > > # certutil -K -d /etc/pki/pki-tomcat/alias > certutil: Checking token "NSS Certificate DB" in slot "NSS User Private > Key and Certificate Services" > Enter Password or Pin for "NSS Certificate DB": > < 0> rsa 0f327e760a7eecdcf6973f5dc57ca5367c592d64 (orphan) > < 1> rsa b12580c7c696cfcd8aefc9405a7a870b24b7b96a NSS Certificate > DB:auditSigningCert cert-pki-ca > < 2> rsa 881b7254c40fa40bc50681bcc8d37bb3eb49937e caSigningCert > cert-pki-ca > < 3> rsa fa9a255a1d15585ac28064c0f4986e416bc48403 NSS Certificate > DB:ocspSigningCert cert-pki-ca > < 4> rsa 3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f Server-Cert > cert-pki-ca > < 5> rsa 1e9479a9556af9339bb5e4552ccbd381d3c38856 NSS Certificate > DB:subsystemCert cert-pki-ca > > But this doesn't (with the same password from password.conf) > > # ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL > Please enter pin, password, or pass phrase for security token 'ldap(0)': > SASL/EXTERNAL authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > > That password is getting me somewhere though, since if I put in a > nonsense or incorrect password it just prompts over and over.
Let's step back a second. You upgraded from what to what? Are you running in SELinux enforcing mode? If so can you run: # ausearch -m AVC I suspect that the subsystem cert was renewed and everything wasn't updated properly. If I'm right this is unrelated to the upgrade it just shone a spotlight on it. Can you run these commands: $ ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate description and # certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep Serial # certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a The description attribute in the ldapsearch output is of the form 2;#;DN;DN The # should match the serial number in the first certutil output The ASCII blob (minus the BEGIN/END headers) should match one of the userCertificate attributes. rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
