I do not believe I changed the DM password. I know I had to update the admin passwords regularly.
Only during the startup using ipactl start --force I am able to connect to the service using the password for DM and it returns: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top namingContexts: cn=changelog namingContexts: dc=myorg,dc=com namingContexts: o=ipaca defaultnamingcontext: dc=myorg,dc=com supportedExtension: 2.16.840.1.1137126.96.36.199 supportedExtension: 2.16.840.1.1137188.8.131.52 supportedExtension: 2.16.840.1.1137184.108.40.206 supportedExtension: 2.16.840.1.1137220.127.116.11.3 supportedExtension: 2.16.840.1.113718.104.22.168.4 supportedExtension: 2.16.840.1.113722.214.171.124.4.1 supportedExtension: 126.96.36.199.4.1.4188.8.131.52 supportedExtension: 2.16.840.1.1137184.108.40.206.1 supportedExtension: 2.16.840.1.1137220.127.116.11.5 supportedExtension: 2.16.840.1.113718.104.22.168 supportedExtension: 2.16.840.1.113722.214.171.124 supportedExtension: 2.16.840.1.1137126.96.36.199 supportedExtension: 2.16.840.1.1137188.8.131.52 supportedExtension: 2.16.840.1.1137184.108.40.206 supportedExtension: 2.16.840.1.1137220.127.116.11 supportedExtension: 2.16.840.1.113718.104.22.168 supportedExtension: 2.16.840.1.113722.214.171.124 supportedExtension: 2.16.840.1.1137126.96.36.199 supportedExtension: 2.16.840.1.1137188.8.131.52 supportedExtension: 184.108.40.206.4.1.1466.20037 supportedControl: 2.16.840.1.1137220.127.116.11 supportedControl: 2.16.840.1.113718.104.22.168 supportedControl: 2.16.840.1.113722.214.171.124 supportedControl: 2.16.840.1.1137126.96.36.199 supportedControl: 1.2.840.1135188.8.131.523 supportedControl: 2.16.840.1.1137184.108.40.206 supportedControl: 2.16.840.1.1137220.127.116.11 supportedControl: 2.16.840.1.113718.104.22.168 supportedControl: 2.16.840.1.113722.214.171.124 supportedControl: 2.16.840.1.1137126.96.36.199 supportedControl: 188.8.131.52.1.13.1 supportedControl: 184.108.40.206.1.13.2 supportedControl: 220.127.116.11.18.104.22.168.22.214.171.124 supportedControl: 126.96.36.199.188.8.131.52.184.108.40.206 supportedControl: 1.2.840.1135220.127.116.119 supportedControl: 18.104.22.168.22.214.171.124.126.96.36.199 supportedControl: 188.8.131.52.4.1.4203.666.5.16 supportedControl: 2.16.840.1.1137184.108.40.206.6 supportedControl: 2.16.840.1.1137220.127.116.11 supportedControl: 2.16.840.1.113718.104.22.168 supportedControl: 22.214.171.124.4.1.1466.29539.12 supportedControl: 2.16.840.1.1137126.96.36.199 supportedControl: 2.16.840.1.1137188.8.131.52 supportedControl: 2.16.840.1.1137184.108.40.206 supportedControl: 220.127.116.11.4.1.418.104.22.168.1 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: ANONYMOUS supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/22.214.171.124 B2016.215.1556 dataversion: 020161222235947020161222235947020161222235947 netscapemdsuffix: cn=ldap://dc=wwgwho01,dc=myorg,dc=com:389 lastusn: 8690425 changeLog: cn=changelog firstchangenumber: 2752153 lastchangenumber: 2752346 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 2016-12-21 9:27 GMT-06:00 Rob Crittenden <rcrit...@redhat.com>: > Daniel Schimpfoessl wrote: > > Thanks for getting back to me. > > > > getcert list | grep expires shows dates years in the future for all > > certificates > > Inline-Bild 1 > > > > ipactl start --force > > > > Eventually the system started with: > > Forced start, ignoring pki-tomcatd Service, continuing normal > > operations. > > > > systemctl status ipa shows: failed > > I don't think this is a certificate problem at all. I think the timing > with your renewal is just coincidence. > > Did you change your Directory Manager password at some point? > > > > > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > > password -b "" -s base > > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > > *********** -b "" -s base > > Inline-Bild 2 > > You need the -x flag to indicate simple bind. > > rob > > > The logs have thousands of lines like it, what am I looking for > > specifically? > > > > Daniel > > > > > > 2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud <f...@redhat.com > > <mailto:f...@redhat.com>>: > > > > On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote: > > > > Good day and happy holidays, > > > > I have been running a freeIPA instance for a few years and been > very > > happy. Recently the certificate expired and I updated it using > the > > documented methods. At first all seemed fine. Added a Nagios > > monitor for > > the certificate expiration and restarted the server (single > > server). I > > have weekly snapshots, daily backups (using Amanda on the entire > > disk). > > > > One day the services relying on IPA failed to authenticate. > > Looking at > > the server the ipa service had stopped. Restarting the service > > fails. > > Restoring a few weeks old snapshot does not start either. > > Resetting the > > date to a few month back does not work either as httpd fails to > > start . > > > > I am at a loss. > > > > Here a few details: > > # ipa --version > > VERSION: 4.4.0, API_VERSION: 2.213 > > > > > > # /usr/sbin/ipactl start > > ... > > out -> Failed to start pki-tomcatd Service > > /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP > server > > host ipa.myorg.com <http://ipa.myorg.com> <http://ipa.myorg.com> > > port 636 Error > > netscape.ldap.LDAPException: Authentication failed (48) > > 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted > > due to > > error: Retrieving CA status failed with status 500 > > > > Any help would be appreciated as all connected services are now > > down. > > > > Thanks, > > > > Daniel > > > > > > > > > > Hi Daniel, > > > > more information would be required to understand what is going on. > > First of all, which certificate did you renew? Can you check with > > $ getcert list > > if other certificates also expired? > > > > PKI fails to start and the error seems linked to the SSL connection > > with the LDAP server. You may want to check if the LDAP server is > > listening on the LDAPs port: > > - start the stack with > > $ ipactl start --force > > - check the LDAPs port with > > $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > > password -b "" -s base > > > > The communication between PKI and the LDAP server is authenticated > > with the certificate 'subsystemCert cert-pki-ca' located in > > /etc/pki/pki-tomcat/alias, so you may also want to check if it is > > still valid. > > The directory server access logs (in > > /var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the > > connection with logs similar to: > > > > [...] 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>; issuer CN=Certificate > > Authority,O=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" > > > > > > > > HTH, > > 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