February 2019 - FreeIPA-users - Fedora mailing-lists

Failed to start 389 Directory Server
by Zarko D 08 Feb '19

08 Feb '19

Hi there, this is ipa-server-4.4.0-12.0.1 with 389-ds-base-1.3.5.10-11 and suddenly daily backup has started to fail with messages: 2019-01-28T04:10:04Z INFO Backing up ipaca in REALM-COM to LDIF 2019-01-28T04:10:04Z INFO Waiting for LDIF to finish 2019-01-28T04:10:05Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_backup.py", line 300, in run self.db2ldif(instance, 'ipaca', online=options.online) File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_backup.py", line 425, in db2ldif shutil.move(ldiffile, os.path.join(self.dir, ldifname)) File "/usr/lib64/python2.7/shutil.py", line 301, in move copy2(src, real_dst) File "/usr/lib64/python2.7/shutil.py", line 130, in copy2 copyfile(src, dst) File "/usr/lib64/python2.7/shutil.py", line 82, in copyfile with open(src, 'rb') as fsrc: 2019-01-28T04:10:05Z DEBUG The ipa-backup command failed, exception: IOError: [Errno 2] No such file or directory: u'/var/ lib/dirsrv/slapd-REALM-COM/ldif/REALM-COM-ipaca.ldif' 2019-01-28T04:10:05Z ERROR [Errno 2] No such file or directory: u'/var/lib/dirsrv/slapd-REALM-COM/ldif/REALM-COM-ipaca.ldif' 2019-01-28T04:10:05Z ERROR The ipa-backup command failed. See /var/log/ipabackup.log for more information And service start fails with messages: [02/Feb/2019:22:47:37.889779410 -0800] 389-Directory/1.3.5.10 B2016.309.1527 starting up [02/Feb/2019:22:47:37.906422534 -0800] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match [02/Feb/2019:22:47:37.921288555 -0800] WARNING: userRoot: entry cache size 10485760 B is less than db size 16932864 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.921943984 -0800] WARNING: ipaca: entry cache size 10485760 B is less than db size 1757741056 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.922701343 -0800] WARNING: changelog: entry cache size 2097152 B is less than db size 82935808 B; We recommend to increase the entry cache size nsslapd-cachememsize. [02/Feb/2019:22:47:37.925215059 -0800] Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Feb/2019:22:47:37.926177620 -0800] libdb: BDB1546 unable to join the environment thanks in advance for any help, Zarko

3 3

Possible to ignore all AD groups?
by Charles Ulrich 08 Feb '19

08 Feb '19

Hello, Hopefully this might be a straightforward question. I have testing instance of FreeIPA version 4.6.4 installed on CentOS 7 from the distro's default repos. I have it configured for a one-way trust to an Active Directory deployment. On the client side, I have installed and configured the freeipa-client package version 4.7.0 on Ubuntu 18.04. This is all basically working as advertised according to the docs. However, when I log into the client with an AD account and run the `id` command, I'm seeing all of my AD groups listed. Is there a way to have FreeIPA completely ignore all groups from AD when dealing with external users? The ultimate goal (and let me know if this is beyond FreeIPA's capabiltiies) is to ignore/discard all groups in AD and manage users instead by groups in FreeIPA. One thing I did try was adding these options to the domain section of `sssd.conf` on the FreeIPA server, but they didn't have any effect and I suspect I don't fully understand what they are for: ignore_group_members = True subdomain_inherit = ignore_group_members Thanks for any advice, even if it's "hey, don't do that". Charles

1 0

Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps?
by Jernej Jakob 08 Feb '19

08 Feb '19

Hi, I'm tasked with upgrading our current setup of 3.3.5 on F19 to something more recent and stable (CentOS 7 or CentOS 8). There were instructions at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht… which is now 404 so I've searched around and found a thread on freeipa-users: https://www.redhat.com/archives/freeipa-users/2016-April/msg00260.html This thread also points to the above 404 link and another thread: https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html When I was reading up on this a year or two ago, there were some guides still up, and I recall there were some commands to check master/replica CA status and promote/demote tha CAs in V3. I can't find these any more. There is a section "Procedure in FreeIPA < 4.0" here: https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master But I do not have a /var/lib/pki-ca, only /var/lib/pki/pki-tomcat so that doesn't work. This was originally a 2-server setup with master-replica, CA and DNS, but due to a firewall misconfiguration after a system upgrade the replication was disconnected for some time. When the split was detected due to us editing the configuration on the master and it not being propagated, we reestablished the connection but things never got back to fully working (I recall we could only edit the configuration on the master, any changes on the replica got lost). We then unenrolled the replica which left us with only the master that is running currently. Everything including enrolling new clients works so IMO this means we're left with the CA master, so we'd want to upgrade this to V4 and have at least 2 replicas back ASAP. If I understand things correctly, first we need to check if all the certificates are valid and if not renew them, then install a V3 replica, promote/demote the CAs, check if things are working correctly, unenroll the old V3 master, upgrade the replica (now master) to V4 and install additional replicas. Since this is our production system with ~20 clients, DNS with custom zones, HBAC, etc I'd not like to experiment a lot with it (we do have backups just in case). I'd highly appreciate if anyone has any suggestions, instructions or an archived upgrade guide somewhere... Thanks. Jernej

3 6

Re: CA no certs being tracked?
by Chris Mohler 08 Feb '19

08 Feb '19

I have not been able to renew the expired certificates yet. I would appreciate help if possible. > Followup summary: > > Q: Seems like part of the problem is that the KDC was not running. Had > you > done ipactl stop prior to the upgrade? > > A: I could not get the KDC to stay running. So yes it was off during > the upgrade. > > Q: Did it end up creating the tracking? Are there expired certs? > > A: I was able to get the upgrade to finish successfully, after > restoring the server from VM snapshot, rolling back the system date, > and trying the update again. It did create the cert tracking!!! Yes > there are expired certs. > > Q: As an aside, I'd have suggest deferring the package upgrade until > after > the other things were sorted. It just adds another moving part. Water > under the bridge now. > > A: Yes sorry. > > >> On 2/5/2019 11:18 AM, Rob Crittenden wrote: >>> Chris Mohler wrote: >>>> Well... That was a mess. >>>> >>>> The ipa-server-upgrade didn't go so well. It failed and now my >>>> ca-replication master is broken. Here are the details. Any hope? >>>> >>>>> Upgrading IPA:. Estimated time: 1 minute 30 seconds >>>>> [1/11]: stopping directory server >>>>> [2/11]: saving configuration >>>>> [3/11]: disabling listeners >>>>> [4/11]: enabling DS global lock >>>>> [5/11]: disabling Schema Compat >>>>> [6/11]: starting directory server >>>>> [7/11]: updating schema >>>>> [8/11]: upgrading server >>>>> [9/11]: stopping directory server >>>>> [10/11]: restoring configuration >>>>> [11/11]: starting directory server >>>>> Done. >>>>> Update complete >>>>> Upgrading IPA services >>>>> Upgrading the configuration of the IPA services >>>>> [Verifying that root certificate is published] >>>>> [Migrate CRL publish directory] >>>>> CRL tree already moved >>>>> [Verifying that CA proxy configuration is correct] >>>>> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run >>>>> command ipa-server-upgrade manually. >>>>> CA did not start in 300.0s >>>>> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log >>>>> for >>>>> more information >>> Seems like part of the problem is that the KDC was not running. Had you >>> done ipactl stop prior to the upgrade? >>> >>> Did it end up creating the tracking? Are there expired certs? >>> >>> As an aside, I'd have suggest deferring the package upgrade until after >>> the other things were sorted. It just adds another moving part. Water >>> under the bridge now. >>> >>> rob >>> >>>> Here is a wall of errors from my /var/log/ipaupgrade.log >>>>> Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.947136504 -0500] >>>>> - ERR - set_krb5_creds - Could not get initial credentials for >>>>> principal [ldap/ipa2.domain.com(a)domain.com] in keytab >>>>> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for >>>>> requested realm) >>>>> Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.953577522 -0500] >>>>> - ERR - slapi_ldap_bind - Error: could not send startTLS request: >>>>> error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is >>>>> not connected) >>>>> Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.958062514 -0500] >>>>> - ERR - set_krb5_creds - Could not get initial credentials for >>>>> principal [ldap/ipa2.domain.com(a)domain.com] in keytab >>>>> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for >>>>> requested realm) >>>>> Feb 4 17:47:33 ipa2 ns-slapd: GSSAPI Error: Unspecified GSS failure. >>>>> Minor code may provide more information (No Kerberos credentials >>>>> available (default cache: /tmp/krb5cc_389)) >>>>> Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.965496432 -0500] >>>>> - ERR - slapi_ldap_bind - Error: could not bind id [cn=Replication >>>>> Manager >>>>> masterAgreement1-ipa2.domain.com-pki-tomcat,ou=csusers,cn=config] >>>>> authentication mechanism [SIMPLE]: error 32 (No such object) >>>>> Feb 4 17:47:40 ipa2 server: WARNING: Exception processing realm >>>>> com.netscape.cms.tomcat.ProxyRealm@3badc78b background process >>>>> Feb 4 17:47:40 ipa2 server: javax.ws.rs.ServiceUnavailableException: >>>>> Subsystem unavailable >>>>> Feb 4 17:47:40 ipa2 server: at >>>>> com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) >>>>> >>>>> Feb 4 17:47:40 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) >>>>> >>>>> >>>>> Feb 4 17:47:40 ipa2 server: at >>>>> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) >>>>> >>>>> >>>>> Feb 4 17:47:40 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) >>>>> >>>>> >>>>> Feb 4 17:47:40 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:47:40 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:47:40 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520) >>>>> >>>>> >>>>> Feb 4 17:47:40 ipa2 server: at java.lang.Thread.run(Thread.java:748) >>>>> Feb 4 17:47:41 ipa2 dhclient[598]: DHCPREQUEST on eth0 to >>>>> 132.162.1.131 port 67 (xid=0x27e7db13) >>>>> Feb 4 17:47:50 ipa2 server: WARNING: Exception processing realm >>>>> com.netscape.cms.tomcat.ProxyRealm@3badc78b background process >>>>> Feb 4 17:47:50 ipa2 server: javax.ws.rs.ServiceUnavailableException: >>>>> Subsystem unavailable >>>>> Feb 4 17:47:50 ipa2 server: at >>>>> com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) >>>>> >>>>> Feb 4 17:47:50 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) >>>>> >>>>> >>>>> Feb 4 17:47:50 ipa2 server: at >>>>> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) >>>>> >>>>> >>>>> Feb 4 17:47:50 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) >>>>> >>>>> >>>>> Feb 4 17:47:50 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:47:50 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:47:50 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520) >>>>> >>>>> >>>>> Feb 4 17:47:50 ipa2 server: at java.lang.Thread.run(Thread.java:748) >>>>> Feb 4 17:47:52 ipa2 dhclient[598]: DHCPREQUEST on eth0 to >>>>> 132.162.1.131 port 67 (xid=0x27e7db13) >>>>> Feb 4 17:48:00 ipa2 server: WARNING: Exception processing realm >>>>> com.netscape.cms.tomcat.ProxyRealm@3badc78b background process >>>>> Feb 4 17:48:00 ipa2 server: javax.ws.rs.ServiceUnavailableException: >>>>> Subsystem unavailable >>>>> Feb 4 17:48:00 ipa2 server: at >>>>> com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) >>>>> >>>>> Feb 4 17:48:00 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) >>>>> >>>>> >>>>> Feb 4 17:48:00 ipa2 server: at >>>>> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) >>>>> >>>>> >>>>> Feb 4 17:48:00 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) >>>>> >>>>> >>>>> Feb 4 17:48:00 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:48:00 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:48:00 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520) >>>>> >>>>> >>>>> Feb 4 17:48:00 ipa2 server: at java.lang.Thread.run(Thread.java:748) >>>>> Feb 4 17:48:02 ipa2 dhclient[598]: DHCPREQUEST on eth0 to >>>>> 132.162.1.131 port 67 (xid=0x27e7db13) >>>>> Feb 4 17:48:10 ipa2 server: WARNING: Exception processing realm >>>>> com.netscape.cms.tomcat.ProxyRealm@3badc78b background process >>>>> Feb 4 17:48:10 ipa2 server: javax.ws.rs.ServiceUnavailableException: >>>>> Subsystem unavailable >>>>> Feb 4 17:48:10 ipa2 server: at >>>>> com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) >>>>> >>>>> Feb 4 17:48:10 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) >>>>> >>>>> >>>>> Feb 4 17:48:10 ipa2 server: at >>>>> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) >>>>> >>>>> >>>>> Feb 4 17:48:10 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) >>>>> >>>>> >>>>> Feb 4 17:48:10 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:48:10 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:48:10 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520) >>>>> >>>>> >>>>> Feb 4 17:48:10 ipa2 server: at java.lang.Thread.run(Thread.java:748) >>>>> Feb 4 17:48:12 ipa2 [sssd[ldap_child[2284]]]: Failed to initialize >>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Cannot contact >>>>> any >>>>> KDC for realm 'domain.com'. Unable to create GSSAPI-encrypted LDAP >>>>> connection. >>>>> Feb 4 17:48:12 ipa2 [sssd[ldap_child[2285]]]: Failed to initialize >>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Cannot contact >>>>> any >>>>> KDC for realm 'domain.com'. Unable to create GSSAPI-encrypted LDAP >>>>> connection. >>>>> Feb 4 17:48:20 ipa2 server: WARNING: Exception processing realm >>>>> com.netscape.cms.tomcat.ProxyRealm@3badc78b background process >>>>> Feb 4 17:48:20 ipa2 server: javax.ws.rs.ServiceUnavailableException: >>>>> Subsystem unavailable >>>>> Feb 4 17:48:20 ipa2 server: at >>>>> com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) >>>>> >>>>> Feb 4 17:48:20 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) >>>>> >>>>> >>>>> Feb 4 17:48:20 ipa2 server: at >>>>> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) >>>>> >>>>> >>>>> Feb 4 17:48:20 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) >>>>> >>>>> >>>>> Feb 4 17:48:20 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:48:20 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:48:20 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520) >>>>> >>>>> >>>>> Feb 4 17:48:20 ipa2 server: at java.lang.Thread.run(Thread.java:748) >>>>> Feb 4 17:48:22 ipa2 dhclient[598]: DHCPREQUEST on eth0 to >>>>> 132.162.1.131 port 67 (xid=0x27e7db13) >>>>> Feb 4 17:48:30 ipa2 server: WARNING: Exception processing realm >>>>> com.netscape.cms.tomcat.ProxyRealm@3badc78b background process >>>>> Feb 4 17:48:30 ipa2 server: javax.ws.rs.ServiceUnavailableException: >>>>> Subsystem unavailable >>>>> Feb 4 17:48:30 ipa2 server: at >>>>> com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) >>>>> >>>>> Feb 4 17:48:30 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) >>>>> >>>>> >>>>> Feb 4 17:48:30 ipa2 server: at >>>>> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) >>>>> >>>>> >>>>> Feb 4 17:48:30 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) >>>>> >>>>> >>>>> Feb 4 17:48:30 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:48:30 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) >>>>> >>>>> >>>>> Feb 4 17:48:30 ipa2 server: at >>>>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1520) >>>>> >>>>> >>>>> Feb 4 17:48:30 ipa2 server: at java.lang.Thread.run(Thread.java:748) >>>>> Feb 4 17:48:31 ipa2 dhclient[598]: DHCPREQUEST on eth0 to >>>>> 132.162.1.131 port 67 (xid=0x27e7db13) >>>>> ^C >>>>> [root@ipa2 log]# less /var/log/ipaupgrade.log >>>>> <p><b>note</b> <u>The full stack trace of the root cause is available >>>>> in the Apache Tomcat/7.0.76 logs.</u></p><HR size="1" >>>>> noshade="noshade"><h3>Apache Tomcat/7.0.76</h3></body></html>' >>>>> 2019-02-04T22:46:13Z DEBUG The CA status is: check interrupted due to >>>>> error: Retrieving CA status failed with status 500 >>>>> 2019-02-04T22:46:13Z DEBUG Waiting for CA to start... >>>>> 2019-02-04T22:46:14Z DEBUG request POST >>>>> http://ipa2.domain.com:8080/ca/admin/ca/getStatus >>>>> 2019-02-04T22:46:14Z DEBUG request body '' >>>>> 2019-02-04T22:46:14Z DEBUG response status 500 >>>>> 2019-02-04T22:46:14Z DEBUG response headers Server: Apache-Coyote/1.1 >>>>> Content-Type: text/html;charset=utf-8 >>>>> Content-Language: en >>>>> Content-Length: 2208 >>>>> Date: Mon, 04 Feb 2019 22:46:14 GMT >>>>> Connection: close >>>>> >>>>> 2019-02-04T22:46:14Z DEBUG response body '<html><head><title>Apache >>>>> Tomcat/7.0.76 - Error report</title><style></style> </head><body><h1>HTTP Status 500 - Subsystem >>>>> unavailable</h1><HR size="1" noshade="noshade"><p><b>type</b> >>>>> Exception report</p><p><b>message</b> <u>Subsystem >>>>> unavailable</u></p><p><b>description</b> <u>The server encountered an >>>>> internal error that prevented it from fulfilling this >>>>> request.</u></p><p><b>exception</b> >>>>> <pre>javax.ws.rs.ServiceUnavailableException: Subsystem >>>>> unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:145)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:500)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)\n\torg.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1087)\n\torg.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)\n\torg.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:748)\n</pre></p><p><b>note</b> >>>>> >>>>> <u>The full stack trace of the root cause is available in the Apache >>>>> Tomcat/7.0.76 logs.</u></p><HR size="1" noshade="noshade"><h3>Apache >>>>> Tomcat/7.0.76</h3></body></html>' >>>>> 2019-02-04T22:46:14Z DEBUG The CA status is: check interrupted due to >>>>> error: Retrieving CA status failed with status 500 >>>>> 2019-02-04T22:46:14Z DEBUG Waiting for CA to start... >>>>> 2019-02-04T22:46:15Z DEBUG request POST >>>>> http://ipa2.domain.com:8080/ca/admin/ca/getStatus >>>>> 2019-02-04T22:46:15Z DEBUG request body '' >>>>> 2019-02-04T22:46:15Z DEBUG response status 500 >>>>> 2019-02-04T22:46:15Z DEBUG response headers Server: Apache-Coyote/1.1 >>>>> Content-Type: text/html;charset=utf-8 >>>>> Content-Language: en >>>>> Content-Length: 2208 >>>>> Date: Mon, 04 Feb 2019 22:46:15 GMT >>>>> Connection: close >>>>> >>>>> 2019-02-04T22:46:15Z DEBUG response body '<html><head><title>Apache >>>>> Tomcat/7.0.76 - Error report</title><style></style> </head><body><h1>HTTP Status 500 - Subsystem >>>>> unavailable</h1><HR size="1" noshade="noshade"><p><b>type</b> >>>>> Exception report</p><p><b>message</b> <u>Subsystem >>>>> unavailable</u></p><p><b>description</b> <u>The server encountered an >>>>> internal error that prevented it from fulfilling this >>>>> request.</u></p><p><b>exception</b> >>>>> <pre>javax.ws.rs.ServiceUnavailableException: Subsystem >>>>> unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:145)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:500)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)\n\torg.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1087)\n\torg.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)\n\torg.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:748)\n</pre></p><p><b>note</b> >>>>> >>>>> <u>The full stack trace of the root cause is available in the Apache >>>>> Tomcat/7.0.76 logs.</u></p><HR size="1" noshade="noshade"><h3>Apache >>>>> Tomcat/7.0.76</h3></body></html>' >>>>> 2019-02-04T22:46:15Z DEBUG The CA status is: check interrupted due to >>>>> error: Retrieving CA status failed with status 500 >>>>> 2019-02-04T22:46:15Z DEBUG Waiting for CA to start... >>>>> 2019-02-04T22:46:16Z ERROR IPA server upgrade failed: Inspect >>>>> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. >>>>> 2019-02-04T22:46:16Z DEBUG File >>>>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, >>>>> in execute >>>>> return_value = self.run() >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", >>>>> >>>>> line 56, in run >>>>> raise admintool.ScriptError(str(e)) >>>>> >>>>> 2019-02-04T22:46:16Z DEBUG The ipa-server-upgrade command failed, >>>>> exception: ScriptError: CA did not start in 300.0s >>>>> 2019-02-04T22:46:16Z ERROR CA did not start in 300.0s >>>>> 2019-02-04T22:46:16Z ERROR The ipa-server-upgrade command failed. See >>>>> /var/log/ipaupgrade.log for more information >>>> Thanks, >>>> -Chris >>>> >>>>> Rob, >>>>> >>>>> I'll be honest. I think you are suggesting an ldapsearch with this >>>>> >>>>> Check to see which masteris the renewal master. Look in >>>>> cn=CA,cn=$(hostname),cn=masters,cn=ipa,cn=etc,$SUFFIX for >>>>> ipaConfigString=caRenewalMaster >>>>> >>>>> sorry I've not figured out how to successfully ldapsearch >>>>> >>>>> Instead I did this: >>>>> ipa config-show |grep 'CA renewal master' >>>>> >>>>> It came up blank. I suspect I didn't have a renewal master somehow. >>>>> >>>>> Then I did This: >>>>> ipa-csreplica-manage set-renewal-master ipa2 (hostname of working IPA >>>>> server) >>>>> >>>>> Next is a "yum update" to be safe, and lastly "ipa-server-upgrade" on >>>>> ipa2. When that's all done I'll try "yum update" and >>>>> "ipa-server-upgrade" on my broken IPA system ipa1 >>>>> >>>>> I'll report back here when finished. >>>>> >>>>> Thanks, >>>>> >>>>> -Chris >>>>> >>>>>> Check to see which masteris the renewal master. Look in >>>>>> cn=CA,cn=$(hostname),cn=masters,cn=ipa,cn=etc,$SUFFIX for >>>>>> ipaConfigString=caRenewalMaster >>>>>> >>>>>> You want to run the script on that master first to get the certs >>>>>> renewed. >>>>>> >>>>>> I'd start by re-running ipa-server-upgrade. It is idempotent so >>>>>> there >>>>>> should be no risk. It may repair the tracking for you. >>>>>> >>>>>> rob >>>>> On 2/4/2019 3:30 PM, Rob Crittenden wrote: >>>>>> Chris Mohler via FreeIPA-users wrote: >>>>>>> Thanks for looking at my issue! >>>>>>> >>>>>>> There have been no recent updates on my system. Actually I was >>>>>>> getting >>>>>>> ready to update when I noticed things weren't good. >>>>>>> >>>>>>> Here is the output from the log of the most recent update. Looks >>>>>>> like it >>>>>>> was completed successfully. The lines you asked about are in >>>>>>> Bold/underlined. >>>>>>> >>>>>>>> 2018-07-18T16:55:21Z INFO [Update certmonger certificate renewal >>>>>>>> configuration] >>>>>>>> 2018-07-18T16:55:21Z DEBUG Loading Index file from >>>>>>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>>>>>> 2018-07-18T16:55:21Z DEBUG Starting external process >>>>>>>> 2018-07-18T16:55:21Z DEBUG args=/usr/bin/certutil -d >>>>>>>> /etc/pki/pki-tomcat/alias -L -f >>>>>>>> /etc/pki/pki-tomcat/alias/pwdfile.txt >>>>>>>> 2018-07-18T16:55:21Z DEBUG Process finished, return code=0 >>>>>>>> 2018-07-18T16:55:21Z DEBUG stdout= >>>>>>>> Certificate Nickname Trust >>>>>>>> Attributes >>>>>>>> SSL,S/MIME,JAR/XPI >>>>>>>> >>>>>>>> caSigningCert cert-pki-ca CTu,Cu,Cu >>>>>>>> subsystemCert cert-pki-ca u,u,u >>>>>>>> ocspSigningCert cert-pki-ca u,u,u >>>>>>>> auditSigningCert cert-pki-ca u,u,Pu >>>>>>>> Server-Cert cert-pki-ca u,u,u >>>>>>>> >>>>>>>> 2018-07-18T16:55:21Z DEBUG stderr= >>>>>>>> _*2018-07-18T16:55:21Z DEBUG Configuring certmonger to stop >>>>>>>> tracking >>>>>>>> system certificates for CA*_ >>>>>>>> 2018-07-18T16:55:21Z DEBUG Starting external process >>>>>>>> 2018-07-18T16:55:21Z DEBUG args=/bin/systemctl start >>>>>>>> messagebus.service >>>>>>>> 2018-07-18T16:55:21Z DEBUG Process finished, return code=0 >>>>>>>> 2018-07-18T16:55:21Z DEBUG stdout= >>>>>>>> 2018-07-18T16:55:21Z DEBUG stderr= >>>>>>>> 2018-07-18T16:55:21Z DEBUG Starting external process >>>>>>>> 2018-07-18T16:55:21Z DEBUG args=/bin/systemctl is-active >>>>>>>> messagebus.service >>>>>>>> 2018-07-18T16:55:21Z DEBUG Process finished, return code=0 >>>>>>>> 2018-07-18T16:55:21Z DEBUG stdout=active >>>>>>>> >>>>>>>> 2018-07-18T16:55:21Z DEBUG stderr= >>>>>>>> 2018-07-18T16:55:21Z DEBUG Starting external process >>>>>>>> 2018-07-18T16:55:21Z DEBUG args=/bin/systemctl start >>>>>>>> certmonger.service >>>>>>>> 2018-07-18T16:55:21Z DEBUG Process finished, return code=0 >>>>>>>> 2018-07-18T16:55:21Z DEBUG stdout= >>>>>>>> 2018-07-18T16:55:21Z DEBUG stderr= >>>>>>>> 2018-07-18T16:55:21Z DEBUG Starting external process >>>>>>>> 2018-07-18T16:55:21Z DEBUG args=/bin/systemctl is-active >>>>>>>> certmonger.service >>>>>>>> 2018-07-18T16:55:21Z DEBUG Process finished, return code=0 >>>>>>>> 2018-07-18T16:55:21Z DEBUG stdout=active >>>>>>>> >>>>>>> -snip- a few more lines like the section above. >>>>>>>> 2018-07-18T16:55:25Z DEBUG stderr= >>>>>>>> 2018-07-18T16:55:30Z DEBUG Loading Index file from >>>>>>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>>>>>> 2018-07-18T16:55:30Z DEBUG Starting external process >>>>>>>> 2018-07-18T16:55:30Z DEBUG args=/usr/bin/certutil -d >>>>>>>> /etc/dirsrv/DOMAINNAMEHERE -L -n Server-Cert -a -f >>>>>>>> /etc/dirsrv/DOMAINNAMEHERE/pwdfile.txt >>>>>>>> 2018-07-18T16:55:30Z DEBUG Process finished, return code=0 >>>>>>>> 2018-07-18T16:55:30Z DEBUG stdout=-----BEGIN CERTIFICATE----- >>>>>>> -Snip- Cert and Key stuff goes here- >>>>>>>> 2018-07-18T16:55:34Z DEBUG stderr= >>>>>>>> _*2018-07-18T16:55:35Z INFO Certmonger certificate renewal >>>>>>>> configuration updated*_ >>>>>> Check to see which masteris the renewal master. Look in >>>>>> cn=CA,cn=$(hostname),cn=masters,cn=ipa,cn=etc,$SUFFIX for >>>>>> ipaConfigString=caRenewalMaster >>>>>> >>>>>> You want to run the script on that master first to get the certs >>>>>> renewed. >>>>>> >>>>>> I'd start by re-running ipa-server-upgrade. It is idempotent so >>>>>> there >>>>>> should be no risk. It may repair the tracking for you. >>>>>> >>>>>> rob >>>>>> >>>>>>> On 2/4/2019 1:44 PM, Florence Blanc-Renaud wrote: >>>>>>>> On 2/4/19 5:59 PM, Chris Mohler via FreeIPA-users wrote: >>>>>>>>> Hi Everyone, >>>>>>>>> >>>>>>>>> I'm looking for some help. I'm having trouble with everything >>>>>>>>> basically. >>>>>>>>> >>>>>>>>> I think one of my CA's certs expired or something. I can't kinit >>>>>>>>> admin, I can't login via the WebGui. If I "getcert list" it >>>>>>>>> returns >>>>>>>>> "Number of certificates and requests being tracked: 0." >>>>>>>>> >>>>>>>>> This all started happening a few days ago and I am at a loss >>>>>>>>> as to >>>>>>>>> what happened. On a whim I set the system date and time back a >>>>>>>>> few >>>>>>>>> months to see if my certs were expired and like magic I can >>>>>>>>> login to >>>>>>>>> the Webgui but I'm still not tracking anything with "getcert >>>>>>>>> list" I >>>>>>>>> suspect the cert has expired but without tracking it I can't >>>>>>>>> tell, or >>>>>>>>> renew it. >>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> can you check if an upgrade happened recently (have a look at >>>>>>>> /var/log/ipaupgrade.log)? The upgrade stop tracking certs and >>>>>>>> re-configures certmonger, so if it failed in the middle you may be >>>>>>>> left without any tracking. >>>>>>>> You should be able to find lines like the following if the >>>>>>>> untracking/tracking went fine: >>>>>>>> --- >>>>>>>> [Update certmonger certificate renewal configuration] >>>>>>>> Configuring certmonger to stop tracking system certificates for CA >>>>>>>> Certmonger certificate renewal configuration updated >>>>>>>> --- >>>>>>>> >>>>>>>> HTH, >>>>>>>> flo >>>>>>>> >>>>>>>>> Please help >>>>>>>>> >>>>>>>>> I'm running Centos 7, FreeIPA 4.5.4 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Chris >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> FreeIPA-users mailing list -- >>>>>>>>> freeipa-users(a)lists.fedorahosted.org >>>>>>>>> To unsubscribe send an email to >>>>>>>>> freeipa-users-leave(a)lists.fedorahosted.org >>>>>>>>> Fedora Code of Conduct: >>>>>>>>> https://getfedora.org/code-of-conduct.html >>>>>>>>> List Guidelines: >>>>>>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>>>>>>>> List Archives: >>>>>>>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>>>>>> To unsubscribe send an email to >>>>>>> freeipa-users-leave(a)lists.fedorahosted.org >>>>>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>>>>>> List Guidelines: >>>>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>>>>>> List Archives: >>>>>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… >>>>>>> >>>>>>> >>>>>>> > >

2 1

Log into web UI with AD user?
by Charles Ulrich 07 Feb '19

07 Feb '19

Hello, I'm setting up a test instance of FreeIPA with a one-way trust to the organization's AD. So far, that all appears to be working. I can run LDAP queries to look up users, I can log into the test instance via Kerberos, it's all golden. What I would like to next is to add certain external AD users to the "admins" FreeIPA group so that these users can log into the FreeIPA web UI and perform administrative actions the same as the built-in "admin" user can. So far I spent about a day reading docs, googling, and trying things out but haven't yet made this work. Here is what I've done so far: In Identity -> Groups, I added a new group called "admins_external", being careful to select "External" when creating it. I then added the external user (user(a)example.net, say) to that group. Next, I added the "admins_external" group to the built-in "admins" group. Based on what little I know so far, I would expect that this would be enough, but when I log into the FreeIPA UI, it only shows the user's profile. There is no way to do anything else. I thought that maybe I needed an HBAC rule or two, so I created one to allow users in group "admin" access to any host via any service. I then disabled the "allow_all" HBAC rule. Still no dice. For fun, I added a "native" FreeIPA user and put that user in the "admins_external" group. When logging into the UI with that user, it seems to have all of the admin functionality, unlike the external users. If I'm missing something obvious, let me know. Fine by me if you point me towards some documentation, but I would ask that you be very specific about what I should read since as I already said, I have already done quite a lot of research on this. :) Thanks, Charles

3 5

Replica creation using 'ipa-replica-prepare' to generate replica file,is supported only in 0-level IPA domain.
by TomK 06 Feb '19

06 Feb '19

Hello, Would someone please point me to a concise list of steps I can use here? Running 1.) and 2.) yields various errors and I would like to try a known set of working commands to get a replica going in this state before posting with errors: # ipa-replica-prepare ipa04.abc.xyz.123 --ip-address 192.168.0.20 -p "PASS01" Replica creation using 'ipa-replica-prepare' to generate replica file is supported only in 0-level IPA domain. The current IPA domain level is 1 and thus the replica must be created by promoting an existing IPA client. To set up a replica use the following procedure: 1.) set up a client on the host using 'ipa-client-install' 2.) promote the client to replica running 'ipa-replica-install' *without* replica file specified 'ipa-replica-prepare' is allowed only in domain level 0 The ipa-replica-prepare command failed. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

2 4

CentOS 7 ipa upgrade causes pki-tomcatd not to start CA
by Jason Wood 06 Feb '19

06 Feb '19

Upgraded from CentOS 7.5 to 7.6 which includes IPA upgrade.from 4.5.4-10 to 4.6.4-10 upgrade was done via yum upgrade Upgrade went fine. I see no alarming errors in the logs. It stopped and started all the servers did the ipa upgrade. All was fine once completed. Reboot and now pki-tomcatd CA will not start. Tomcat starts, gets all the way to were it should start the CA and doesn't. No errors, Debug doesn't show any blatant errors. It does have "Repository: Server not completely started. Returning .." which is the closest thing I see to an error. All the certs are in monitoring state. None are expired. Domain is not quite a year old. PKI is communicating to LDAP without issues. Validated that. Also checked for and replication errors. There are none. This is happening on all 4 systems. In the exact same way. DNS is up, we can authenticate, kerbrose is working. Can search LDAP via SSL and non-SSL Rebooted into the older kernel just to make sure. Reverted back to an old CS.cfg also, no different. I'm at a complete loss. Most other posts and pages about this all deal with expired certs. And the one that wasn't (from Redhat) was about replication conflicts. Nothing is panning out. Fully patched CentOS Linux release 7.6.1810 (Core) ipa-client-4.6.4-10.el7.centos.x86_64 ipa-client-common-4.6.4-10.el7.centos.noarch ipa-common-4.6.4-10.el7.centos.noarch ipa-server-4.6.4-10.el7.centos.x86_64 ipa-server-common-4.6.4-10.el7.centos.noarch ipa-server-dns-4.6.4-10.el7.centos.noarch libipa_hbac-1.16.2-13.el7.x86_64 python2-ipaclient-4.6.4-10.el7.centos.noarch python2-ipalib-4.6.4-10.el7.centos.noarch python2-ipaserver-4.6.4-10.el7.centos.noarch python-iniparse-0.4-9.el7.noarch python-libipa_hbac-1.16.2-13.el7.x86_64 sssd-ipa-1.16.2-13.el7.x86_64 krb5-pkinit-1.15.1-34.el7.x86_64 pki-base-10.5.9-6.el7.noarch pki-base-java-10.5.9-6.el7.noarch pki-ca-10.5.9-6.el7.noarch pki-kra-10.5.9-6.el7.noarch pki-server-10.5.9-6.el7.noarch pki-tools-10.5.9-6.el7.x86_64

8 22

Help with webapps and expired passwords
by Jeff Goddard 06 Feb '19

06 Feb '19

Hi, I find myself in situation described in this thread: https://serverfault.com/questions/716556/freeipa-ldap-refuse-auth-for-users… Basically we have enabled the FreeIPA LDAP back end to authenticate our uses to various web applications (Confluence, jira, rundeck, etc.) as well as our VPN. What I'm finding is that users with expired passwords are still able to access all of the services. I see there is an issue in development ( https://pagure.io/freeipa/issue/1539) but it looks to be a complex issue that doesn't seem prudent to wait for. Does anyone have a script or pointers on how I can search for expired passwords and disable the user accounts if they are expired? Or is there another method to accomplish having users with expired passwords get denied access to VPN and web services if their password is expired? Thanks, Jeff

1 0

Modsecurity for admin account lockout protection
by Andrey Bondarenko 06 Feb '19

06 Feb '19

Hello, in a situation when freeipa is exposed interface to the internet, there would be bolts trying to bruteforce admin account that made it locked. I come with modsecurity setting for the nss.conf: SecRule ARGS:user "@contains admin" "id:1234,deny,status:403"' Admin user is no longer avaliable from UI, Kerberos login is not affected, cli and WebUI login for other users are not affected. Can it brake something? -- With best regards, Andrey Bondarenkomail:me@andreybondarenko.comhttps://andreybondarenko.com skype:andrey.bondarenko phone, Telegram, WhatsApp, etc:+420-773-591-443 7758 40AC 88CC 96C9 0C9A 9EE4 3B72 547B 7538 D41B

2 2

Use of certificates is failing
by Pierre Labanowski 05 Feb '19

05 Feb '19

Hello, I have some issues with certificate management. 2 important points of the recent information: - after a longstanding loss of the certification authority. The certification authority was deleted and a new one was created. https://frasertweedale.github.io/blog-redhat/posts/2018-05-31-replacing-los… <https://frasertweedale.github.io/blog-redhat/posts/2018-05-31-replacing-los…> ( very big thx ) - For http and ldap, i use 3rd part certificates ( /ipa-server-certinstall /) So far, I've noticed 2 problems : 1°) ipa-server-upgrade : failed Impossible to upgrade the server. i have a 401 error return when the upgrade script wants to access the url: > GET request https://freeipa4.exemple.fr:8443/ca/rest/account/login > ... > response status 401 for this problem, I followed this information : https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomca… certificate on //etc/pki/pki-tomcat/alias///is the same pkiuser on the LDAP server internaldb.ldapauth.authtype=SslClientAuth so I don't know why I have a 401 error. // 2°) ipa cert-request --principal : failed ipa: ERROR: impossible de se connecter à « https://freeipa4.exmple.fr:443/ca/eeca/ca/profileSubmitSSLClient » : (SSL_ERROR_BAD_CERT_ALERT) SSL peer cannot verify your certificate this is strange because on this port 443 i use a 3rd part certificates do you have any idea what the problem is? I'm lost I don't know what to look for anymore. thank you in advance Pierre here are some excerpts from the log ----- IPA server version 4.4.0. API version 2.213 ----- ipaupgrade.log : ''' 2019-01-29T16:48:21Z DEBUG request GET https://freeipa4.exemple.fr:8443/ca/rest/account/login 2019-01-29T16:48:21Z DEBUG request body '' 2019-01-29T16:48:21Z DEBUG NSSConnection init freeipa4.exemple.fr 2019-01-29T16:48:21Z DEBUG Connecting: XX.XX.XX.XX:0 2019-01-29T16:48:21Z DEBUG approved_usage = SSL Server intended_usage = SSL Server 2019-01-29T16:48:21Z DEBUG cert valid True for "CN=freeipa4.exemple.fr,O=exemple.FR" 2019-01-29T16:48:21Z DEBUG handshake complete, peer = XX.XX.XX.XX:8443 2019-01-29T16:48:21Z DEBUG Protocol: TLS1.2 2019-01-29T16:48:21Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA 2019-01-29T16:48:21Z DEBUG approved_usage = SSL Server intended_usage = SSL Server 2019-01-29T16:48:21Z DEBUG cert valid True for "CN=freeipa4.exemple.fr,O=exemple.FR" 2019-01-29T16:48:21Z DEBUG handshake complete, peer = XX.XX.XX.XX:8443 2019-01-29T16:48:21Z DEBUG Protocol: TLS1.2 2019-01-29T16:48:21Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA 2019-01-29T16:48:21Z DEBUG response status 401 2019-01-29T16:48:21Z DEBUG response headers {'content-length': '964', 'content-language': 'fr', 'expires': 'Thu, 01 Jan 1970 01:00:00 CET', 'server': 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Tue, 29 Jan 2019 16:48:21 GMT', 'content-type': 'text/html;charset=utf-8', 'www-authenticate': 'Basic realm="C} 2019-01-29T16:48:21Z DEBUG response body '<html><head><title>Apache Tomcat/7.0.69 - Rapport d\'\'erreur</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font' 2019-01-29T16:48:21Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2019-01-29T16:48:21Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 46, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1863, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1785, in upgrade_configuration ca_enable_ldap_profile_subsystem(ca) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 336, in ca_enable_ldap_profile_subsystem cainstance.migrate_profiles_to_ldap() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1984, in migrate_profiles_to_ldap _create_dogtag_profile(profile_id, profile_data, overwrite=False) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1990, in _create_dogtag_profile with api.Backend.ra_certprofile as profile_api: File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 2060, in __enter__ raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) 2019-01-29T16:48:21Z DEBUG The ipa-server-upgrade command failed, exception: RemoteRetrieveError: Échec de l'authentification auprès de l'API REST de l'AC ------- # getcert list Number of certificates and requests being tracked: 5. -------

3 2

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users February 2019