November 2019 - FreeIPA-users - Fedora mailing-lists

Re: FreeIPA having problem after upgrading from Fedora 30 to 31
by Patrick Dung 27 Nov '19

27 Nov '19

Hello all, 1) Resent, I used reply instead of reply all in the last mail. 2) I tailed the dirsrv log and perform a manual ipa-server-upgrade. I didn't found connection refused log in the dirsrv. 3) BTW, I had another ipa server that is a replica. Originally both freeipa server had upgrade problem. On the replica server, I tried to install jss-4.6.2-2.fc31.x86_64 (according to https://bugzilla.redhat.com/show_bug.cgi?id=1766451) The ipa-server-upgrade is successfully run on the replica server. But there is problem when I access: https://replica:8443, the error message is shown in below. HTTP Status 500 – Internal Server Error ------------------------------ *Type* Exception Report *Message* org.apache.jasper.JasperException: Unable to compile class for JSP *Description* The server encountered an unexpected condition that prevented it from fulfilling the request. *Exception* org.apache.jasper.JasperException: org.apache.jasper.JasperException: Unable to compile class for JSP org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:604) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:422) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) javax.servlet.http.HttpServlet.service(HttpServlet.java:741) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:549) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170) java.security.AccessController.doPrivileged(Native Method) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:549) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:253) *Root Cause* org.apache.jasper.JasperException: Unable to compile class for JSP org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:619) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) javax.servlet.http.HttpServlet.service(HttpServlet.java:741) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:549) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170) java.security.AccessController.doPrivileged(Native Method) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:549) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:253) *Root Cause* java.security.AccessControlException: access denied ("java.util.PropertyPermission" "tolerateIllegalAmbiguousVarargsInvocation" "read") java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) java.security.AccessController.checkPermission(AccessController.java:886) java.lang.SecurityManager.checkPermission(SecurityManager.java:549) java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) java.lang.System.getProperty(System.java:717) org.eclipse.jdt.internal.compiler.impl.CompilerOptions.<init>(CompilerOptions.java:513) org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:483) org.apache.jasper.compiler.Compiler.compile(Compiler.java:392) org.apache.jasper.compiler.Compiler.compile(Compiler.java:362) org.apache.jasper.compiler.Compiler.compile(Compiler.java:346) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:603) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) javax.servlet.http.HttpServlet.service(HttpServlet.java:741) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:549) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170) java.security.AccessController.doPrivileged(Native Method) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:549) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:253) *Note* The full stack trace of the root cause is available in the server logs. 4) On the main server, I tried to upgrade jss and run ipa-server-upgrade but the error is still there. The error is the same as the original mail a few days ago. Thanks, Patrick On Thu, Oct 31, 2019 at 12:25 PM Patrick Dung <patdung100(a)gmail.com> wrote: > I tail the dirsrv log and perform a manual ipa-server-upgrade. > I didn't found connection refused log in the dirsrv. > > Thanks, > Patrick > > On Thu, Oct 31, 2019 at 7:43 AM Fraser Tweedale <ftweedal(a)redhat.com> > wrote: > >> Is there anything in the dirsrv log relating to the connection >> attempt? Connection Refused could in fact be a TLS handshake error >> (the TLS handshake also includes certificate authentication). >> >> Cheers, >> Fraser >> >> On Wed, Oct 30, 2019 at 10:47:54PM +0800, Patrick Dung via FreeIPA-users >> wrote: >> > Hello Endi, >> > >> > The DS is up. >> > >> > $ ldapsearch -LLL -x -H ldaps://home.local.nonet:636 -b >> > "cn=users,cn=accounts,dc=local,dc=nonet" >> > dn: cn=users,cn=accounts,dc=local,dc=nonet >> > objectClass: top >> > objectClass: nsContainer >> > cn: users >> > >> > dn: uid=admin,cn=users,cn=accounts,dc=local,dc=nonet >> > objectClass: top >> > objectClass: person >> > objectClass: posixaccount >> > objectClass: krbprincipalaux >> > objectClass: krbticketpolicyaux >> > objectClass: inetuser >> > objectClass: ipaobject >> > objectClass: ipasshuser >> > objectClass: ipaSshGroupOfPubKeys >> > uid: admin >> > cn: Administrator >> > sn: Administrator >> > uidNumber: 700000 >> > gidNumber: 700000 >> > homeDirectory: /home/admin >> > loginShell: /bin/bash >> > gecos: Administrator >> > >> > I had include more logs as attachment. >> > >> > Thanks, >> > Patrick >> > >> > On Wed, Oct 30, 2019 at 10:23 PM Endi Sukma Dewata <edewata(a)redhat.com> >> > wrote: >> > >> > > Hi Patrick, >> > > >> > > I see that you included the CA debug log: >> > > >> > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnection: Connecting to >> > > home.local.nonet:636 with client cert auth >> > > 2019-10-30 05:03:50 [main] FINE: >> ldapconn/PKISocketFactory.makeSSLSocket: >> > > begins >> > > 2019-10-30 05:03:50 [main] SEVERE: Unable to create socket: >> > > java.net.ConnectException: Connection refused (Connection refused) >> > > java.net.ConnectException: Connection refused (Connection refused) >> > > at java.net.PlainSocketImpl.socketConnect(Native Method) >> > > at java.net >> > > .AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) >> > > at java.net >> > > >> .AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) >> > > at java.net >> > > .AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) >> > > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) >> > > at java.net.Socket.connect(Socket.java:607) >> > > at java.net.Socket.connect(Socket.java:556) >> > > at java.net.Socket.<init>(Socket.java:452) >> > > at java.net.Socket.<init>(Socket.java:262) >> > > >> > > The stack trace above is incomplete so it's hard to tell exactly where >> > > in PKI code the exception happened, but the earlier message seem to >> > > indicate that it's trying to connect to the the DS, so you need to >> make >> > > sure the DS is running and accessible. >> > > >> > > -- >> > > Endi S. Dewata >> > > >> > > ----- Original Message ----- >> > > > Hi Patrick, >> > > > >> > > > The "javax.ws.rs.ServiceUnavailableException: Subsystem >> unavailable" >> > > > suggests that the CA subsystem got undeployed automatically from >> > > > Tomcat due to an error in CA (the Tomcat itself seems to be running >> > > > just fine). >> > > > >> > > > You'll need to check the CA debug log in >> /var/log/pki/pki-tomcat/ca/*, >> > > > hopefully it will show the actual problem. Once it's fixed, you just >> > > > need to restart Tomcat and the CA should be redeployed >> automatically. >> > > > >> > > > Also check the upgrade log in /var/log/pki/pki-server-upgrade-* to >> see >> > > > if there's any PKI upgrade issue. >> > > > >> > > > Hope this helps. >> > > > >> > > > -- >> > > > Endi S. Dewata >> > > > >> > > > ----- Original Message ----- >> > > > > Looks like it's the second problem (on pagure) >> > > > > >> > > > > -- Logs begin at Wed 2019-10-30 02:34:10 HKT, end at Wed >> 2019-10-30 >> > > > > 06:28:21 >> > > > > HKT. -- >> > > > > Oct 30 03:39:43 home.local.nonet systemd[1]: Starting PKI Tomcat >> Server >> > > > > pki-tomcat... >> > > > > Oct 30 03:39:44 home.local.nonet pki-server[57211]: >> > > > > ---------------------------- >> > > > > Oct 30 03:39:44 home.local.nonet pki-server[57211]: pki-tomcat >> instance >> > > > > migrated >> > > > > Oct 30 03:39:44 home.local.nonet pki-server[57211]: >> > > > > ---------------------------- >> > > > > Oct 30 03:39:44 home.local.nonet systemd[1]: Started PKI Tomcat >> Server >> > > > > pki-tomcat. >> > > > > Oct 30 03:39:44 home.local.nonet server[57330]: Java virtual >> machine >> > > used: >> > > > > /usr/lib/jvm/jre-1.8.0-openjdk/bin/java >> > > > > Oct 30 03:39:44 home.local.nonet server[57330]: classpath used: >> > > > > >> > > >> /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.jar >> > > > > Oct 30 03:39:44 home.local.nonet server[57330]: main class used: >> > > > > org.apache.catalina.startup.Bootstrap >> > > > > Oct 30 03:39:44 home.local.nonet server[57330]: flags used: >> > > > > -Djava.library.path=/usr/lib64/nuxwdog-jni >> > > > > Oct 30 03:39:44 home.local.nonet server[57330]: options used: >> > > > > -Dcatalina.base=/var/lib/pki/pki-tomcat >> > > -Dcatalina.home=/usr/share/tomcat >> > > > > -Djava.endorsed.dirs= >> -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp >> > > > > >> > > >> -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties >> > > > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager >> > > > > -Djava.security.manager >> > > > > >> -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy >> > > > > Oct 30 03:39:44 home.local.nonet server[57330]: arguments used: >> start >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: WARNING: Exception >> > > > > processing >> > > > > realm [com.netscape.cms.tomcat.ProxyRealm@296c31c9] background >> process >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: >> > > > > javax.ws.rs.ServiceUnavailableException: Subsystem unavailable >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:142) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1137) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5566) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1353) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1357) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1335) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > >> > > >> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) >> > > > > Oct 30 03:40:03 home.local.nonet server[57330]: at >> > > > > java.lang.Thread.run(Thread.java:748) >> > > > > >> > > > > The pki-tomcat instance is running. It would output error when I >> browse >> > > > > https://home.local.nonet:8443/ca , but >> > > https://home.local.nonet:8443/pki/ >> > > > > is >> > > > > ok >> > > > > Instance ID: pki-tomcat >> > > > > Active: True >> > > > > Unsecure Port: 8080 >> > > > > Secure Port: 8443 >> > > > > AJP Port: 8009 >> > > > > Tomcat Port: 8005 >> > > > > >> > > > > CA Subsystem: >> > > > > Type: Subordinate CA (Security Domain) >> > > > > SD Registration URL: https://home.local.nonet:443 >> > > > > Enabled: True >> > > > > Unsecure URL: http://home.local.nonet:8080/ca/ee/ca >> > > > > Secure Agent URL: https://home.local.nonet:8443/ca/agent/ca >> > > > > Secure EE URL: https://home.local.nonet:8443/ca/ee/ca >> > > > > Secure Admin URL: https://home.local.nonet:8443/ca/services >> > > > > PKI Console URL: https://home.local.nonet:8443/ca >> > > > > >> > > > > Thanks, >> > > > > Patrick >> > > > > >> > > > > On Wed, Oct 30, 2019 at 5:44 AM Alex Scheel < ascheel(a)redhat.com >> > >> > > wrote: >> > > > > >> > > > > >> > > > > You might try checking journalctl output. >> > > > > >> > > > > It might be this bug: >> > > https://bugzilla.redhat.com/show_bug.cgi?id=1766451 >> > > > > >> > > > > Otherwise, it is a perfect match for this bug: >> > > > > https://pagure.io/dogtagpki/issue/3111 >> > > > > >> > > > > Which I'd also like journalctl output on, if you have any to >> share. :) >> > > > > >> > > > > >> > > > > I should have a Bodhi update out tonight yet for the issue in the >> BZ. >> > > > > Without >> > > > > more information, I'm not sure we'd know what cause for the second >> > > issue >> > > > > is. >> > > > > >> > > > > - Alex >> > > > > >> > > > > ----- Original Message ----- >> > > > > > From: "Patrick Dung via FreeIPA-users" < >> > > > > > freeipa-users(a)lists.fedorahosted.org > >> > > > > > To: freeipa-users(a)lists.fedorahosted.org >> > > > > > Cc: "Patrick Dung" < patdung100(a)gmail.com > >> > > > > > Sent: Tuesday, October 29, 2019 5:29:09 PM >> > > > > > Subject: [Freeipa-users] FreeIPA having problem after upgrading >> from >> > > > > > Fedora >> > > > > > 30 to 31 >> > > > > > >> > > > > > Hello, >> > > > > > >> > > > > > I got problem upgrading from FC30 to FC31. >> > > > > > Before upgrade the FreeIPA in FC30 is running fine. >> > > > > > >> > > > > > After OS upgrade, IPA cannot start and checked that it stuck at >> the >> > > CA >> > > > > > part. >> > > > > > I run ipa-server-upgrade manually but there is problem. >> > > > > > >> > > > > > 2019-10-29T21:03:58Z DEBUG request GET >> > > > > > https://home.local.nonet:8443/ca/rest/account/login >> > > > > > 2019-10-29T21:03:58Z DEBUG request body '' >> > > > > > 2019-10-29T21:03:58Z DEBUG response status 500 >> > > > > > 2019-10-29T21:03:58Z DEBUG response headers Content-Type: >> > > > > > text/html;charset=utf-8 >> > > > > > Content-Language: en >> > > > > > Content-Length: 2481 >> > > > > > Date: Tue, 29 Oct 2019 21:03:58 GMT >> > > > > > Connection: close >> > > > > > >> > > > > > >> > > > > > 2019-10-29T21:03:58Z DEBUG response body (decoded): b'<!doctype >> > > > > > html><html >> > > > > > lang="en"><head><title>HTTP Status 500 \xe2\x80\x93 Internal >> Server >> > > > > > Error</title><style type="text/css">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-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} >> > > > > > body >> > > > > > >> > > >> {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} >> > > > > > b >> > > > > > >> > > >> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} >> > > > > > p >> > > > > > >> > > >> {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;} >> > > > > > a {color:black;} a.name {color:black;} .line >> > > > > > >> > > >> {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP >> > > > > > Status 500 \xe2\x80\x93 Internal Server Error</h1><hr >> class="line" >> > > > > > /><p><b>Type</b> Exception Report</p><p><b>Message</b> Subsystem >> > > > > > unavailable</p><p><b>Description</b> The server encountered an >> > > unexpected >> > > > > > condition that prevented it from fulfilling the >> > > > > > request.</p><p><b>Exception</b></p><pre> javax.ws.rs >> > > > > > .ServiceUnavailableException: >> > > > > > Subsystem >> > > > > > >> > > >> unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:150)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:515)\n\tcom.netscape.cms.tomcat.ExternalAuthenticationValve.invoke(ExternalAuthenticationValve.java:82)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)\n\torg.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)\n\torg.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)\n\torg.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)\n\torg.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860)\n\ >> > > > > > torg.apache.tomcat.util.net >> > > > > > .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)\n\ >> > > > > > torg.apache.tomcat.util.net >> > > > > > >> > > >> .SocketProcessorBase.run(SocketProcessorBase.java:49)\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><b>Note</b> >> > > > > > The full stack trace of the root cause is available in the >> server >> > > > > > logs.</p><hr class="line" /><h3>Apache >> > > Tomcat/9.0.26</h3></body></html>' >> > > > > > 2019-10-29T21:03:58Z ERROR IPA server upgrade failed: Inspect >> > > > > > /var/log/ipaupgrade.log and run command ipa-server-upgrade >> manually. >> > > > > > 2019-10-29T21:03:58Z DEBUG File >> > > > > > "/usr/lib/python3.7/site-packages/ipapython/admintool.py", line >> 179, >> > > in >> > > > > > execute >> > > > > > return_value = self.run() >> > > > > > File >> > > > > > >> > > >> "/usr/lib/python3.7/site-packages/ipaserver/install/ipa_server_upgrade.py", >> > > > > > line 54, in run >> > > > > > server.upgrade() >> > > > > > File >> > > > > > >> > > >> "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py", >> > > > > > line 2223, in upgrade >> > > > > > upgrade_configuration() >> > > > > > File >> > > > > > >> > > >> "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py", >> > > > > > line 2093, in upgrade_configuration >> > > > > > ca_enable_ldap_profile_subsystem(ca) >> > > > > > File >> > > > > > >> > > >> "/usr/lib/python3.7/site-packages/ipaserver/install/server/upgrade.py", >> > > > > > line 414, in ca_enable_ldap_profile_subsystem >> > > > > > cainstance.migrate_profiles_to_ldap() >> > > > > > File >> > > "/usr/lib/python3.7/site-packages/ipaserver/install/cainstance.py", >> > > > > > line 1937, in migrate_profiles_to_ldap >> > > > > > _create_dogtag_profile(profile_id, profile_data, >> overwrite=False) >> > > > > > File >> > > "/usr/lib/python3.7/site-packages/ipaserver/install/cainstance.py", >> > > > > > line 1943, in _create_dogtag_profile >> > > > > > with api.Backend.ra_certprofile as profile_api: >> > > > > > File >> "/usr/lib/python3.7/site-packages/ipaserver/plugins/dogtag.py", >> > > line >> > > > > > 1315, in __enter__ >> > > > > > raise errors.RemoteRetrieveError(reason=_('Failed to >> authenticate to >> > > CA >> > > > > > REST API')) >> > > > > > >> > > > > > 2019-10-29T21:03:58Z DEBUG The ipa-server-upgrade command >> failed, >> > > > > > exception: RemoteRetrieveError: Failed to authenticate to CA >> REST API >> > > > > > 2019-10-29T21:03:58Z ERROR Unexpected error - see >> > > /var/log/ipaupgrade.log >> > > > > > for details: >> > > > > > RemoteRetrieveError: Failed to authenticate to CA REST API >> > > > > > 2019-10-29T21:03:58Z ERROR The ipa-server-upgrade command >> failed. See >> > > > > > /var/log/ipaupgrade.log for more information >> > > > > > >> > > > > > From /var/log/pki/pki-tomcat/ca/debug log file: >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapAuthInfo: init() >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapAuthInfo: init begins >> > > > > > 2019-10-30 05:03:50 [main] FINEST: Getting >> > > > > > internaldb.ldapauth.authtype=SslClientAuth >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapAuthInfo: init ends >> > > > > > 2019-10-30 05:03:50 [main] FINEST: Property >> internaldb.errorIfDown >> > > not >> > > > > > found >> > > > > > 2019-10-30 05:03:50 [main] FINEST: Getting >> > > internaldb.errorIfDown=true >> > > > > > 2019-10-30 05:03:50 [main] FINEST: Property >> internaldb.doCloning not >> > > > > > found >> > > > > > 2019-10-30 05:03:50 [main] FINEST: Getting >> internaldb.doCloning=true >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnFactory: >> doCloning: >> > > true >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnFactory: mininum: >> 3 >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnFactory: maximum: >> 15 >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnFactory: host: >> > > > > > home.local.nonet >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnFactory: port: 636 >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnFactory: secure: >> true >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnFactory: >> > > authentication: 2 >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnFactory: >> > > > > > makeConnection(true) >> > > > > > 2019-10-30 05:03:50 [main] FINEST: Getting >> > > > > > internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca >> > > > > > 2019-10-30 05:03:50 [main] FINEST: Property tcp.keepAlive not >> found >> > > > > > 2019-10-30 05:03:50 [main] FINEST: Getting tcp.keepAlive=true >> > > > > > 2019-10-30 05:03:50 [main] FINE: TCP Keep-Alive: true >> > > > > > 2019-10-30 05:03:50 [main] FINE: LdapBoundConnection: >> Connecting to >> > > > > > home.local.nonet:636 with client cert auth >> > > > > > 2019-10-30 05:03:50 [main] FINE: >> > > ldapconn/PKISocketFactory.makeSSLSocket: >> > > > > > begins >> > > > > > 2019-10-30 05:03:50 [main] SEVERE: Unable to create socket: >> > > > > > java.net.ConnectException: Connection refused (Connection >> refused) >> > > > > > java.net.ConnectException: Connection refused (Connection >> refused) >> > > > > > at java.net.PlainSocketImpl.socketConnect(Native Method) >> > > > > > at >> > > > > > java.net >> > > > > > >> .AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) >> > > > > > at >> > > > > > java.net >> > > > > > >> > > >> .AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) >> > > > > > at >> > > > > > java.net >> > > > > > >> .AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) >> > > > > > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) >> > > > > > at java.net.Socket.connect(Socket.java:607) >> > > > > > at java.net.Socket.connect(Socket.java:556) >> > > > > > at java.net.Socket.<init>(Socket.java:452) >> > > > > > at java.net.Socket.<init>(Socket.java:262) >> > > > > > >> > > > > > Some error is logged to /var/log/messages: >> > > > > > Oct 30 05:26:50 home server[65722]: WARNING: Exception >> processing >> > > realm >> > > > > > [com.netscape.cms.tomcat.ProxyRealm@5647a92b] background >> process >> > > > > > Oct 30 05:26:50 home server[65722]: >> > > > > > javax.ws.rs .ServiceUnavailableException: Subsystem unavailable >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:142) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1137) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5566) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1353) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1357) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1335) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > >> > > >> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) >> > > > > > Oct 30 05:26:50 home server[65722]: #011at >> > > > > > java.lang.Thread.run(Thread.java:748) >> > > > > > >> > > > > > I am able to connect to my ldap server port 636 with TLS without >> > > problem. >> > > > > > >> > > > > > Thanks, >> > > > > > Patrick >> > > > > > >> > > > > > _______________________________________________ >> > > > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > > > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> > List Archives: >> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… >> >>

2 4

OTP implementation
by Mizuki Karasawa 27 Nov '19

27 Nov '19

Hi all, We started looking into OTP features provided by IPA in our facility. In our environment, majority of our machines are located in the private network, users access them via external-facing Gateways. We want to enforce MFA on our gateway and allow users to have freedom SSH-ing into any internal nodes using their regular password (or keys). Then add HBAC rules for certain hosts/services who require MFA authentications using OTP (for example, protected web resource access. NX etc) In order to achieve that, it seems to me we need turn on both 'password' and 'otp' for individual users or globally. This will then trigger 'password' for SSH and 'otp' auth for WebApps/NX and so on. However when I looked at the online document @ https://www.freeipa.org/page/V4/OTP#Implementation , it stated "Mixing the "password" and "otp" user auth types should not be used", I wonder why "mixing" is not recommended, and what is the downside if we implement this way(in order to achieve what we're trying to do), or any other better strategies in this case? Can some advice? Thank you in advance! Mizuki

3 2

[Announce] Security releases: FreeIPA 4.8.3, 4.7.4, and 4.6.7 released
by Alexander Bokovoy 26 Nov '19

26 Nov '19

Hello! The FreeIPA team would like to announce FreeIPA security releases for three release series: 4.8.3, 4.7.4, and 4.6.7 release! Each series includes a security update release that contains fixes for two issues: * CVE-2019-10195: Don't log passwords embedded in commands in calls using batch A flaw was found in the way that FreeIPA's batch processing API logged operations. This included passing user passwords in clear text on FreeIPA masters. Batch processing of commands with passwords as arguments or options is not performed by default in FreeIPA but is possible by third-party components. An attacker having access to system logs on FreeIPA masters could use this flaw to produce log file content with passwords exposed. The issue was reported by Jamison Bennett from Cloudera * CVE-2019-14867: Make sure to have storage space for tag A flaw was found in the way the internal function ber_scanf() was used in some components of the IPA server, which parsed kerberos key data. An unauthenticated attacker who could trigger parsing of the krb principal key could cause the IPA server to crash or in some conditions, cause arbitrary code to be executed on the server hosting the IPA server. The issue was reported by Todd Lipcon from Cloudera == Upgrading == Upgrade instructions are available on [[Upgrade]] page. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahos…) or #freeipa channel on Freenode. == Detailed changelog since 4.6.6 == === Alexander Bokovoy (1) === * Become FreeIPA 4.6.7 === Rob Crittenden (1) === * CVE-2019-10195: Don't log passwords embedded in commands in calls using batch === Simo Sorce (1) === * CVE-2019-14867: Make sure to have storage space for tag == Detailed changelog since 4.7.3 == === Alexander Bokovoy (1) === * Become FreeIPA 4.7.4 === Rob Crittenden (1) === * CVE-2019-10195: Don't log passwords embedded in commands in calls using batch === Simo Sorce (1) === * CVE-2019-14867: Make sure to have storage space for tag == Detailed changelog since 4.8.2 == === Alexander Bokovoy (1) === * Become FreeIPA 4.8.3 === Rob Crittenden (1) === * CVE-2019-10195: Don't log passwords embedded in commands in calls using batch === Simo Sorce (1) === * CVE-2019-14867: Make sure to have storage space for tag -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

1 1

"s2n exop request failed" errors.
by Jean Figarella 26 Nov '19

26 Nov '19

Hi, I have a customer that has both, RHEL 7 and RHEL 6 clients failing logins with these "s2n exop request failed" errors. > > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [sdap_process_result] (0x2000): Trace: sh[0x219b840], connected[1], > ops[0x3209440], ldap[0x218dd00] (Sat Nov 16 12:40:21 2019) [sssd[be[ > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Sat Nov > 16 12:40:21 2019) [sssd[be[ > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such > object(32), (null). (Sat Nov 16 12:40:21 2019) [sssd[be[ > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [sdap_op_destructor] (0x2000): Operation 27 finished (Sat Nov 16 12:40:21 > 2019) [sssd[be[ > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Sat Nov 16 > 12:40:21 2019) [sssd[be[ > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [sdap_id_op_done] (0x4000): releasing operation connection (Sat Nov 16 > 12:40:21 2019) [sssd[be[ > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Sat > Nov 16 12:40:21 2019) [sssd[be[ > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [sdap_process_result] (0x2000): Trace: sh[0x219b840], connected[1], > ops[(nil)], ldap[0x218dd00] (Sat Nov 16 12:40:21 2019) [sssd[be[ > (Sat Nov 16 12:40:21 2019) [sssd[be[devunx.ulalaunch.com]]] > [sdap_process_result] (0x2000): Trace: ldap_result found nothing! On RHEL > 7, this was fixed by updating sssd to version > 1.13. Basically and update > from RHEL 7.2 to 7.3 is all that is needed. However sssd-1.14 has not made > it to rhel6 yet. Will this ever get fixed in RHEL 6? Thanks. On RHEL 7, this was fixed by updating sssd to version > 1.13. Basically and update from RHEL 7.2 to 7.3 is all that is needed. However sssd-1.14 has not made it to rhel6 yet. Will this ever get fixed in RHEL 6? Thanks. --- MR. JEAN FIGARELLA PRINCIPAL CONSULTANT Red Hat Consulting North America Public Sector jean(a)redhat.com M: 5404293506 www.redhat.com

2 1

freeipa communication to dogtag broken after certificates expired and ipa-cert-fix run
by Alexander Skobeltsin 25 Nov '19

25 Nov '19

Several days ago my freeipa (4.4) server was broken due to expiration of all certificates ( except ca of course). Because of in 4.4 was no such handy tool, as ipa-cert-fix, but lots of recovery methods, that I found in Google were using it, I decided to upgrade my broken freeipa to 4.5 ( by packages upgrade). Packages were installed succesfully, but automatic ipa-server-upgrade script after installation failed ( because of certificates, obviously). Then, I ran ipa-cert-fix and almost all freeipa certificates were succesfully resubmited and updated. Then, I tried to manually run ipa-server-upgrade, but it failed in the same place, as before updating certificates - on trying to communicate with dogtag. As well as I can't just start ipa (via "ipactl start"), but it works with "--force" option, and works well, except those part of ui, that shows certificates. There is part of ipaupgrade.log, where upgrade fails: 2019-11-25T14:44:35Z DEBUG request GET https://ipa-vis.tis.rk:8443/ca/rest/account/login 2019-11-25T14:44:35Z DEBUG request body '' 2019-11-25T14:44:35Z DEBUG response status 401 2019-11-25T14:44:35Z DEBUG response headers Server: Apache-Coyote/1.1 Cache-Control: private Expires: Thu, 01 Jan 1970 03:00:00 MSK WWW-Authenticate: Basic realm="Certificate Authority" Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 951 Date: Mon, 25 Nov 2019 14:44:35 GMT 2019-11-25T14:44:35Z DEBUG response body '<html><head><title>Apache Tomcat/7.0.76 - Error report</title><style></style> </head><body><h1>HTTP Status 401 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>This request requires HTTP authentication.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.76</h3></body></html>' 2019-11-25T14:44:35Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2019-11-25T14:44:35Z 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 54, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2146, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2018, in upgrade_configuration ca_enable_ldap_profile_subsystem(ca) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 406, in ca_enable_ldap_profile_subsystem cainstance.migrate_profiles_to_ldap() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 2027, 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 2033, in _create_dogtag_profile with api.Backend.ra_certprofile as profile_api: File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1315, in __enter__ raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) 2019-11-25T14:44:35Z DEBUG The ipa-server-upgrade command failed, exception: RemoteRetrieveError: Failed to authenticate to CA REST API After some searching, I found that such behaviour could be caused by incompatibility of newly generated ra-agent certificate in location "/var/lib/ipa/ra-agent.pem" and LDAP database in location "uid=ipara,ou=people,o=ipaca"(userCertificate,SeeAlso,description fields), and really, there was old certificates data there. I modified these 3 fields with corresponding new values from new certificate, including correct serial number in description. Here how it looks like now: dn: uid=ipara,ou=people,o=ipaca userCertificate: MIIDXD...NX7U3S description: 2;16;CN=Certificate Authority,O=TIS.RK;CN=IPA RA,O=TIS.RK pkidbuser LDAP entry contained old "CA Subsystem" also, so I modified it too with new "CA Subsystem" certificate data. dn: uid=pkidbuser,ou=people,o=ipaca userCertificate:: MIIDYj...+M7J8bmRc description: 2;14;CN=Certificate Authority,O=TIS.RK;CN=CA Subsystem,O=TIS.RK But none helped. Here what I see in /var/log/pki/pki-tomcat/ca/debug, when trying to show certificate detail in freeipa's ui: [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet:service() uri = /ca/agent/ca/displayBySerial [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet::service() param name='xml' value='true' [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet::service() param name='serialNumber' value='20' [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: caDisplayBySerial start to service. [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: IP: 172.19.4.2 [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: AuthMgrName: certUserDBAuthMgr [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: retrieving SSL certificate [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: certUID=CN=IPA RA,O=TIS.RK [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: started [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: Retrieving client certificate [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuth: Got client certificate [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 4 [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 5 [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: Authentication: client certificate found [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 5 [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 6 [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CertUserDBAuthentication: cannot map certificate to any userServer Internal Error [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: SignedAuditLogger: event AUTH [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.java: renderTemplate [25/Nov/2019:17:24:38][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.java: xml parameter detected, returning xml Before I Updated IPA RA LDAP Entry, it showed "User not found" instead of "Server Internal Error". And in dirsrv log I see such entries, when navigating to certificate detail page: [25/Nov/2019:17:29:41.095869943 +0300] conn=40148 fd=206 slot=206 connection from 172.19.4.2 to 172.19.4.2 [25/Nov/2019:17:29:41.098585286 +0300] conn=40148 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO [25/Nov/2019:17:29:41.103760424 +0300] conn=40148 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0005409737 dn="uid=admin,cn=users,cn=accounts,dc=tis,dc=rk" [25/Nov/2019:17:29:41.105906742 +0300] conn=40148 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=tis,dc=rk" scope=0 filter="(objectClass=*)" attrs=ALL [25/Nov/2019:17:29:41.106795977 +0300] conn=40148 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0000976075 [25/Nov/2019:17:29:41.108348488 +0300] conn=40148 op=2 SRCH base="cn=masters,cn=ipa,cn=etc,dc=tis,dc=rk" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL [25/Nov/2019:17:29:41.108921046 +0300] conn=40148 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000658341 [25/Nov/2019:17:29:41.135945117 +0300] conn=27 op=13 SRCH base="ou=People,o=ipaca" scope=2 filter="(description=2;16;CN=Certificate Authority,O=TIS.RK;CN=IPA RA,O=TIS.RK)" attrs=ALL [25/Nov/2019:17:29:41.136203891 +0300] conn=27 op=13 RESULT err=0 tag=101 nentries=1 etime=0.0000356148 [25/Nov/2019:17:29:41.142786310 +0300] conn=40148 op=3 UNBIND [25/Nov/2019:17:29:41.142807994 +0300] conn=40148 op=3 fd=206 closed - U1 Now I am stuck at this point. I don't understand, what is wrong with dogtag, is it LDAP entry trouble or dogtags itself. There are some errors in "getcert list" output,

2 1

OTP implementation
by mizuki 25 Nov '19

25 Nov '19

Hi all, We started looking into OTP features provided by IPA in our facility. In our environment, majority of our machines are located in the private network, users access them via external-facing Gateways. We want to enforce MFA on our gateway and allow users to have freedom SSH-ing into any internal nodes using their regular passwords (or keys). Then add HBAC rules for certain hosts/services who require MFA authentications using OTP (for example, protected web resource access. NX etc) In order to achieve that, it seems to me we need turn on both 'password' and 'otp' for individual users or globally. This will then trigger 'password' for SSH and 'otp' auth for WebApps/NX and so on. However when I looked at the online document @ https://www.freeipa.org/page/V4/OTP#Implementation , it stated "*Mixing the "password" and "otp" user auth types should not be used*", I wonder why "mixing" is not recommended, and what is the downside if we implement this way(in order to achieve what we're trying to do), or any other better strategies in this case? Can some advice? Thank you in advance! Mizuki

1 0

FreeIPA certificates to create a keystore
by Hernán Fernández 25 Nov '19

25 Nov '19

Hello, I have a FreeIPA server and about 7 nodes, each node has a certificate and a key. I got those host certificates with: ipa-getcert request -v -f /etc/security/certificates/host.crt -k /etc/security/certificates/host.key I can see the CA certificate it's located at /etc/ipa/ca.crt. Where is the CAKey file?. I need to create a Keystore for the host. Thanks -- Hernán Fernández

2 2

Certificate Renewal less than 28days
by Christof Schulze 25 Nov '19

25 Nov '19

Reading a lot I learned that certificates should be renewed automatically 28 before expiring. But some of Certificates are now on less than 10 days. This is on the CA renewal master: Request ID '20181008075404': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY subject: CN=OCSP Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY expires: 2019-11-30 11:12:26 UTC eku: id-kp-OCSPSigning pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20181008075405': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY subject: CN=CA Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY expires: 2019-11-30 11:11:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20181008075407': status: MONITORING stuck: no key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key' certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY subject: CN=IPA RA,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schulze(a)fau.de,L=CITY expires: 2019-11-30 11:10:54 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Is there a way to get them renewed manually? -- Christof Schulze Email: christof.schulze(a)fau.de

2 5

ipa-getkeytab -r for user keytabs
by Dmitry Perets 25 Nov '19

25 Nov '19

Hi, Is it possible to retrieve an existing user keytab, without resetting the key? I see there is "ipa-getkeytab -r", but it doesn't seem to work for me, at least not for user principals: $ kinit admin <password> $ ipa-getkeytab -p auto -r -k new.auto.keytab Failed to load translations Failed to parse result: Insufficient access rights Failed to get keytab Should I add some permissions to the user "admin"...? --- Regards, Dmitry Perets

3 14

Re: Issues with certificates: X509: KEY_VALUES_MISMATCH
by Dmitri Moudraninets 25 Nov '19

25 Nov '19

Hi Rob, Some good news. I did the same with the secondary server. Now on secondary server I can navigate through GUI with out any errors (authentication->certificates->certificates). But on the first server Subjects are missing and all certificates are grayed-out except one. Another good thing - on both servers I can go to identity->users, then I click on a user who has a personal certificate. And I can see the certificate data via GUI. Also if I run ipa-server-upgrade it fails on a first server with he following message: 2019-11-25T13:34:26Z DEBUG The ipa-server-upgrade command failed, exception: NetworkError: cannot connect to ' https://freeipa.corp.mydomain.de:8443/ca/rest/account/login': [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:618) 2019-11-25T13:34:26Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: NetworkError: cannot connect to ' https://freeipa.corp.mydomain.de:8443/ca/rest/account/login': [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error (_ssl.c:618) 2019-11-25T13:34:26Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information If I run ipa-cert-show 1 on a first server I see this: [root@freeipa ipa]# ipa cert-show 1 ipa: DEBUG: importing all plugin modules in ipaclient.remote_plugins.schema$5131ac65... ipa: DEBUG: importing plugin module ipaclient.remote_plugins.schema$5131ac65.plugins ipa: DEBUG: importing all plugin modules in ipaclient.plugins... ipa: DEBUG: importing plugin module ipaclient.plugins.automember ipa: DEBUG: importing plugin module ipaclient.plugins.automount ipa: DEBUG: importing plugin module ipaclient.plugins.ca ipa: DEBUG: importing plugin module ipaclient.plugins.cert ipa: DEBUG: importing plugin module ipaclient.plugins.certmap ipa: DEBUG: importing plugin module ipaclient.plugins.certprofile ipa: DEBUG: importing plugin module ipaclient.plugins.csrgen ipa: DEBUG: importing plugin module ipaclient.plugins.dns ipa: DEBUG: importing plugin module ipaclient.plugins.hbacrule ipa: DEBUG: importing plugin module ipaclient.plugins.hbactest ipa: DEBUG: importing plugin module ipaclient.plugins.host ipa: DEBUG: importing plugin module ipaclient.plugins.idrange ipa: DEBUG: importing plugin module ipaclient.plugins.internal ipa: DEBUG: importing plugin module ipaclient.plugins.location ipa: DEBUG: importing plugin module ipaclient.plugins.migration ipa: DEBUG: importing plugin module ipaclient.plugins.misc ipa: DEBUG: importing plugin module ipaclient.plugins.otptoken ipa: DEBUG: importing plugin module ipaclient.plugins.otptoken_yubikey ipa: DEBUG: importing plugin module ipaclient.plugins.passwd ipa: DEBUG: importing plugin module ipaclient.plugins.permission ipa: DEBUG: importing plugin module ipaclient.plugins.rpcclient ipa: DEBUG: importing plugin module ipaclient.plugins.server ipa: DEBUG: importing plugin module ipaclient.plugins.service ipa: DEBUG: importing plugin module ipaclient.plugins.sudorule ipa: DEBUG: importing plugin module ipaclient.plugins.topology ipa: DEBUG: importing plugin module ipaclient.plugins.trust ipa: DEBUG: importing plugin module ipaclient.plugins.user ipa: DEBUG: importing plugin module ipaclient.plugins.vault ipa: DEBUG: found session_cookie in persistent storage for principal ' admin(a)CORP.mydomain.DE', cookie: 'ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d' ipa: DEBUG: setting session_cookie into context 'ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;' ipa: INFO: trying https://freeipa.corp.mydomain.de/ipa/session/json ipa: DEBUG: New HTTP connection (freeipa.corp.mydomain.de) ipa: DEBUG: received Set-Cookie (<type 'list'>)'['ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;path=/ipa;httponly;secure;']' ipa: DEBUG: storing cookie 'ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;' for principal admin(a)CORP.mydomain.DE ipa: DEBUG: Created connection context.rpcclient_140099072449040 ipa: DEBUG: raw: cert_show(u'1', version=u'2.230') ipa: DEBUG: cert_show(u'1', version=u'2.230') ipa: INFO: [try 1]: Forwarding 'cert_show/1' to json server ' https://freeipa.corp.mydomain.de/ipa/session/json' ipa: DEBUG: HTTP connection keep-alive (freeipa.corp.mydomain.de) ipa: DEBUG: received Set-Cookie (<type 'list'>)'['ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;path=/ipa;httponly;secure;']' ipa: DEBUG: storing cookie 'ipa_session=MagBearerToken=F24vDMW36nOAh8xZI3Dw9%2b27hmZa1IGrw6xadQQnWsVjp5WFxpJfUcw3ewbovoQGpk5c9QS7xnOTJ9TqOErpti9Z4yT3e2XU1md8%2brrN3nDjuYT2rKazHUDRUq0%2f%2fWk81hXvVfdnWbQ7SoNs0wyrNa3eJu%2fDJABm3qbUW66vcSJA2kVMCI%2bBFYu6GVGZsDAeocu1MlfFL9vvZ49zvsclAA%3d%3d;' for principal admin(a)CORP.mydomain.DE ipa: DEBUG: Destroyed connection context.rpcclient_140099072449040 ipa: ERROR: cannot connect to ' https://freeipa.corp.mydomain.de:443/ca/agent/ca/displayBySerial': [Errno 13] Permission denied on a second server it prints a certificate: [root@freeipa-02 ~]# ipa cert-show 1 Issuing CA: ipa Certificate: MIIDozCC.....uU= Subject: CN=Certificate Authority,O=CORP.MYDOMAIN.DE Issuer: CN=Certificate Authority,O=CORP.MYDOMAIN.DE Not Before: Tue Dec 05 15:31:39 2017 UTC Not After: Sat Dec 05 15:31:39 2037 UTC Serial number: 1 Serial number (hex): 0x1 Revoked: False пн, 25 нояб. 2019 г. в 14:07, Robert Crittenden <rcritten(a)redhat.com>: > I am out of the office until December 2, 2019. > > -- With best regards/Mit freundlichen Grüßen Moudraninets Dmitry, RHCSA http://www.linkedin.com/in/moudraninets http://www.xing.com/profile/Dmitry_Mudraninets

1 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users November 2019