July 2020 - FreeIPA-users - Fedora mailing-lists

IPA DNS ACL (respond with a different IP depending on the requester)
by Daniel PC 24 Oct '25

24 Oct '25

I would like to configure DNS to respond with a different IP depending on the requester source IP. Bind allow it using ACL. Do you know if it is possible to implement this feature on IPA integrated DNS? thank you

3 4

ipa-replica-install -- cannot get past [26/41]: creating DS keytab
by Jonathon Jenkins 10 Jun '25

10 Jun '25

Greetings, I cannot get the ipa-replica-install to proceed past step 26/41 - creating DS keytab. I see the command that is to be run, and I can run that just fine before and after the ipa-replica-install command, and it creates the keytab. I am not sure how to proceed from here - the bug reports I see all pertain to earlier versions, and my files reflect those changes. I have also tried running this with all manner of password flags, which are correct, but still getting insufficient access rights. particulars: centos 7 3.10.0-957.1.3.el7.x86_64 ipa-server-4.6.4-10.el7.centos.x86_64 ipa-common-4.6.4-10.el7.centos.noarch ipa-server-common-4.6.4-10.el7.centos.noarch ipa-client-4.6.4-10.el7.centos.x86_64 ipa-server-dns-4.6.4-10.el7.centos.noarch ipa-client-common-4.6.4-10.el7.centos.noarch * Note: anonymized output below ipapython.ipautil: DEBUG stderr= ipalib.backend: DEBUG Created connection context.ldap2_139891568509776 ipaserver.install.service: DEBUG duration: 7 seconds ipaserver.install.service: DEBUG [26/41]: creating DS keytab [26/41]: creating DS keytab ipalib.frontend: DEBUG raw: service_add(u'ldap/<ipa-replica-host>@<domain>.NET', force=True, version=u'2.229') ipalib.frontend: DEBUG service_add(ipapython.kerberos.Principal('ldap/<ipa-replica-host>@<domain>.NET'), force=True, all=False, raw=False, version=u'2.229', no_members=False) ipalib.frontend: DEBUG raw: host_show(u'<ipa-replica-host>', version=u'2.229') ipalib.frontend: DEBUG host_show(u'<ipa-replica-host>', rights=False, all=False, raw=False, version=u'2.229', no_members=False) ipalib.install.sysrestore: DEBUG Backing up system configuration file '/etc/dirsrv/ds.keytab' ipalib.install.sysrestore: DEBUG -> Not backing up - '/etc/dirsrv/ds.keytab' doesn't exist ipapython.ipautil: DEBUG Starting external process ipapython.ipautil: DEBUG args=/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master> ipapython.ipautil: DEBUG Process finished, return code=9 ipapython.ipautil: DEBUG stdout= ipapython.ipautil: DEBUG stderr=Failed to parse result: Insufficient access rights Retrying with pre-4.0 keytab retrieval method... Failed to parse result: Insufficient access rights Failed to get keytab! Failed to get keytab ipaserver.install.service: DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 570, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 560, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 1308, in request_service_keytab super(DsInstance, self).request_service_keytab() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 742, in request_service_keytab self.run_getkeytab(self.api.env.ldap_uri, self.keytab, self.principal) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 732, in run_getkeytab ipautil.run(args, nolog=nolog) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run raise CalledProcessError(p.returncode, arg_string, str(output)) CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 ipaserver.install.service: DEBUG [error] CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 [error] CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 ipalib.backend: DEBUG Destroyed connection context.ldap2_139891548583120 ipalib.install.sysrestore: DEBUG Backing up system configuration file '/etc/ipa/default.conf' ipalib.install.sysrestore: DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipapython.admintool: 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/ipapython/install/cli.py", line 319, in run return cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 364, in run return self.execute() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 389, in execute for rval in self._executor(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 434, in __runner exc_handler(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 463, in _handle_execute_exception self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 424, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, in <lambda> step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 658, in _configure next(executor) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 434, in __runner exc_handler(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 463, in _handle_execute_exception self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 521, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 518, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 424, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, in <lambda> step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 65, in _install for unused in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/__init__.py", line 622, in main replica_install(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 406, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1431, in install fstore=fstore) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 113, in install_replica_ds setup_pkinit=not options.no_pkinit, File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 419, in create_replica self.start_creation(runtime=30) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 570, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 560, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 1308, in request_service_keytab super(DsInstance, self).request_service_keytab() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 742, in request_service_keytab self.run_getkeytab(self.api.env.ldap_uri, self.keytab, self.principal) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 732, in run_getkeytab ipautil.run(args, nolog=nolog) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 562, in run raise CalledProcessError(p.returncode, arg_string, str(output)) ipapython.admintool: DEBUG The ipa-replica-install command failed, exception: CalledProcessError: Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 ipapython.admintool: ERROR Command '/usr/sbin/ipa-getkeytab -k /etc/dirsrv/ds.keytab -p ldap/<ipa-replica-host>@<domain>.NET -H ldaps://<ipa-replica-master>' returned non-zero exit status 9 ipapython.admintool: ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

3 4

Removal & clean up certificates from o=ipaca
by David Goudet 30 Sep '24

30 Sep '24

Hello all, I have to clean up lot of useless certificate in dirsrv database. Because of resubmit loop on Certmonger client, i have 99,9% of certificate in dirsrv database that are useless and not obsolete (expiration in 2020) (it represent ~85 000 certificates). These useless certificates produce some issues on FreeIPA: - decrease FreeIPA performances on CLI and GUI - increase the LDAP size - increase size and time of FreeIPA backup ... Is it possible to purge these certificates in dirsrv database and how? I found two branches in LDAP directory about these certificates: dn: cn=xxx,ou=ca,ou=requests,o=ipaca dn: cn=yyy,ou=certificateRepository,ou=ca,o=ipaca I can remove all requests and certificates entry from dirsrv database but how it is supported by PKI manager Dogtag (CRL, certificate generation, OCSP)? (This topic has already been discuss on https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost…) Thank you for you help -- David GOUDET LYRA NETWORK IT Operations service Tel : +33 (0)5 32 09 09 74 | Poste : 574

4 7

How to prevent non-admin users of FreeIPA from reading the list of users in the web interface?
by cdknight 16 Apr '24

16 Apr '24

When a user signs in to FreeIPA, I do not want them to be able to view the list of users in my LDAP server under the "Active users" link. I still want them to be able to administer self-service, so they can reset their password, add OTP tokens, etc. How would I go about doing this? The users will only be able to access the web interface, so it doesn't matter whether they can access it from other sources.

5 10

certmonger error on ubuntu
by Robson Francisco de Souza 08 Feb '24

08 Feb '24

Hello! I've been running FreeIPA 4.3.1 on Ubuntu 16.04 for almost two years and most certificates should expire within three weeks. As this deadline approaches, I noticed certmonger has been unable to renew certificates due to the error below. After googling for two days, I found this issue has been observed by many people before, mostly after expiration of the certificates, as in https://tinyurl.com/vajmocw Still, I couldn't find a solution to this problem. If it is impossible to fix this issue while using FreeIPA 4.3.1, I would like to: 1) Find a way to renew all certificates even if certmonger can't be fixed. This would allow me to postpone the solution to after the next OS and/or FreeIPA upgrade 2) Find out what version of FreeIPA I should upgrade to while the operating system remains Ubuntu 16.04 Any help would be appreciated! Thanks! Robson ======> Command: systemctl status certmonger Nov 17 20:53:08 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17 20:53:08 [3873125] Error 77 connecting to https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). Nov 17 21:10:13 ipa.cefapnet.icb.usp.br dogtag-ipa-ca-renew-agent-submit[3875188]: Forwarding request to dogtag-ipa-renew-agent Nov 17 21:10:13 ipa.cefapnet.icb.usp.br dogtag-ipa-ca-renew-agent-submit[3875188]: dogtag-ipa-renew-agent returned 3 Nov 17 21:10:13 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17 21:10:13 [3873125] Error 77 connecting to https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). Nov 17 21:25:20 ipa.cefapnet.icb.usp.br dogtag-ipa-ca-renew-agent-submit[3875738]: Forwarding request to dogtag-ipa-renew-agent Nov 17 21:25:20 ipa.cefapnet.icb.usp.br dogtag-ipa-ca-renew-agent-submit[3875738]: dogtag-ipa-renew-agent returned 3 Nov 17 21:25:21 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17 21:25:21 [3873125] Error 77 connecting to https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). Nov 17 21:25:31 ipa.cefapnet.icb.usp.br dogtag-ipa-ca-renew-agent-submit[3875766]: Forwarding request to dogtag-ipa-renew-agent Nov 17 21:25:31 ipa.cefapnet.icb.usp.br dogtag-ipa-ca-renew-agent-submit[3875766]: dogtag-ipa-renew-agent returned 3 Nov 17 21:25:31 ipa.cefapnet.icb.usp.br certmonger[3873125]: 2019-11-17 21:25:31 [3873125] Error 77 connecting to https://ipa.cefapnet.icb.usp.br:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?). -- Robson Francisco de Souza, PhD Laboratório de Estrutura e Evolução de Proteínas (LEEP/PSEL) Departamento de Microbiologia Instituto de Ciências Biomédicas Universidade de São Paulo Av. Prof. Lineu Prestes, 1374 - Ed. Biomédicas II - Sala 250 - 2o. andar Tel: 3091-0891 Cidade Universitária - CEP 05508-900 - São Paulo - SP - Brasil ---- Robson Francisco de Souza, PhD Protein Structure and Evolution Laboratory (LEEP/PSEL) Microbiology Departament Biomedical Sciences Institute University of Sao Paulo Av. Prof. Lineu Prestes, 1374 - Biomédicas II - Sala 250 Phone: 55-11-3091-0891 Cidade Universitária - ZIP 05508-900 - São Paulo - SP - Brazil

6 10

FreeIPA web session timeout
by Yuri Krysko 11 Jan '24

11 Jan '24

Hello, Could you please advise how to configure FreeIPA web UI user session timeout? Thanks, Yuri ________________________________ LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this e-mail and any files transmitted with it to be protected, proprietary or privileged information intended solely for the use of the named recipient(s). Any disclosure of this material or the information contained herein, in whole or in part, to anyone outside of the intended recipient or affiliates is strictly prohibited. M. C. Dean, Inc. accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of the information contained in it, unless that information is subsequently confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to infringe on any rights of the recipient; any such communication violates company policy. If you are not the intended recipient, any disclosure, copying, distribution, or action taken or omitted in reliance on this information is strictly prohibited by M.C. Dean, Inc.; please notify the sender immediately by return e-mail, delete this communication and destroy all copies.

4 4

Allow sysaccount to view its own entry
by Adam Bishop 09 Nov '23

09 Nov '23

I have a piece of software that tries to look up its own uid to check that LDAP is correctly configured. This check fails because the sysaccount cannot view anything under cn=etc,cn=sysaccounts. Is there an existing permission/privilege that I can use to allow it to read the sysaccounts tree (or better, just its own entry)? Many Thanks, Adam Bishop

4 3

kinit: KDC can't fulfill requested option while renewing credentials - which approach?
by Pieter Baele 19 Sep '23

19 Sep '23

I tried various approached to get Renewable tickets : modifying the kdc modifying krb5.conf using kadmin.local on every replica to modify the principal; which is not working - as designed (?)- in IPA What should I do to get a ticket with the correct R flag from IPA ? I don't think this is SSSD related (the service needing the renewable ticket this way is Apache Storm) Thanks a lot!

3 4

Do keytabs expire?
by Ronald Wimmer 07 Jun '23

07 Jun '23

Hi, today I found out that some entries in a keytab file seemed to have expired: Request ticket server HTTP/mwc.linux.mydomain.at(a)LINUX.MYDOMAIN.AT kvno 4 not found in keytab; keytab is likely out of date Fetching the keytab again with ipa-getkeytab fixed the problem. But why is this happening? Do keytab entries expire? I have not set any custom password or ticket policies. Regards, Ronald

4 13

ipa-replica-install fails when I use custom certificates
by Peter Tselios 08 Feb '23

08 Feb '23

I have installed the ipa server by using the following command: --------- ipa-server-install --realm "EXAMPLE.COM" -p 'password' -a 'password' --hostname="server.example.com" -n example.com --ip-address="10.1.4.2" --dirsrv-cert-file=/etc/pki/tls/private/example.com.pem --dirsrv-cert-file=/etc/pki/tls/certs/example.com.crt --dirsrv-pin='' --http-cert-file=/etc/pki/tls/certs/example.com.crt --http-cert-file=/etc/pki/tls/private/example.com.pem --http-pin='' --ca-cert-file=/etc/pki/ca-trust/source/anchors/myca.pem --ca-cert-file=/etc/pki/ca-trust/source/anchors/mysubca.pem --mkhomedir -N --no-host-dns --unattended --------- Which works perfectly fine. However, I cannot make it work with ipa-replica-install since there is no option for --ca-cert-file. So, how can I install a replica with custom certificates?

6 12

FreeIPA CA failing to login with new admin user
by Stasiek Michalski 19 Dec '22

19 Dec '22

Hello, I installed FreeIPA replica on 4.8.4 on CentOS 8 from 4.4.4 from Fedora 25 with `ipa-replica-install --setup-dns --auto-forwarders`, without `--setup-ca` due to errors, which went fine. I do want to install CA though, which failed when I did `--setup-ca` and then later `ipa-ca-install` with the following error: ``` [4/29]: creating installation admin user Unable to log in as uid=admin-freeipa2.infra.opensuse.org,ou=people,o=ipaca on ldap://freeipa.infra.opensuse.org:389 [hint] tune with replication_wait_timeout [error] NotFound: uid=admin-freeipa2.infra.opensuse.org,ou=people,o=ipaca did not replicate to ldap://freeipa.infra.opensuse.org:389 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ``` Obviously I did try try extending the timeout based on that, but I don't think that was helpful in the end, considering the logs produced by the old server: httpd access_log ``` 192.168.47.90 - - [23/Jul/2020:00:25:36 +0000] "GET /ca/rest/account/login HTTP/1.1" 401 994 ``` server process in journal ``` SSLAuthenticatorWithFallback: Authenticating with BASIC authentication Invalid Credential. at com.netscape.cmscore.authentication.PasswdUserDBAuthentication.authenticate(PasswdUserDBAuthentication.java:167) at com.netscape.cms.realm.PKIRealm.authenticate(PKIRealm.java:63) at com.netscape.cms.tomcat.ProxyRealm.authenticate(ProxyRealm.java:78) at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:94) at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.doSubAuthenticate(SSLAuthenticatorWithFallback.java:37) at com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate(AbstractPKIAuthenticator.java:98) at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.authenticate(SSLAuthenticatorWithFallback.java:47) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:579) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:502) at org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:877) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1539) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1495) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) SSLAuthenticatorWithFallback: Fallback auth header: WWW-Authenticate=Basic realm="Certificate Authority" SSLAuthenticatorWithFallback: Fallback auth return code: 401 SSLAuthenticatorWithFallback: Result: false ``` and from pki logs ``` Failed to authenticate as admin UID=admin-freeipa2.infra.opensuse.org. Error: netscape.ldap.LDAPException: error result (49) ``` I don't particularly know how to proceed from here, since those errors don't mean much to me. I see however it's not just me having issues with `ipa-ca-install` at least similar to this one (although by the looks of it, the reason is already different ;) Thanks in advance for trying, LCP [Stasiek] https://lcp.world/

4 6

Problem running IPA client on IPv6 only connection
by William Muriithi 26 Jul '22

26 Jul '22

Hello, I have an IPA clients that has both IPv4 and IPv6 addresses. One of the IPA client is in the office and hence can reach the IPA server on both IPv4 and IPv6. However, the client outside the LAN can only reach the IPA server over IPv6. I was able to enroll the external client fine over IPv6 and from the logs, all clean. However, when I attempted to ssh, its not able to retreave the user from IPA. The client in the office works fine. I can also make for example LDAP queries and they work over IPv6 fine. It looks like kerberos is somehow however using IPv4. I reached this conclusion after taking a tcpdump when attempting to ssh to the server and the kerberos traffic from the client to IPA is on IPv4. What would I need to do on the IPA client for it to prefer IPv6? I am aware I could remove IPv4 address from DNS, but that would break any communication from IPv4 only systems. Any assistance would be appreaciated. [william@ansible ~]$ ssh root(a)mars.external.example.com Last login: Mon Jan 7 17:19:49 2019 from 65.98.193.94 [root@mars ~]# kinit admin kinit: Cannot contact any KDC for realm 'EXTERNAL.EXAMPLE.COM <http://external.example.com/>' while getting initial credentials [root@mars ~]# ldapsearch -x -b cn=ftp,cn=groups,cn=compat,dc=external,dc=example,dc=com | tail -n 4 result: 0 Success # numResponses: 2 # numEntries: 1 [root@mars ~]# cat /etc/resolv.conf search external.example.com nameserver 2607:4860:6000:a::5 [root@mars ~]# Regards, William

5 10

Could not login with AD user
by Ronald Wimmer 20 Jul '22

20 Jul '22

Today I was not able to log in with an AD user to an IPA client within a test setup. IPA users worked fine. DNS is managed externally. I figured out that the DNS-Record of that particular IPA client has not been created correctly. After having corrected the DNS entry and having dropped the SSSD cache on that client I could login with my AD user. Do you have an explanation for that or was it just a coincidence? Cheers, Ronald

4 13

freeipa/certmonger for openvpn user certificates
by Patrick Spinler 27 Jun '22

27 Jun '22

Hi, I'm setting up an openvpn server and I'd like to use our already existing FreeIPA CA to issue user keys/certs for openvpn's use. Since our OpenVPN box is a freeipa client, I thought it'd be nice to use certmonger to issue and keep up to date these certs. Ergo, I've created a certificate profile: pat@apex-freeipa ~$ ipa certprofile-show --all OpenVPNUserCert dn: cn=OpenVPNUserCert,cn=certprofiles,cn=ca,dc=int,dc=apexmw,dc=com Profile ID: OpenVPNUserCert Profile description: OpenVPN User Certificates Store issued certificates: FALSE objectclass: ipacertprofile, top And also a CA acl. For experimentation (and working vs our test freeipa) I've left this as wide open as I can: [pat@apex-freeipa ~]$ ipa caacl-show --all OpenVPN_User_Certificate_ACL dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com ACL name: OpenVPN_User_Certificate_ACL Enabled: TRUE CA category: all Profile category: all User category: all Host category: all Service category: all ipauniqueid: 6dde33a6-7849-11e9-aa05-525400b52c7b objectclass: ipaassociation, ipacaacl Then, on my openvpn server, I ask for a cert for use for one of my users (myself, in this case): root@apex-openvpn:~# ipa-getcert request -f /etc/openvpn/client/pat.crt -k /etc/openvpn/client/pat.key -r -N 'CN=pat,O=INT.APEXMW.COM' -K pat -g 4096 --profile OpenVPNUserCert New signing request "20190603014016" added. But, it fails due to an access err vs the 'userCertificate' attribute of my account: root@apex-openvpn:~# ipa-getcert list (...snippy snip excess...) Request ID '20190603014016': status: CA_REJECTED ca-error: Server at https://apex-freeipa.int.apexmw.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com'.). stuck: yes key pair storage: type=FILE,location='/etc/openvpn/client/pat.key' certificate: type=FILE,location='/etc/openvpn/client/pat.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes If I look at the dirsrv log, here's the accesses I see for this request (trimmed off the date/time to make the lines a _little_ shorter): root@apex-freeipa slapd-INT-APEXMW-COM# grep conn=178 access | cut -d' ' -f3- conn=178 fd=114 slot=114 connection from 10.10.200.1 to 10.10.200.1 conn=178 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO conn=178 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0025554208 dn="fqdn=apex-openvpn.int.apexmw.com,cn=computers,cn=accounts,dc=int,dc=apexmw,dc=com" conn=178 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL conn=178 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0001319554 conn=178 op=2 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL conn=178 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000979573 conn=178 op=3 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL conn=178 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0000736730 conn=178 op=4 SRCH base="cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaca)(cn=ipa))" attrs="" conn=178 op=4 RESULT err=0 tag=101 nentries=1 etime=0.0000499142 conn=178 op=5 SRCH base="cn=ipa,cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaCaId ipaCaSubjectDN cn ipaCaIssuerDN description" conn=178 op=5 RESULT err=0 tag=101 nentries=1 etime=0.0000482726 conn=178 op=6 SRCH base="cn=apex-freeipa.int.apexmw.com,cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=CA))" attrs=ALL conn=178 op=6 RESULT err=0 tag=101 nentries=1 etime=0.0000950646 notes=U conn=178 op=7 SRCH base="cn=accounts,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=pat(a)INT.APEXMW.COM))" attrs=ALL conn=178 op=7 RESULT err=0 tag=101 nentries=1 etime=0.0002747849 conn=178 op=8 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin" conn=178 op=8 RESULT err=0 tag=120 nentries=0 etime=0.0000135034 conn=178 op=9 SRCH base="cn=request certificate ignore caacl,cn=virtual operations,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass" conn=178 op=9 RESULT err=0 tag=101 nentries=1 etime=0.0000932668 - entryLevelRights: none conn=178 op=10 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="distinguishedName" conn=178 op=10 RESULT err=0 tag=101 nentries=1 etime=0.0000640289 conn=178 op=11 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="telephoneNumber ipaSshPubKey uid krbCanonicalName ipatokenRadiusUserName ipaUserAuthType krbPrincipalExpiration homeDirectory nsAccountLock usercertificate;binary title loginShell uidNumber mail ipaCertMapData memberOf memberofindirect krbPrincipalName givenName gidNumber sn ou userClass ipatokenRadiusConfigLink" conn=178 op=11 RESULT err=0 tag=101 nentries=1 etime=0.0001401737 conn=178 op=12 SRCH base="dc=int,dc=apexmw,dc=com" scope=2 filter="(|(member=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com)(memberUser=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com)(memberHost=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com))" attrs="" conn=178 op=12 RESULT err=0 tag=101 nentries=7 etime=0.0001492344 notes=P pr_idx=0 pr_cookie=-1 conn=178 op=13 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(userPassword=*)" attrs="userPassword" conn=178 op=13 RESULT err=0 tag=101 nentries=1 etime=0.0000524838 conn=178 op=14 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey" conn=178 op=14 RESULT err=0 tag=101 nentries=1 etime=0.0000597589 conn=178 op=15 SRCH base="ipaUniqueID=80b23b30-6a0c-11e9-baa3-525400b52c7b,cn=sudorules,cn=sudo,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="cn" conn=178 op=15 RESULT err=0 tag=101 nentries=1 etime=0.0000379744 conn=178 op=16 SRCH base="ipaUniqueID=5fb3a640-705a-11e9-aa05-525400b52c7b,cn=hbac,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="cn" conn=178 op=16 RESULT err=0 tag=101 nentries=1 etime=0.0000337904 conn=178 op=17 SRCH base="cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com" scope=1 filter="(&(objectClass=ipaassociation)(objectClass=ipacaacl))" attrs="serviceCategory cn ipaMemberCertProfile ipaMemberCa ipaCertProfileCategory memberUser userCategory hostCategory memberHost ipaEnabledFlag ipaCaCategory memberService description" conn=178 op=17 RESULT err=0 tag=101 nentries=2 etime=0.0001647058 conn=178 op=18 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin" conn=178 op=18 RESULT err=0 tag=120 nentries=0 etime=0.0000138321 conn=178 op=19 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="userCertificate" conn=178 op=19 RESULT err=0 tag=101 nentries=1 etime=0.0001475052 - entryLevelRights: none conn=178 op=20 UNBIND conn=178 op=20 fd=114 closed - U1 To begin with, I note that this session does a BIND with 'dn=""', right at the beginning, it's essentially an anonymous bind, yah? That operation near the end, here: op=17 SRCH base="cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com" scope=1 filter="(&(objectClass=ipaassociation)(objectClass=ipacaacl))" seems like it might be kinda key. and indeed, if I attempt to run this by hand as an anonymous bind, I get no results: root@apex-freeipa slapd-INT-APEXMW-COM# ldapsearch -x -h localhost -b dc=int,dc=apexmw,dc=com -s sub "(|(objectClass=ipaassociation)(objectClass=ipacaacl))" # extended LDIF # # LDAPv3 # base <dc=int,dc=apexmw,dc=com> with scope subtree # filter: (|(objectClass=ipaassociation)(objectClass=ipacaacl)) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 It's only if I run this as an _authenticated_ bind, that I can find my ACL: root@apex-freeipa slapd-INT-APEXMW-COM# ldapsearch -x -D "cn=Directory Manager" -W -h localhost -b dc=int,dc=apexmw,dc=com -s sub "(&(objectClass=ipaassociation)(objectClass=ipacaacl))" cn Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=int,dc=apexmw,dc=com> with scope subtree # filter: (&(objectClass=ipaassociation)(objectClass=ipacaacl)) # requesting: cn # # c98b740c-6903-11e9-ad1b-525400b52c7b, caacls, ca, int.apexmw.com dn: ipaUniqueID=c98b740c-6903-11e9-ad1b-525400b52c7b,cn=caacls,cn=ca,dc=int,dc =apexmw,dc=com cn: hosts_services_caIPAserviceCert # 6dde33a6-7849-11e9-aa05-525400b52c7b, caacls, ca, int.apexmw.com dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc =apexmw,dc=com cn: OpenVPN_User_Certificate_ACL # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Is this (using certmonger to auto-issue signed certs/keys for my openvpn users) going to be essentially impossible to do, here? Do I need to go a more traditional route of creating a seperate keystore/certdb, issuing a CSR, and feeding that to FreeIPA to sign? Any advice appreciated, and thanks in advance, -- Pat

4 6

Broken ipa replica
by Giulio Casella 08 May '22

08 May '22

Hi everyone, I'm stuck with a broken replica. I had a setup with two ipa server in replica (ipa-server-4.6.4 on CentOS 7.6), let's say "idc01" and "idc02". Due to heavy load idc01 crashed many times, and was not working anymore. So I tried to redo the replica again. At first I tried to "ipa-replica-manage re-initialize", with no success. Now I'm trying to redo from scratch the replica setup: on idc02 I removed the segments (ipa topologysegment-del, for both ca and domain suffix), on idc01 I removed everything (ipa-server-install --uninstall), then I joined domain (ipa-client-install), and everything is working so far. When doing "ipa-replica-install" on idc01 I get: [...] [28/41]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 22 seconds elapsed [ldap://idc02.my.dom.ain:389] reports: Update failed! Status: [Error (-11) connection error: Unknown connection error (-11) - Total update aborted] And on idc02 (the working server), in /var/log/dirsrv/slapd-MY-DOM-AIN/errors I find lines stating: [20/Mar/2019:09:28:06.545187923 +0100] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning total update of replica "agmt="cn=meToidc01.my.dom.ain" (idc01:389)". [20/Mar/2019:09:28:26.528046160 +0100] - ERR - NSMMReplicationPlugin - perform_operation - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Failed to send extended operation: LDAP error -1 (Can't contact LDAP server) [20/Mar/2019:09:28:26.530763939 +0100] - ERR - NSMMReplicationPlugin - repl5_tot_log_operation_failure - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Received error -1 (Can't contact LDAP server): for total update operation [20/Mar/2019:09:28:26.532678072 +0100] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Unable to send endReplication extended operation (Can't contact LDAP server) [20/Mar/2019:09:28:26.534307539 +0100] - ERR - NSMMReplicationPlugin - repl5_tot_run - Total update failed for replica "agmt="cn=meToidc01.my.dom.ain" (idc01:389)", error (-11) [20/Mar/2019:09:28:26.561763168 +0100] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Replication bind with GSSAPI auth resumed [20/Mar/2019:09:28:26.582389258 +0100] - WARN - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meToidc01.my.dom.ain" (idc01:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. It seems that idc02 remembers something about the old replica. Any hint? Thank you in advance, Giulio

5 10

IPA CA allow CSR SAN names in external domains
by Steve Dainard 14 Mar '22

14 Mar '22

Hello I have a RHEL7 IPA server installed as a subordinate CA. I'd like to be able to add SAN's for a different dns domain than exists in the IPA realm. The dns for 'otherdomain.com' is handled by active directory which my IPA server has a cross-forest trust with. ie: host: client1.ipadomain.com certificate: CN = client1.ipadomain.com, SAN = client1.ipadomain.com, servicename.otherdomain.com When I try to submit this CSR with 'ipa-getcert request' the IPA server denies with: "The service principal for subject alt name servicename.otherdomain.com in certificate request does not exist" It seems that the default CAACL enforces a profile named 'caIPAserviceCert', but I'm having some trouble determining what can be modified (or cloned and changed in a new profile) that would allow the CA to sign a CSR that contains *.ipadomain.com and *.otherdomain.com in the SAN. This is the only section in the profile that contains SAN: policyset.serverCertSet.12.constraint.class_id=noConstraintImpl policyset.serverCertSet.12.constraint.name=No Constraint policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl policyset.serverCertSet.12.default.name=Copy Common Name to Subject Alternative Name Thanks, Steve

3 3

freeipa with sudo and 2FA (OTP)
by John Ratliff 31 Jan '22

31 Jan '22

I'm trying to setup freeipa with OTP. I created a TOTP under my user in freeipa and updated my user to use 2FA (password + OTP). When I try to do sudo, it only asks for my password and it fails every time (presumably because it isn't getting the OTP first). I didn't see anything useful in the sss_sudo logs, even after adding debug_level = 6 in the config. What can I do to further troubleshoot this? Thanks.

4 6

Problems after replacing SSL certificates
by Andreas Bulling 21 Oct '21

21 Oct '21

Dear all, I have recently started using FreeIPA (4.8.1 on Ubuntu) and now wanted to replace the original SSL certificates for the web UI and the LDAP server with official ones issued by our university. I've followed the procedure described here (no errors): https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP I could confirm in the browser that the certificate for the web UI has been replaced and I therefore assume so has the LDAP certificate. Authentication from other hosts/services using LDAP still works but in the server log file I see errors like these for all hosts in the domain: Apr 20 19:57:11 auth krb5kdc[24895]: AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) X: NEEDED_PREAUTH: host/X@X for krbtgt/X@X, Additional pre-authentication required Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12 Apr 20 19:57:11 auth krb5kdc[24895]: AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) X: ISSUE: authtime 1587405431, etypes {rep=18 tkt=18 ses=18}, host/X@X for krbtgt/X@X Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12 Apr 20 19:57:11 auth krb5kdc[24895]: TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) X: ISSUE: authtime 1587405431, etypes {rep=18 tkt=18 ses=18}, host/X@X for ldap/X@X Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12 Also, ipa-certupdate on the respective clients shows ipa-certupdate trying https://X/ipa/json [try 1]: Forwarding 'schema' to json server 'https://X/ipa/json' cannot connect to 'https://X/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727) The ipa-certupdate command failed. Also, I can't login to the web UI anymore. I tried ipa-getkeytab -s X -p HTTP/X@X -k /var/lib/ipa/gssproxy/http.keytab on the freeipa server (followed by ipactl restart) but this didn't help. Any idea/suggestions for how to get everything working again? Thanks a lot!

6 15

User in AD not found by IPA
by Marc Boorshtein 14 Oct '21

14 Oct '21

We added a new account to AD that has a domain trust with FreeIPA. This one user is having an issue where IPA can't find him. The user is in the same OU as other users that work fine. The user is unlocked (userAccountControl is 512) and the userprincipalname is set. When I try to add the user to an id view or an external group IPA gives me the error "trusted domain object not found" . Not really sure where to look next to figure out what's wrong. We see the user when we make LDAP calls to AD. Thanks Marc

4 14

Cannot add externally-signed IPA CA certificate
by Dmitry Perets 27 Aug '21

27 Aug '21

Hi, I am trying to configure FreeIPA as a SubCA, and the "RootCA" is self-made with openssl. So I've signed the FreeIPA's request with my self-signed "root ca" certificate, but it looks like FreeIPA doesn't like it: ipa-server-install --external-cert-file=/root/rootca/rootcacert.pem --external-cert-file=/root/rootca/certs/ipacert.pem <...skipped...> ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR CA certificate CN=RootCA,OU=PRJ,O=COMPANY,L=Bonn,C=DE in /root/rootca/rootcacert.pem, /root/rootca/certs/ipacert.pem is not valid: not a CA certificate ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information The subj above is my self-made root CA cert, so it looks like something is missing in it. But what...? Here is it below, it has the "Basic Constraint" set with CA:TRUE... What else is required, so that FreeIPA accepts it as a root CA? Should I add it somewhere first, before running the ipa-server-install? [root@ipa ~]# openssl x509 -text -noout -in /root/rootca/rootcacert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: C=DE, L=Bonn, O=COMPANY, OU=PRJ, CN=RootCA Validity Not Before: Oct 24 11:43:13 2018 GMT Not After : Oct 21 11:43:13 2028 GMT Subject: C=DE, L=Bonn, O=COMPANY, OU=PRJ, CN=RootCA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: <...skipped...> Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: B3:18:3B:CF:29:D2:A5:D4:AE:94:A5:42:65:A2:D8:12:7C:92:78:81 X509v3 Authority Key Identifier: keyid:B3:18:3B:CF:29:D2:A5:D4:AE:94:A5:42:65:A2:D8:12:7C:92:78:81 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption <...skipped...> Thanks!!

2 2

FreeIPA Upgrade F31 -> F32: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock
by Anthony Joseph Messina 01 Jul '21

01 Jul '21

After upgrading FreeIPA from F31 to F32, on startup I now see a lot of these errors from certmonger, ns-slapd, java, etc. May 08 17:57:28 certmonger[38]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock May 08 17:57:30 ns-slapd[67]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock May 08 17:57:33 dogtag-ipa-renew-agent-submit[143]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock May 08 17:57:42 java[640]: usr/lib/api/apiutil.c Could not open /run/lock/opencryptoki/LCK..APIlock The server seems to come up without issue, but can you point me in the right direction to resolve these errors? freeipa-server-4.8.6-1.fc32.x86_64 opendnssec-2.1.6-5.fc32.x86_64 opencryptoki-3.13.0-1.fc32.x86_64 I've installed a fresh F32 freeipa-server (on a test domain) and I don't see these errors. Thanks. -A -- Anthony - https://messinet.com F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6

7 9

dirsrv hangs soon after reboot
by Kees Bakker 17 May '21

17 May '21

Hey, I'm looking for advice how to analyse/debug this. On one of the masters the dirsrv is unresponsive. It runs, but every attempt to connect it hangs. The command "systemctl status" does not show anything alarming ● dirsrv(a)EXAMPLE-COM.service - 389 Directory Server EXAMPLE-COM. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since vr 2020-04-17 13:46:25 CEST; 1h 33min ago Process: 3123 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=0/SUCCESS) Main PID: 3134 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv(a)EXAMPLE-COM.service └─3134 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-COM -i /var/run/dirsrv/slapd-EXAMPLE-COM.pid apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:13:54 linge.example.com ns-slapd[3134]: GSSAPI client step 2 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:54 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 1 apr 17 15:18:55 linge.example.com ns-slapd[3134]: GSSAPI client step 2 However, an ldapsearch command hangs forever [root@rotte ~]# ldapsearch -H ldaps://linge.example.com -D uid=keesbtest,cn=users,cn=accounts,dc=example,dc=com -W -LLL -o ldif-wrap=no -b cn=users,cn=accounts,dc=example,dc=com '(&(objectClass=person)(memberOf=cn=admins,cn=groups,cn=accounts,dc=example,dc=com))' uid Enter LDAP Password: Even if I use the socket (ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket) the ldapsearch command hangs. "ipactl status" hangs "kinit" hangs -- Kees Bakker

5 16

DNS - trusted-keys via IPA's tools - ?
by lejeczek 03 May '21

03 May '21

hi everybody I want to ask if we have a way of adding trusted-keys? Official/recommended VS by fiddling/non-recommended ? many thanks, L.

1 1

Unable to install ipa client centos 7.5.1804 (Core)
by William Graboyes 17 Feb '21

17 Feb '21

Hello List, I have been searching around for the day and have found an answer for the error I am getting when I am trying to install the client on a brand new install: Version: ipa-client-4.5.4-10.el7.centos.3.x86_64 ipa-client-common-4.5.4-10.el7.centos.3.noarch The error is below (run as root, not via sudo): ipa-client-install Traceback (most recent call last): File "/sbin/ipa-client-install", line 22, in <module> from ipaclient.install import ipa_client_install File "/usr/lib/python2.7/site-packages/ipaclient/install/ipa_client_install.py", line 5, in <module> from ipaclient.install import client File "/usr/lib/python2.7/site-packages/ipaclient/install/client.py", line 34, in <module> from ipalib import api, errors, x509 File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 45, in <module> from pyasn1_modules import rfc2315, rfc2459 File "/usr/lib/python2.7/site-packages/pyasn1_modules/rfc2315.py", line 67, in <module> class DigestedData(univ.Sequence): File "/usr/lib/python2.7/site-packages/pyasn1_modules/rfc2315.py", line 72, in DigestedData namedtype.NamedType('digest', Digest) File "/usr/lib/python2.7/site-packages/pyasn1/type/namedtype.py", line 115, in __init__ self.__ambiguousTypes = 'terminal' not in kwargs and self.__computeAmbiguousTypes() or {} File "/usr/lib/python2.7/site-packages/pyasn1/type/namedtype.py", line 232, in __computeAmbiguousTypes ambigiousTypes[idx] = NamedTypes(*partialAmbigiousTypes, **dict(terminal=True)) File "/usr/lib/python2.7/site-packages/pyasn1/type/namedtype.py", line 114, in __init__ self.__tagToPosMap = self.__computeTagToPosMap() File "/usr/lib/python2.7/site-packages/pyasn1/type/namedtype.py", line 205, in __computeTagToPosMap for _tagSet in tagMap.presentTypes: AttributeError: 'property' object has no attribute 'presentTypes' Any help would be greatly appreciated. Thanks, Bill G.

3 2

Allocation of a new value for DNA range failed
by Ronald Wimmer 03 Dec '20

03 Dec '20

After upgrading to OL 8.1 and replacing all of my 8 IPA servers I ran into this particular problem. Is it right that I need to have an ID range where all DNA ranges have to fit in? And that the DNA range of each IPA server has to be distinct from the ranges of the other IPA servers? I will start by checking each IPA server with ldapsearch -x -D 'cn=Directory Manager' -W -b 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' (according to what Rob wrote on his blog some years ago https://rcritten.wordpress.com/2015/01/05/freeipa-and-no-dna-range/ ) Cheers, Ronald

2 7

FreeIPA, OSX, DockerDesktop
by james liu 14 Oct '20

14 Oct '20

PREP ==== git clone https://github.com/freeipa/freeipa-container.git cd freeipa-container mkdir /tmp/ipa-data docker run --name freeipa-server-container -ti -h ipa.example.test --read-only -v /tmp/ip-data :/data:Z freeipa-server --sysctl net.ipv6.conf.all.disable_ipv6=1 RESULT ====== tar: etc/sysconfig/selinux: Cannot utime: No such file or directory tar: Exiting with failure status due to previous errors QUESTION ========= I'm running DockerDesktop 2.0.4, OSX 10.13.6. Is there a set of commands that will work? Thanks

4 6

yum update problem
by Natxo Asenjo 02 Oct '20

02 Oct '20

hi, after patching our centos 7 hosts to the latest version today, one of the two replicas is having trouble. [root@kdc2 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: STOPPED kadmin Service: STOPPED named Service: STOPPED httpd Service: RUNNING ipa-custodia Service: STOPPED ntpd Service: STOPPED pki-tomcatd Service: RUNNING smb Service: STOPPED winbind Service: STOPPED ipa-otpd Service: STOPPED ipa-dnskeysyncd Service: STOPPED ipa: INFO: The ipactl command was successful and after digging in the logs I come across this in /var/log/ipaupgrade.log: 2019-11-20T18:18:29Z DEBUG stderr= 2019-11-20T18:18:31Z INFO Certmonger certificate renewal configuration already up-to-date 2019-11-20T18:18:31Z INFO [Enable PKIX certificate path discovery and validation] 2019-11-20T18:18:31Z DEBUG Loading StateFile from '/var/lib/ipa/sysupgrade/sysupgrade.state' 2019-11-20T18:18:31Z INFO PKIX already enabled 2019-11-20T18:18:31Z INFO [Authorizing RA Agent to modify profiles] 2019-11-20T18:18:31Z INFO [Authorizing RA Agent to manage lightweight CAs] 2019-11-20T18:18:31Z INFO [Ensuring Lightweight CAs container exists in Dogtag database] 2019-11-20T18:18:31Z DEBUG Created connection context.ldap2_139740162547472 2019-11-20T18:18:31Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket from SchemaCache 2019-11-20T18:18:31Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f17cc24b638> 2019-11-20T18:18:31Z DEBUG Destroyed connection context.ldap2_139740162547472 2019-11-20T18:18:31Z INFO [Adding default OCSP URI configuration] 2019-11-20T18:18:31Z INFO [Ensuring CA is using LDAPProfileSubsystem] 2019-11-20T18:18:31Z INFO [Migrating certificate profiles to LDAP] 2019-11-20T18:18:31Z DEBUG Created connection context.ldap2_139740160021648 2019-11-20T18:18:31Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket from SchemaCache 2019-11-20T18:18:31Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f17cc289b00> 2019-11-20T18:18:31Z DEBUG Destroyed connection context.ldap2_139740160021648 2019-11-20T18:18:31Z DEBUG request GET https://kdc2.l.domain.it:8443/ca/rest/account/login 2019-11-20T18:18:31Z DEBUG request body '' 2019-11-20T18:18:31Z DEBUG response status 401 2019-11-20T18:18:31Z DEBUG response headers Server: Apache-Coyote/1.1 Cache-Control: private Expires: Thu, 01 Jan 1970 01:00:00 CET WWW-Authenticate: Basic realm="Certificate Authority" Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 951 Date: Wed, 20 Nov 2019 18:18:31 GMT 2019-11-20T18:18:31Z 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-20T18:18:31Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2019-11-20T18:18:31Z 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-20T18:18:31Z DEBUG The ipa-server-upgrade command failed, exception: RemoteRetrieveError: Failed to authenticate to CA REST API 2019-11-20T18:18:31Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: RemoteRetrieveError: Failed to authenticate to CA REST API In this kdc I see these errors in getcert list: Request ID '20190220182014': status: MONITORING ca-error: Invalid cookie: u'' stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=L.DOMAIN.IT subject: CN=CA Audit,O=L.DOMAIN.IT expires: 2019-12-05 13:58:24 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190220182015': status: MONITORING ca-error: Invalid cookie: u'' 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=L.DOMAIN.IT subject: CN=OCSP Subsystem,O=L.DOMAIN.IT expires: 2019-12-05 13:58:24 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign 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 '20190220182016': status: MONITORING ca-error: Invalid cookie: u'' 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=L.DOMAIN.IT subject: CN=CA Subsystem,O=L.DOMAIN.IT expires: 2019-12-05 13:58:24 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 '20190220182018': status: MONITORING ca-error: Invalid cookie: u'' 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=L.DOMAIN.IT subject: CN=IPA RA,O=L.DOMAIN.IT expires: 2019-12-05 13:58:44 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 Request ID '20190220182019': status: MONITORING ca-error: Server at " https://kdc2.l.domain.it:8443/ca/agent/ca/profileProcess" replied: 1: Invalid Credential. stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=L.DOMAIN.IT subject: CN=kdc2.l.domain.it,O=L.DOMAIN.IT expires: 2019-12-10 10:57:52 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth,id-kp-emailProtection pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca" track: yes auto-renew: yes I still have a working replica, so I could just reinstall and have a working set in a couple of minutes, but I would like to find out what has gone wrong. The systems are running ipa-server-4.6.5-11.el7.centos.3.x86_64 Any help welcome ;-) Thanks, -- Groeten, natxo

4 12

Replica not renewing IPA certificates
by Roderick Johnstone 02 Oct '20

02 Oct '20

Hi This is freeipa (ipa-server-4.6.5-11.el7_7.3.x86_64) on RHEL7 with freeipa's own internal CA. One of my ipa server replicas (host3) has not renewed its IPA system certificates and is now showing ca-error: Invalid cookie: u'' in the 'getcert list' output for certificates: "auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca", "subsystemCert cert-pki-ca", and the certificate in the file /var/lib/ipa/ra-agent.pem As far as I can see, the sequence of events has been as follows: host3 noticed the certificates needed renewing at 30 Jan 2020 05:37 and certmonger initiated a renewal. The state of those certificates went from MONITORING to CA_WORKING but the certificates were not renewed. The CA renewal master (host1) noticed its same set of certificates (plus "Server-Cert cert-pki-ca") needed renewing at 30 Jan 2020 07:28 and renewed them successfully. Another replica (host2) noticed that its certificates needed renewing at 30 Jan 2020 07:32 and renewed them successfully. At 30 Jan 13:37 on host3 the certificates needing to be renewed went from CA_WORKING back to MONITORING, but 'getcert list' now shows them with: ca-error: Invalid cookie: u'' and they still haven't renewed. I haven't seen certmonger attempt to try the renewal again on host3 (nothing from certmonger in /var/log/messages since 30 Jan 13:37). While I could try a getcert resubmit on host3 to force it to try again, I'd like to know if what I am seeing is the expected behaviour when a replica tried to renew certificates before the renewal master. How long should I have to wait till certmonger on host3 tries again? - I couldn't find any reference to how often certmonger tries the renewal. Rob Crittenden's freeipa-healthcheck script is now showing the following for host3: ERROR: ipahealthcheck.ipa.certs.IPARAAgent: RA agent description does not match 2;16;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM in LDAP and 2;7;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM expected ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040924: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040920: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040921: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040922: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040923: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040925: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040927: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040926: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180831064406: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ERROR: ipahealthcheck.dogtag.ca.DogtagCertsConnectivityCheck: Request for certificate failed, Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) Each of host1, host2 and host3 are showing serial number 16 in ldap using: ldapsearch -D "cn=directory manager" -W -b uid=ipara,ou=people,o=ipaca description At this stage I'm not sure whether this will resolve itself when certmonger tries to renew certificates again or whether I need to be more proactive. I'm happy to supply more logs as necessary. Thanks Roderick

3 3

ipa-replica-install failing
by Mitchell Smith 25 Aug '20

25 Aug '20

Hi list, I wanted to repost this issue with a more appropriate subject line, in case anyone has come across this issue before and has a work around. To provide some context, I have two FreeIPA instances running FreeIPA 4.3.1 on Ubuntu 16.04 LTS. I want to migrate to FreeIPA 4.5.4 running on CentOS 7. I have a way to migrate by dumping all the users out with ldapsearch and adding them to the new instance with ldapadd but it is a bit messy and will result in all users having to reset their password, as it won't let me add in already encrypted passwords. My initial thought was to add the new instance as a replica and then eventually retire the old one. I ran in to some problems with the ‘ipa-replica-install’ command though. I was able to join as a client no problem, but when I went to run ‘ipa-replica-install’ it failed while configuring the directory server component. [25/42]: restarting directory server [26/42]: creating DS keytab [27/42]: ignore time skew for initial replication [28/42]: setting up initial replication [error] DatabaseError: Server is unwilling to perform: modification of attribute nsds5replicareleasetimeout is not allowed in replica entry Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. I thought this might have something to do with differences between 4.3.1 and 4.5.4 but I wasn’t entirely sure. If there is a work around for this issue, it would be a significantly easier transition to the new FreeIPA instance. Cheers, Mitch

3 4

IPA healthcheck for older versions
by Rob Crittenden 24 Aug '20

24 Aug '20

Over the summer we announced the freeipa-healthcheck project which is designed to look at an IdM cluster and look for common problems so you can have some level of assurance that the system is running as it should. It was built against the IPA 4.8.x branch and originally released only for Fedora 29+. It is also included in the newly released RHEL 8.1.0. My curious nature led me to see if it would also work in in the IPA 4.6.x branch. It was a bit of a challenge backing down to Python 2 but I was able to get something working. I tested primarily on Fedora 27 but it should also work in RHEL/CentOS 7 (I smoke tested 7.8). I made an EPEL 7 build in COPR, https://copr.fedorainfracloud.org/coprs/rcritten/ipa-healthcheck/ Enable the repo and do: yum install freeipa-healthcheck Then run: ipa-healthcheck --failures-only Ideally there will be no output but an empty list []. Otherwise the output is JSON and hopefully has enough information to point you in the right direction. Feel free to ask if need help. False positives are always a possibility and many of the checks run independently so it's possible to get multiple issues from a single root problem. It's hard to predict all possible installations so some fine-tuning may be required. I'd recommend running it every now and then at least, like prior to updating IPA packages, creating a new master, etc, if not daily. It will, for example, warn of impending cert expiration. The more feedback I get on it the better and more useful I can make it. This is my own personal backport and is not officially supported by anyone but me. It's preferred to report issues on this mailing list. I'll see them and others may be able to chime in as well. rob

10 32

Replication issue with CSN generator
by Morgan Marodin 11 Aug '20

11 Aug '20

Hi. Into my environment I have two IPA server, replicating each other. They are both 7.6 OS systems, ipa-server RPM version is 4.6.4-10.0.1.el7_6.2.x86_64. The first server installed was srv01 (many years ago), then I installed the replica into srv02 (like a year later the 1st node). When I had a single server I did also a trust with my corporate Active Directory. VMs are running in 2 different hypervisor clusters. Now the replication doesn't works. Into log files I have this error: *[16/Apr/2020:12:25:36.856632697 +0200] - ERR - csngen_adjust_time - Adjustment limit exceeded; value - 23221226, limit - 86400[16/Apr/2020:12:25:36.857909222 +0200] - ERR - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTosrv01.ipa.mydomain.com <http://meTosrv01.ipa.mydomain.com>" (srv01:389): Fatal error - too much time skew between replicas![16/Apr/2020:12:25:36.862233147 +0200] - ERR - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTosrv01.ipa.mydomain.com <http://meTosrv01.ipa.mydomain.com>" (srv01:389): Incremental update failed and requires administrator action* I tried to force the replica, but the limit exceeded problem doesn't allow the sync. I know that the problem is that CSN generator has become grossly skewed. Using the external script readNsState.py I found that there was as offset time for about a month, so ... I waited for a month and then the issue disappeared. But now the offset is about 9 months ... I can't wait so much time :) *[root@srv01 scripts]# ./readNsState.py /etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldifnsState is BAAAAAAAAACCN/xfAAAAAHbiBAAAAAAABCgAAAAAAAANdQAAAAAAAA==Little EndianFor replica cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping tree,cn=con fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state: Replica ID : 4 Sampled Time : 1610364802 Gen as csn : 5ffc37822996500040000 Time as str : Mon Jan 11 12:33:22 2021 Local Offset : 320118 Remote Offset : 10244 Seq. num : 29965 System time : Tue Apr 21 15:03:45 2020 Diff in sec. : -22890577 Day:sec diff : -265:5423nsState is YAAAAAAAAAADLZheAAAAAAAAAAAAAAAAXSgAAAAAAAATAAAAAAAAAA==Little EndianFor replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state: Replica ID : 96 Sampled Time : 1587031299 Gen as csn : 5e982d03001900960000 Time as str : Thu Apr 16 12:01:39 2020 Local Offset : 0 Remote Offset : 10333 Seq. num : 19 System time : Tue Apr 21 15:03:45 2020 Diff in sec. : 442926 Day:sec diff : 5:10926[root@srv02 scripts]# ./readNsState.py /etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldifnsState is AwAAAAAAAABU7p5eAAAAAAAAAAAAAAAAsVNiAQAAAAAAAAAAAAAAAA==Little EndianFor replica cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping tree,cn=con fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state: Replica ID : 3 Sampled Time : 1587474004 Gen as csn : 5e9eee54000000030000 Time as str : Tue Apr 21 15:00:04 2020 Local Offset : 0 Remote Offset : 23221169 Seq. num : 0 System time : Tue Apr 21 15:02:38 2020 Diff in sec. : 154 Day:sec diff : 0:154nsState is YQAAAAAAAAAuLZheAAAAAEUBAAAAAAAA7SYAAAAAAAASAAAAAAAAAA==Little EndianFor replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state: Replica ID : 97 Sampled Time : 1587031342 Gen as csn : 5e982d2e001800970000 Time as str : Thu Apr 16 12:02:22 2020 Local Offset : 325 Remote Offset : 9965 Seq. num : 18 System time : Tue Apr 21 15:02:38 2020 Diff in sec. : 442816 Day:sec diff : 5:10816* As you can see in the 1st node the Time as str is Jan 11 of 2021. With timedatectl command I see that both VMs use the same Time zone and the clock is correct. I found this old article to fix my issue: *https://www.redhat.com/archives/freeipa-users/2014-February/msg00007.html <https://www.redhat.com/archives/freeipa-users/2014-February/msg00007.html>* But ... I had the same issue in the past, always in the 1st server. So, in my mind I don't want to try to use that fix. I have a new hypervisor cluster, so I would prefer to reinstall the 1st server, using these steps: 1) check if all roles (also the CA) is installed in srv02 You can find here some data about the VMs: *[root@srv01 ~]# ipa server-show srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com> Server name: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com> Managed suffixes: domain, ca Min domain level: 0 Max domain level: 1 Enabled server roles: CA server, IPA master, DNS server, NTP server, AD trust controller[root@srv02 ~]# ipa server-show srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> Server name: srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> Managed suffixes: domain, ca Min domain level: 0 Max domain level: 1 Enabled server roles: CA server, IPA master, DNS server, NTP server[root@srv01 ~]# ipa config-show Maximum username length: 32 Home directory base: /home Default shell: /bin/bash Default users group: ipausers Default e-mail domain: ipa.mydomain.com <http://ipa.mydomain.com> Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=IPA.MYDOMAIN.COM <http://IPA.MYDOMAIN.COM> Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> IPA CA servers: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> IPA NTP servers: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> IPA CA renewal master: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>[root@srv02 ~]# ipa config-show Maximum username length: 32 Home directory base: /home Default shell: /bin/bash Default users group: ipausers Default e-mail domain: ipa.mydomain.com <http://ipa.mydomain.com> Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=IPA.MYDOMAIN.COM <http://IPA.MYDOMAIN.COM> Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> IPA CA servers: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> IPA NTP servers: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> IPA CA renewal master: srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>[root@srv01 ~]# ipactl statusDirectory Service: RUNNINGkrb5kdc Service: RUNNINGkadmin Service: RUNNINGnamed Service: RUNNINGhttpd Service: RUNNINGipa-custodia Service: RUNNINGntpd Service: RUNNINGpki-tomcatd Service: STOPPEDsmb Service: RUNNINGwinbind Service: RUNNINGipa-otpd Service: RUNNINGipa-dnskeysyncd Service: RUNNINGipa: INFO: The ipactl command was successful[root@srv02 ~]# ipactl statusDirectory Service: RUNNINGkrb5kdc Service: RUNNINGkadmin Service: RUNNINGnamed Service: RUNNINGhttpd Service: RUNNINGipa-custodia Service: RUNNINGntpd Service: RUNNINGpki-tomcatd Service: STOPPEDipa-otpd Service: RUNNINGipa-dnskeysyncd Service: RUNNINGipa: INFO: The ipactl command was successful[root@srv01 ~]# certutil -L -d /etc/pki/pki-tomcat/aliasCertificate Nickname Trust Attributes SSL,S/MIME,JAR/XPIServer-Cert cert-pki-ca u,u,usubsystemCert cert-pki-ca u,u,ucaSigningCert cert-pki-ca CTu,Cu,CuocspSigningCert cert-pki-ca u,u,uauditSigningCert cert-pki-ca u,u,Pu[root@srv02 ~]# certutil -L -d /etc/pki/pki-tomcat/aliasCertificate Nickname Trust Attributes SSL,S/MIME,JAR/XPIServer-Cert cert-pki-ca u,u,usubsystemCert cert-pki-ca u,u,ucaSigningCert cert-pki-ca CTu,u,uocspSigningCert cert-pki-ca u,u,uauditSigningCert cert-pki-ca u,u,Pu* It seems that AD trust controller role, IPA CA renewal master, smb and windbind are only in the 1st server. And also caSigningCert cert-pki-ca entry is different (CTu,Cu,Cu vs CTu,u,u). I can see only in the 1st server these DNS records: *_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs SRV 0 100 88 srv01_kerberos._tcp.dc._msdcs SRV 0 100 88 srv01_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs SRV 0 100 88 srv01_kerberos._udp.dc._msdcs SRV 0 100 88 srv01_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs 0 100 389 srv01_ldap._tcp.dc._msdcs 0 100 389 srv01* Srv01 is the first master, I know, but is the server VM that has clock problems, in both situations. So I want to keep srv02 and install a new one. What do I have to do to let the 2nd VM be a single server? Could I use these URLs? *https://www.freeipa.org/page/Backup_and_Restore#One_Server_Loss_-_First_Master <https://www.freeipa.org/page/Backup_and_Restore#One_Server_Loss_-_First_Mas…>https://www.freeipa.org/page/V4/Server_Roles#Upgrade <https://www.freeipa.org/page/V4/Server_Roles#Upgrade>* 2) uninstall ipa-server from the 1st server (srv01) and then powering off it, assuming that all data into the 2nd one are ok (srv02) 3) update freeipa and all other RPM packages into the VM srv02 4) install a new fresh VM, always with 7 release, and create a new replica Could I use the same old hostname (srv01) and IP address for this new VM? Or is better to use the same IP but a new name, like srv03? Do you think this is the right way to solve my issue? Or do you have any better idea? Please let me know, thanks. Bye, Morgan

3 8

Docker using PAM on a freeipa host?
by Dominik Vogt 05 Aug '20

05 Aug '20

We have a freeipa server and some clients. One of the clients runs a (minimal) Docker container with some custom application. The application does user authorization and authentication using PAM. Is there a good way to make PAM delegate all decisions to the host running the Docker conainer? We'd like to avoid configuring the container as a separate freeipa client. Ciao Dominik ^_^ ^_^ -- Dominik Vogt

2 3

DNS Delegation
by Christian Hernandez 04 Aug '20

04 Aug '20

I'm having an issue delegating a subdomain. My domain is cloud.chx and I ran the following. ipa dnsrecord-add cloud.chx dc1.ad --a-rec=192.168.1.253 ipa dnsrecord-add 1.168.192.in-addr.arpa. 253 --ptr-rec=dc1.ad.cloud.chx. ipa dnsrecord-add cloud.chx ad --ns-rec=dc1.ad.cloud.chx. I checked and it's in the config [root@ipa1 ~]# dig axfr cloud.chx | grep ad ad.cloud.chx. 86400 IN NS dc1.ad.cloud.chx. dc1.ad.cloud.chx. 86400 IN A 192.168.1.253 But when I query, it doesn't return what I expected. [root@ipa1 ~]# dig dc1.ad.cloud.chx NS ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> dc1.ad.cloud.chx NS ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15346 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dc1.ad.cloud.chx. IN NS ;; Query time: 27 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 30 15:48:03 PDT 2020 ;; MSG SIZE rcvd: 45 The other DNS server is up and running. [root@ipa1 ~]# dig @192.168.1.253 dc1.ad.cloud.chx ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> @192.168.1.253 dc1.ad.cloud.chx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64777 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;dc1.ad.cloud.chx. IN A ;; ANSWER SECTION: dc1.ad.cloud.chx. 3600 IN A 192.168.1.253 ;; Query time: 1 msec ;; SERVER: 192.168.1.253#53(192.168.1.253) ;; WHEN: Thu Jul 30 15:59:21 PDT 2020 ;; MSG SIZE rcvd: 61 This is worth noting that adding +norec works. [root@ipa1 ~]# dig dc1.ad.cloud.chx NS +norec ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> dc1.ad.cloud.chx NS +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36273 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dc1.ad.cloud.chx. IN NS ;; AUTHORITY SECTION: ad.cloud.chx. 86400 IN NS dc1.ad.cloud.chx. ;; ADDITIONAL SECTION: dc1.ad.cloud.chx. 86400 IN A 192.168.1.253 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 30 15:59:39 PDT 2020 ;; MSG SIZE rcvd: 75 Is there anything I'm missing? --- Christian Hernandez, RHCE Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> christian(a)redhat.com Mobile: 626.502.8310 Slack: chernand <https://www.redhat.com/>

4 7

Some users get sshd:auth Permission denied
by TOULMONDE Sébastien (CSC/MST) 03 Aug '20

03 Aug '20

Hi, Yesterday we migrated our dev servers to IPA - to help in the migration, I enabled the allow_all HBAC rule, but despite that, some users get this message: Jul 29 15:56:23 el4966 sshd[98029]: Postponed keyboard-interactive for id094844 from 81.245.6.11 port 35552 ssh2 [preauth] Jul 29 15:56:49 el4966 sshd[98034]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=el1921.bc user=id094844 Jul 29 15:56:49 el4966 sshd[98034]: pam_sss(sshd:auth): received for user id094844: 6 (Permission denied) < ----- This Jul 29 15:56:52 el4966 sshd[98029]: error: PAM: Authentication failure for id094844 from el1921.bc Jul 29 15:56:52 el4966 sshd[98029]: Failed keyboard-interactive/pam for id094844 from 81.245.6.11 port 35552 ssh2 Jul 29 15:56:58 el4966 sshd[98029]: Postponed keyboard-interactive for id094844 from 81.245.6.11 port 35552 ssh2 [preauth] Jul 29 15:57:00 el4966 sshd[98029]: Connection closed by 81.245.6.11 port 35552 [preauth] These are external (AD) users. Weird thing: not all users have this and not everywhere... I tried to remove the LDAP filter on the IPA server -> same thing... I'm running out of ideas... Thanks for your help! S. Toulmonde Sensitivity: Internal Use Only This e-mail cannot be used for other purposes than Proximus business use. See more on https://www.proximus.be/maildisclaimer

2 1

AD trust user logins where their userPrincipalName does not match AD's DNS domain name
by Sam Morris 03 Aug '20

03 Aug '20

I have a FreeIPA setup that trusts an Active Directory domain. I have users who exist in the AD domain, but who are unable to log into Linux systems. The domains are: ad.domain.examaple: the Active Directory domain ipa.ad.domain.example: the FreeIPA domain The user has a SAM-Account-Name of 'user.name' and a userPrincipalName of 'user.name(a)thirdparty.com'. Here are the log messages I see when one of them tries to log in: ==> krb5_child.log <== (Thu Jul 23 11:08:58 2020) [[sssd[krb5_child[2481132]]]] [get_and_save_tgt] (0x0020): 1704: [-1765328378][Client 'user.name\@THIRDPARTY.COM@IPA.AD.DOMAIN.EXAMPLE' not found in Kerberos database] (Thu Jul 23 11:08:58 2020) [[sssd[krb5_child[2481132]]]] [map_krb5_error] (0x0020): 1833: [-1765328378][Client 'user.name\@THIRDPARTY.COM@IPA.AD.DOMAIN.EXAMPLE' not found in Kerberos database] ==> sssd_ipa.ad.domain.example.log <== (Thu Jul 23 11:08:58 2020) [sssd[be[ipa.ad.domain.example]]] [krb5_auth_done] (0x0040): The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information A bit of research brings me to <https://docs.microsoft.com/en-us/windows/win32/ad/naming-properties> which states: A UPN suffix has the following restrictions: It must be the DNS name of a domain, but does not need to be the name of the domain that contains the user. It must be the name of a domain in the current domain forest, or an alternate name listed in the upnSuffixes attribute of the Partitions container within the Configuration container. I believe the user account violates the second of these restrictions, in that its suffix (thirdparty.com) is neither in the AD forest, nor is it found in the upnSuffixes attribute of CN=Partitions,CN=Configuration,DC=ad,DC=domain,DC=example in AD. Now the ugly part. I suspect this is just How Things Are Done around here and getting the user's userPrincipalName changed to ad.domain.example will not be particularly easy. So in the meantime, is there any configuration I can do, either on the FreeIPA servers or on the machine where the user needs to log in, to work around the UPN suffix mismatch? I am able to get a TGT for the user with 'kinit user.name(a)AD.DOMAIN.EXAMPLE', so I guess I'm looking for a hypothetical way to tell sssd to map the UPN suffix in the user's domain (thirdparty.com) to ad.domain.example when it tries to get a ticket during user login... I can also ask to get thirdparty.com added to the AD domain's list of UPN suffixes. Can anyone confirm whether this would be sufficient to get sssd to be able to authenticate the user? Thanks! -- Sam Morris <https://robots.org.uk/>

2 1

Centos 8.2.2004 (Core) not pulling FreeIPA 4.8
by Damjan Kumin 03 Aug '20

03 Aug '20

Hello guys, regardless what officially I do, my Centos is not pulling latest FreeiPA binaries to install, it sticks with 4.7 Since everything is working, it is not a deal-breaker, but still, now that everything is stable and config is absolutely correct, it would be time to upgrade and stay up to date with all fixes. Any help on this topic please? Thanks in advance! rgD

3 5

autofs Troubles
by Ronald Wimmer 30 Jul '20

30 Jul '20

Hi, all over sudden automounting home shares has stopped working on one of our most important servers. The configuration has not changed at all. Automounting on servers with identical configuration works. What i tried so far: 1) stopping rpcidmapd, rpcgssd, autofs, sssd and restarting the services 2) rebooting the system 3) doing ipa-client-automount --uninstall and reconfiguring it again 4) checking /etc/sysconfig/nfs and /etc/idmapd.conf as well as sssd.conf 5) automount -fv tells me that it attemts to mount /home but nothing happens No matter what I tried I could not get homeshares mounted again. I would highly appreciate any input that brings me one step further. Cheers, Ronald

2 2

ssh session timeout on freeipa clients
by Saurabh Garg 28 Jul '20

28 Jul '20

Hi, Can someone please help me find an option if IdM server allows to control the ssh session timeout for user logins on freeipa clients? thanks, sgarg

2 1

Re: krbpasswordexpiration field gone from "ipa user-show" ?
by raymond.spangle＠verizon.com 27 Jul '20

27 Jul '20

The same thing has happened to me. It's in the --raw data, but not in --all. Everything was fine in CentOS 6.x, but CentOS 8.x bombed my scripts with this.

2 2

getting authentication token is no longer valid new one required error
by Kannappan M 27 Jul '20

27 Jul '20

Hi Team, we have cloned one of the linux server which is having ipa user ac lets say 1. server a 2.server b 3. server c 4.server a.1 (clone server) one user has been created in server a.1 , b and c i was able to login to from b to c and c to b but when i tried to login to server b to server a.1 or from c to server a.1 getting error as authentication failed error when i dig deep with the cat /var/log/secure getting message as authentication token is no longer valid; new one required (log messages in server c and server b) when i checked the logs in server a.1 (cat /var/log/secure) pam_sss(sshd:auth): authentication success ; logname= uid = 0 euid=0 tty=ssh ruser= rhost= server c user error:pam: user account has expired for USER from server c please help me to fix it Regards Kanna

1 0

PKI for Windows
by Vinícius Ferrão 24 Jul '20

24 Jul '20

Hello, I need to issue some certificates for the AD Environment and I don’t have ADCS in place. So my FreeIPA deployment was with a self signed CA and the common AD Trust enabled. Now with this issue I’m looking on the IPA’s documentation and there’s some recommendations to deploy IPA as as subCA from ADCS, but as as I said, I don’t have it. So I was thinking if it’s possible to issue certificates for Windows machines directly form FreeIPA, and if this is recommended or not. If it’s possible but it will be a hassle, there’s a way to make FreeIPA talk with ADCS after the deployment? I can setup an ADCS instance to keep Windows certificates in a separate location. I saw this post: https://frasertweedale.github.io/blog-redhat/posts/2019-09-23-direct-integr… but I don’t think it’s the same issue here; the valuable info that I found on this site is about trusting the FreeIPA CA certificate on Windows environment: "Operationally there is one additional step when the IPA CA is not subordinate to the AD CA: the IPA CA certificate has to be explicitly trusted.”; but the use case does not seems to be on a Windows system. Thanks for any guidance.

2 2

Re: ipa-ca-install fails
by Roberto Cornacchia 24 Jul '20

24 Jul '20

Hi, I just wanted thank Rob for the help and give a conclusion to this thread, in case anyone else needs to replicate from some old version like 4.2 I first wanted to replicate from 4.2.4 to 4.8.4 (provided by CentOS 8). Just not possible (4.8 doesn't support replication from level 0). So I decided to first replicate from 4.2 to 4.6.6 (provided by CentOS 7). I got almost at the end, but I found too many incompatibilities. Not worth the effort. My next attempt was from 4.2.4 to 4.4.4 (provided by FC25). This succeeded, but had to upgrade nss to get past https://pagure.io/freeipa/issue/4676 Lesson learned: don't try to skip too many releases. On Fri, 24 Jul 2020 at 15:33, Roberto Cornacchia < roberto.cornacchia(a)gmail.com> wrote: > I actually went further - I'm really close now. > > Hinted by https://bugzilla.redhat.com/show_bug.cgi?id=1158410, I adjusted > /usr/share/pki/server/conf/ciphers.info > /usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py > to use the same ciphers as ipa01. > > This worked, and it got almost to the end (with one step in between - I > needed to open port 8443 on ipa01): > > [root@ipa02 ~]# ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg > Password for admin(a)HQ.SPINQUE.COM: > Directory Manager (existing master) password: > > Run connection check to master > Connection check OK > Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes > [1/27]: configuring certificate server instance > [2/27]: reindex attributes > [3/27]: exporting Dogtag certificate store pin > [4/27]: stopping certificate server instance to update CS.cfg > [5/27]: backing up CS.cfg > [6/27]: disabling nonces > [7/27]: set up CRL publishing > [8/27]: enable PKIX certificate path discovery and validation > [9/27]: starting certificate server instance > [10/27]: setting audit signing renewal to 2 years > [11/27]: restarting certificate server > [12/27]: authorizing RA to modify profiles > [13/27]: authorizing RA to manage lightweight CAs > [14/27]: Ensure lightweight CAs container exists > [15/27]: Ensuring backward compatibility > [16/27]: configure certificate renewals > [17/27]: configure Server-Cert certificate renewal > [18/27]: Configure HTTP to proxy connections > [19/27]: restarting certificate server > [20/27]: updating IPA configuration > [21/27]: enabling CA instance > [22/27]: exposing CA instance on LDAP > [23/27]: migrating certificate profiles to LDAP > [24/27]: importing IPA certificate profiles > [25/27]: adding default CA ACL > [26/27]: adding 'ipa' CA entry > [error] HTTPRequestError: Request failed with status 404: Non-2xx > response from CA REST API: 404. > > The failing call was > https://ipa01.hq.spinque.com:8443/ca/rest/authorities/host-authority. > This comes after a successful POST > https://ipa01.hq.spinque.com:8443/ca/rest/profiles/KDCs_PKINIT_Certs?action… > > The subpath /authorities doesn't seem to exist on ipa01 - probably it > changed. > > Is there a workaround here? > > If not: it was almost at the end. Is it missing crucial steps or can I get > away with it? > > The CA is up, I'm just not sure if it is safe to use. > Can I check its health further than the following? > > [root@ipa02 ~]# ipa server-role-find --role "CA server" > ---------------------- > 2 server roles matched > ---------------------- > Server name: ipa02.hq.spinque.com > Role name: CA server > Role status: enabled > > Server name: ipa01.hq.spinque.com > Role name: CA server > Role status: enabled > ---------------------------- > Number of entries returned 2 > ---------------------------- > > > > On Fri, 24 Jul 2020 at 13:20, Roberto Cornacchia < > roberto.cornacchia(a)gmail.com> wrote: > >> Thanks Rob. >> >> Skipping the key checks got me past that error. So the connection test >> passes! >> >> Unfortunately now I have a cipher issue. >> >> [root@ipa02 ~]# ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg >> Directory Manager (existing master) password: >> >> Run connection check to master >> Connection check OK >> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes >> [1/27]: configuring certificate server instance >> ipaserver.install.dogtaginstance: CRITICAL Failed to configure CA >> instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpkUNbPC' returned >> non-zero exit status 1 >> ipaserver.install.dogtaginstance: CRITICAL See the installation logs and >> the following files/directories for more information: >> ipaserver.install.dogtaginstance: CRITICAL /var/log/pki/pki-tomcat >> >> /var/log/pki/pki-tomcat/ca/debug >> >> [http-bio-8443-exec-3]: ConfigurationUtils: GET >> https://ipa01.hq.spinque.com:443/ca/admin/ca/getCertChain >> javax.ws.rs.ProcessingException: Unable to invoke request >> at >> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287) >> ... >> Caused by: java.io.IOException: SocketException cannot write on socket >> at org.mozilla.jss.ssl.SSLSocket.write(SSLSocket.java:1503) >> >> ipa01:/var/log/httpd/error_log says: >> [:error] [pid 18129] SSL Library Error: -12286 No common encryption >> algorithm(s) with client >> >> I guess it makes sense, old ciphers have been disabled in the newer >> release. >> >> Testing with openssl from ipa02 against ipa01, I found only these being >> accepted: >> AES128-SHA >> DES-CBC3-SHA >> RC4-SHA >> RC4-MD5 >> >> How can I temporarily make ipa-ca-install accept old ciphers? >> Before running ipa-ca-install there is even no pki-tomcat configured on >> ipa02, but running it fails. >> >> Any idea? >> >> On Fri, 24 Jul 2020 at 00:46, Rob Crittenden <rcritten(a)redhat.com> wrote: >> >>> Roberto Cornacchia via FreeIPA-users wrote: >>> > Hi Rob, >>> > >>> > Thanks for the tip. >>> > >>> > I don't see errors that I've found before, but quite some errors. >>> > >>> > In attachment is the result of >>> > grep -v SUCCESS /var/log/httpd/error_log >>> > for today. >>> >>> IPA stopped using memcached in I think version 4.5.0. I guess the key >>> size in the session grew since then. >>> >>> I'm not sure what the best workaround is. On the 4.2 servers you could >>> try to modify /usr/lib/python*/site-packages/ipaserver/session.py and >>> find: >>> >>> self.mc = memcache.Client(self.servers, debug=0) >>> >>> Add check_keys=False to that initialization to not check sizing. That >>> could have other unintended consequences that I'm not aware of. >>> >>> Restart httpd after making this change. >>> >>> > I've also tried to replicate the error that I got with >>> > ipa-replica-install, during the server upgrade step. >>> > I ran ipa-server-upgrade -v on ipa02, and got the same error >>> > "ipaserver.install.ldapupdate: ERROR Add failure attribute "cn" not >>> > allowed". >>> >>> /var/log/ipaserver-upgrade.log should have more context. >>> >>> > >>> > I also see something else that is strane in the output >>> > of ipa-server-upgrade -v: >>> > >>> > Failed to check CA status: cannot connect to >>> > 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus': [Errno 113] >>> No >>> > route to host >>> > >>> > I wonder why 8080. Shouldn't this be on 80? >>> >>> Try opening port 8080. It tries to contact the CA directly and not >>> through the Apache proxy. >>> >>> > >>> > [root@ipa02 ~]# curl >>> > 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus' >>> > curl: (7) Failed connect to ipa01.hq.spinque.com:8080 >>> > <http://ipa01.hq.spinque.com:8080>; No route to host >>> > >>> > [root@ipa02 ~]# curl ' >>> http://ipa01.hq.spinque.com/ca/admin/ca/getStatus' >>> > <?xml version="1.0" encoding="UTF-8" >>> > >>> standalone="no"?><XMLResponse><State>1</State><Type>CA</Type><Status>running</Status><Version>10.2.6-20.fc23</Version></XMLResponse> >>> > >>> > Roberto >>> > >>> > On Thu, 23 Jul 2020 at 19:08, Rob Crittenden <rcritten(a)redhat.com >>> > <mailto:rcritten@redhat.com>> wrote: >>> > >>> > Roberto Cornacchia via FreeIPA-users wrote: >>> > > ipa-replica-conncheck fails with --auto-master-check (used by >>> > > ipa-ca-install), but not without: >>> > > >>> > > >>> > > [root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master >>> > > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com> >>> > <http://ipa01.hq.spinque.com> --auto-master-check >>> > > --realm HQ.SPINQUE.COM <http://HQ.SPINQUE.COM> >>> > <http://HQ.SPINQUE.COM> --hostname >>> > > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com> >>> > <http://ipa02.hq.spinque.com> >>> > > Check connection from replica to remote master >>> > 'ipa01.hq.spinque.com <http://ipa01.hq.spinque.com> >>> > > <http://ipa01.hq.spinque.com>': >>> > > Directory Service: Unsecure port (389): OK >>> > > Directory Service: Secure port (636): OK >>> > > Kerberos KDC: TCP (88): OK >>> > > Kerberos Kpasswd: TCP (464): OK >>> > > HTTP Server: Unsecure port (80): OK >>> > > HTTP Server: Secure port (443): OK >>> > > >>> > > The following list of ports use UDP protocoland would need to be >>> > > checked manually: >>> > > Kerberos KDC: UDP (88): SKIPPED >>> > > Kerberos Kpasswd: UDP (464): SKIPPED >>> > > >>> > > Connection from replica to master is OK. >>> > > Start listening on required ports for remote master check >>> > > 389 tcp: Failed to bind >>> > > 636 tcp: Failed to bind >>> > > 88 tcp: Failed to bind >>> > > 88 udp: Failed to bind >>> > > 464 tcp: Failed to bind >>> > > 464 udp: Failed to bind >>> > > 80 tcp: Failed to bind >>> > > 443 tcp: Failed to bind >>> > > Get credentials to log in to remote master >>> > > Check RPC connection to remote master >>> > > trying https://ipa01.hq.spinque.com/ipa/session/json >>> > > *Connection to https://ipa01.hq.spinque.com/ipa/session/json >>> > failed with >>> > > <ProtocolError for ipa01.hq.spinque.com/ipa/session/json >>> > <http://ipa01.hq.spinque.com/ipa/session/json> >>> > > <http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal >>> > Server Error>* >>> > > trying https://ipa02.hq.spinque.com/ipa/session/json >>> > > [try 1]: Forwarding 'schema' to json server >>> > > 'https://ipa02.hq.spinque.com/ipa/session/json' >>> > > trying https://ipa01.hq.spinque.com/ipa/session/json >>> > > Connection to https://ipa01.hq.spinque.com/ipa/session/json >>> failed >>> > with >>> > > <ProtocolError for ipa01.hq.spinque.com/ipa/session/json >>> > <http://ipa01.hq.spinque.com/ipa/session/json> >>> > > <http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal >>> > Server Error> >>> > > trying https://ipa02.hq.spinque.com/ipa/session/json >>> > > [try 1]: Forwarding 'ping/1' to json server >>> > > 'https://ipa02.hq.spinque.com/ipa/session/json' >>> > > Execute check on remote master >>> > > [try 1]: Forwarding 'server_conncheck' to json server >>> > > 'https://ipa02.hq.spinque.com/ipa/session/json' >>> > > *ERROR: Remote master check failed with following error >>> message(s): >>> > > invalid 'cn': must be "ipa02.hq.spinque.com >>> > <http://ipa02.hq.spinque.com> <http://ipa02.hq.spinque.com>"* >>> > > >>> > > >>> > > Now, without --auto-master-check: >>> > > >>> > > On ipa02 (I suppose the many "Failed to bind" below are >>> expected?): >>> > > [root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master >>> > > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com> >>> > <http://ipa01.hq.spinque.com> --realm >>> > > HQ.SPINQUE.COM <http://HQ.SPINQUE.COM> <http://HQ.SPINQUE.COM> >>> > --hostname ipa02.hq.spinque.com <http://ipa02.hq.spinque.com> >>> > > <http://ipa02.hq.spinque.com> >>> > > Check connection from replica to remote master >>> > 'ipa01.hq.spinque.com <http://ipa01.hq.spinque.com> >>> > > <http://ipa01.hq.spinque.com>': >>> > > Directory Service: Unsecure port (389): OK >>> > > Directory Service: Secure port (636): OK >>> > > Kerberos KDC: TCP (88): OK >>> > > Kerberos Kpasswd: TCP (464): OK >>> > > HTTP Server: Unsecure port (80): OK >>> > > HTTP Server: Secure port (443): OK >>> > > >>> > > The following list of ports use UDP protocoland would need to be >>> > > checked manually: >>> > > Kerberos KDC: UDP (88): SKIPPED >>> > > Kerberos Kpasswd: UDP (464): SKIPPED >>> > > >>> > > Connection from replica to master is OK. >>> > > Start listening on required ports for remote master check >>> > > 389 tcp: Failed to bind >>> > > 636 tcp: Failed to bind >>> > > 88 tcp: Failed to bind >>> > > 88 udp: Failed to bind >>> > > 464 tcp: Failed to bind >>> > > 464 udp: Failed to bind >>> > > 80 tcp: Failed to bind >>> > > 443 tcp: Failed to bind >>> > > Listeners are started. Use CTRL+C to terminate the listening part >>> > after >>> > > the test. >>> > > >>> > > Please run the following command on remote master: >>> > > /usr/sbin/ipa-replica-conncheck --replica ipa02.hq.spinque.com >>> > <http://ipa02.hq.spinque.com> >>> > > <http://ipa02.hq.spinque.com> >>> > > ^C >>> > > Cleaning up... >>> > > >>> > > On ipa01: >>> > > [root@ipa01 ~]# /usr/sbin/ipa-replica-conncheck --replica >>> > > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com> >>> > <http://ipa02.hq.spinque.com> >>> > > Check connection from master to remote replica >>> > 'ipa02.hq.spinque.com <http://ipa02.hq.spinque.com> >>> > > <http://ipa02.hq.spinque.com>': >>> > > Directory Service: Unsecure port (389): OK >>> > > Directory Service: Secure port (636): OK >>> > > Kerberos KDC: TCP (88): OK >>> > > Kerberos KDC: UDP (88): WARNING >>> > > Kerberos Kpasswd: TCP (464): OK >>> > > Kerberos Kpasswd: UDP (464): WARNING >>> > > HTTP Server: Unsecure port (80): OK >>> > > HTTP Server: Secure port (443): OK >>> > > The following UDP ports could not be verified as open: 88, 464 >>> > > This can happen if they are already bound to an application >>> > > and ipa-replica-conncheck cannot attach own UDP responder. >>> > > >>> > > Connection from master to replica is OK. >>> > > >>> > > >>> > > >>> > > On Thu, 23 Jul 2020 at 15:15, Roberto Cornacchia >>> > > <roberto.cornacchia(a)gmail.com >>> > <mailto:roberto.cornacchia@gmail.com> >>> > <mailto:roberto.cornacchia@gmail.com >>> > <mailto:roberto.cornacchia@gmail.com>>> wrote: >>> > > >>> > > Hi, >>> > > >>> > > I have successfully created a replica from a 4.2.4 master >>> (ipa01) >>> > > into a new 4.6.6 master (ipa02). >>> > > >>> > > I did it without --setup-ca option (because it had failed), >>> so the >>> > > only CA is still on the 4.2.4 server (ipa01). >>> > > >>> > > When I try to setup theCA on ipa02 (the same replica file >>> was used >>> > > with ipa-replica-install), this fails: >>> > > >>> > > $ ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg >>> > > Directory Manager (existing master) password: >>> > > >>> > > Run connection check to master >>> > > >>> > > Your system may be partly configured. >>> > > Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> > > >>> > > Connection check failed! >>> > > See /var/log/ipareplica-conncheck.log for more information. >>> > > If the check results are not valid it can be skipped with >>> > > --skip-conncheck parameter. >>> > > >>> > > The log of conncheck (generated by ipa-ca-install) is in >>> > attachment. >>> > > In there, I can see a couple of things going wrong: >>> > > >>> > > ProtocolError: <ProtocolError for >>> > > ipa01.hq.spinque.com/ipa/session/json >>> > <http://ipa01.hq.spinque.com/ipa/session/json> >>> > > <http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal >>> > Server >>> > > Error> >>> > > ... >>> > > 2020-07-23T12:20:50Z ERROR ERROR: Remote master check failed >>> with >>> > > following error message(s): >>> > > invalid 'cn': must be "ipa02.hq.spinque.com >>> > <http://ipa02.hq.spinque.com> >>> > > <http://ipa02.hq.spinque.com>" >>> > > >>> > > Not sure if relevant, but also ipa-replica-install, though it >>> > > completed successfully, gave this error: >>> > > >>> > > Upgrading IPA:. Estimated time: 1 minute 30 seconds >>> > > [1/10]: stopping directory server >>> > > [2/10]: saving configuration >>> > > [3/10]: disabling listeners >>> > > [4/10]: enabling DS global lock >>> > > [5/10]: disabling Schema Compat >>> > > [6/10]: starting directory server >>> > > [7/10]: upgrading server >>> > > ipaserver.install.ldapupdate: ERROR Add failure attribute >>> "cn" >>> > > not allowed >>> > > [8/10]: stopping directory server >>> > > [9/10]: restoring configuration >>> > > [10/10]: starting directory server >>> > > >>> > > >>> > > Could you please help me find the issue? >>> > >>> > Look on ipa01.hq.spinque.com <http://ipa01.hq.spinque.com> in >>> > /var/log/httpd/error_log for those >>> > internal errors. >>> > >>> > rob >>> > >>> > >>> > _______________________________________________ >>> > 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 1

[SSSD-users] Announcing SSSD 2.3.1
by Pavel Březina 24 Jul '20

24 Jul '20

# SSSD 2.3.1 The SSSD team is proud to announce the release of version 2.3.1 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/sssd-2_3_1 See the full release notes at: https://sssd.io/docs/users/relnotes/notes_2_3_1 RPM packages will be made available for Fedora shortly. ## Feedback Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users ## Highlights ### New features - Domains can be now explicitly enabled or disabled using `enable` option in domain section. This can be especially used in configuration snippets. - New configuration options `memcache_size_passwd`, `memcache_size_group`, `memcache_size_initgroups` that can be used to control memory cache size. ### Notable bug fixes - Fixed several regressions in GPO processing introduced in sssd-2.3.0 - Fixed regression in PAM responder: failures in cache only lookups are no longer considered fatal - Fixed regression in proxy provider: `pwfield=x` is now default value only for `sssd-shadowutils` target ### Packaging changes - `libwbclient` is now deprecated and is not being built by default (use `--with-libwibclient` to build it) ### Documentation Changes - Added option `memcache_size_passwd` - Added option `memcache_size_group` - Added option `memcache_size_initgroups` - Added option `enable` in domain sections - Minor text improvements

1 0

ipa-ca-install fails
by Roberto Cornacchia 24 Jul '20

24 Jul '20

Hi, I have successfully created a replica from a 4.2.4 master (ipa01) into a new 4.6.6 master (ipa02). I did it without --setup-ca option (because it had failed), so the only CA is still on the 4.2.4 server (ipa01). When I try to setup theCA on ipa02 (the same replica file was used with ipa-replica-install), this fails: $ ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg Directory Manager (existing master) password: Run connection check to master Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Connection check failed! See /var/log/ipareplica-conncheck.log for more information. If the check results are not valid it can be skipped with --skip-conncheck parameter. The log of conncheck (generated by ipa-ca-install) is in attachment. In there, I can see a couple of things going wrong: ProtocolError: <ProtocolError for ipa01.hq.spinque.com/ipa/session/json: 500 Internal Server Error> ... 2020-07-23T12:20:50Z ERROR ERROR: Remote master check failed with following error message(s): invalid 'cn': must be "ipa02.hq.spinque.com" Not sure if relevant, but also ipa-replica-install, though it completed successfully, gave this error: Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/10]: stopping directory server [2/10]: saving configuration [3/10]: disabling listeners [4/10]: enabling DS global lock [5/10]: disabling Schema Compat [6/10]: starting directory server [7/10]: upgrading server ipaserver.install.ldapupdate: ERROR Add failure attribute "cn" not allowed [8/10]: stopping directory server [9/10]: restoring configuration [10/10]: starting directory server Could you please help me find the issue?

2 5

Users won't migrate despite filters?
by Alfred Victor 23 Jul '20

23 Jul '20

Hi all, We're performing some migrate-ds and noticed some missing users. We took a closer look and the errors are: <redacted user>: attribute "givenName" not allowed <redacted user>: attribute "givenName" not allowed <redacted user>: attribute "departmentNumber" not allowed <redacted user>: attribute "departmentNumber" not allowed <redacted user>: attribute "departmentNumber" not allowed This is odd, because this OU is being grabbed with some filters which should specifically ignore these attributes. The old environment is OpenLDAP and the migrate-ds command is as follows: ipa migrate-ds --schema=RFC2307 --base-dn="dc=<redacted>,dc=com" --bind-dn="cn=<redacted>,ou=<redacted>,dc=<redacted>,dc=com" --ca-cert-file=/etc/ssl/certs/ca.crt ldaps://<redacted> --user-container=ou=<redacted> --user-objectclass=posixaccount --group-container=ou=group --group-objectclass=posixgroup --user-ignore-attribute="sn,ldappublickey,sshpublickey,givenName,departmentNumber" --user-ignore-objectclass={person,organizationalPerson,inetOrgPerson,departmentNumber,givenName,ldappublickey,sshpublickey} Regards, Alfred

2 6

Replica from 4.2 to 4.8
by Roberto Cornacchia 22 Jul '20

22 Jul '20

Hi, I currently have a single 4.2.4 server. I would like to create a replica with 4.8 and later decommission the 4.2 server. I had tested the procedure a while ago, from 4.2 to 4.6. I had created a replica package from the old instance, and used it with ipa-replica-install to create the new one. However, I see that 4.8 no longer supports level 0. Does this mean I cannot do this replica in one go? I also see that ipa-replica-install does not accept the replica package in input. So I suppose it only supports the upgrade to master of an existing client. What is the best route for my 4.2 -> 4.8 replica? Thanks, Roberto

1 0

cacerts and ipa-client-install
by Ben Aveling 22 Jul '20

22 Jul '20

The man page for ipa-client-install has a list of files that are replaced/created/updated. It's not completely up to date. I'm sure if it's worth the effort of keeping it up to date or not. On the one hand, it's probably a bit of work to get it up to date and keep it up to date. On the other hand, If it were up to date, it could be useful for people who want to be able to do a selective backup, prior to installing, or just want to see what changes. If we don't want to keep it up to date, we should probably explain what the criteria for including files in the list is, while being clear that this isn't the full list. If we do want to bring it up to date, it should possibly also include : Files always created (replacing existing content): - /etc/pki/ca-trust/source/ipa.p11-kit Files updated, existing content is maintained: - /etc/pki/ca-trust/extracted/java/cacerts Does IPA depend on the entries that it adds to cacerts? Or does it just put them there in case some other application needs them?

2 1

Enforce the creation of home directory in IdM managed clients
by Saurabh Garg 21 Jul '20

21 Jul '20

Hi All, Is it possible to enforce the creation of home directory without having them ssh/login into the IdM managed clients. Please advice. Thanks, Saurabh Garg

2 1

Initial setup: some questions before proceeding.
by Chathranga Wijekoon 21 Jul '20

21 Jul '20

Hi everyone, We're currently in the process of deploying FreeIPA within our organization and I'd like to ask a few questions before we actually do deploy it to make sure I'm not getting anything wrong. We don't have an ActiveDirectory system, and our preference for OpenSource means we most likely never will. 1. Is there any requirement for FreeIPA to have a public (internet facing) connection if we already have an existing P2P link with our data-centers? 2. We are placing all IPA servers under a separate sub-domain of our primary domain. Are there any pitfalls to this or anything we should look out for before doing this? 3. We thought of changing the ca-subject and subject bases to CN=Certificate Authority,OU=IPA,OU=Identity Management,OU=<IT OU>,O=<OUR ORGANIZATION>,C=LK and OU=IPA,OU=Identity Management,OU=<IT OU>,O=<OUR ORGANIZATION>,C=LK respectively. Will there be any problems in doing this? Thanks in advance for any replies, Chathranga Wijekoon.

1 0

username has domain in it
by Chris Roadfeldt 20 Jul '20

20 Jul '20

This is probably a simple change, but a few weeks ago after an update of my fedora 31 freeipa server and clients, usernames are now displaying with the freeipa domain in the standard email format (username(a)sample.com) minus the () obviously. This caused some issues with processes that were looking for the previous format (username), looking at you cron... Anyway, I'd like to restore the previous username format to (username). I attempted to track down the change / update that did this, but was unable to. I've attempted to set a default domain in sssd which did not change the behavior. Not sure if this is a change in data returned from freeipa / ldap / kerberos or something in PAM. I can login with just the username, minus the domain, but all command prompts and environment variables contain (username(a)sample.com) as the username. What changed and how do I restore the previous username format? Thanks! Chris

1 1

ldap_bind: Invalid credentials (49)
by Dwija D 20 Jul '20

20 Jul '20

Hi I am trying to search ldap user using the following command but with invalid credentials error: # ldapsearch -x -h ldap://ipm.example.net <http://ldaps//idm.example.net> -p 389 -b "*dc=example,dc=net*" -D " *uid=ldapbind,cn=users,cn=account,dc=example,dc=net*" uid=ambariadmin1 -W Enter LDAP Password: *ldap_bind: Invalid credentials (49)* I have double checked the password but the error still persists. Before that, i have added a ldap bind user with the following procedure *[root@example ~]# cat ldapbind.ldif* dn: uid=ldapbind,cn=users,cn=accounts,dc=example,dc=net changetype: add objectclass: account objectclass: simplesecurityobject uid: ambaribind userPassword: secret123 passwordExpirationTime: 20380119031407Z nsIdleTimeout: 0 *[root@example ~]# ldapmodify -h **example.net* <http://example.net/>* -p 389 -x -D "cn=Directory Manager" -w 'secret123' -f ldapbind.ldif* adding new entry "uid=ldapbind,cn=users,cn=accounts,dc=example,dc=net" *[root@example ~]# ipa user-show ambaribind --raw --all* dn: uid=ldapbind,cn=users,cn=accounts,dc=example,dc=net uid: ldapbind nsaccountlock: FALSE has_password: TRUE has_keytab: FALSE objectClass: account objectClass: simplesecurityobject objectClass: top Without bind user, i can search the user *[root@example ~]# ldapsearch -x -h * *ipa.example.net* <http://idm.infodetics.net/>* -p 389 -b "cn=ambari,dc=example,dc=net" uid=ambariadmin1* Can any one plz guide me where is the issue ? Regards

2 2

Re: Looking for help to get my IPA server running again
by Florence Blanc-Renaud 17 Jul '20

17 Jul '20

On 7/16/20 4:54 PM, Lorenz Braun wrote: > On 16.07.20 15:50, Florence Blanc-Renaud wrote: >> On 7/16/20 3:00 PM, Lorenz Braun via FreeIPA-users wrote: >>> I was thinking something similar. I tried >>> ``` >>> [root@ipa01 ~]# ipa-cacert-manage renew >>> Renewing CA certificate, please wait >>> Error resubmitting certmonger request '20200716071025', please check >>> the request manually >>> The ipa-cacert-manage command failed. >>> ``` >> >> Hi, >> this command is used to renew IPA CA certificate and not applicable to >> the current situation. IPA CA has ~20 years validity and this cert is >> unlikely to be expired. > Good to know, thanks! >>> ``` >>> [root@ipa01 ~]# getcert list >>> Number of certificates and requests being tracked: 9. >>> [...] >>> Request ID '20200716071025': >>> status: CA_UNREACHABLE >> This is expected in your case as pki is down, and won't be able to >> manage the certificate renewal request. >> >>> ca-error: Internal error >>> stuck: no >>> key pair storage: >>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert >>> cert-pki-ca',token='NSS Certificate DB',pin set >>> certificate: >>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert >>> cert-pki-ca',token='NSS Certificate DB' >>> CA: dogtag-ipa-ca-renew-agent >>> issuer: CN=Certificate Authority,O=EXAMPLE.COM >>> subject: CN=Certificate Authority,O=EXAMPLE.COM >>> expires: 2040-07-16 07:08:27 UTC >>> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign >>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad >>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert >>> "caSigningCert cert-pki-ca" >>> track: yes >>> auto-renew: yes >>> [...] >>> ``` >>> >>> The other one are all MONITORING and expire at 2022. Since i tried to >>> force a new cert maybe this is still okay and the problem lies >>> somewhere else? >> >> Then the problem is different. Since the new certs will expire 2022 >> (in 2 years), I suspect that they were renewed recently but the >> renewal failed in the middle. >> >> You can refer to [1] in order to ensure that this is the root cause >> and fix the current situation. >> >> HTH, >> flo >> >> [1] >> https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomca… >> > I have checked and the certificate from /etc/pki/pki-tomcat/alias and > ldap are the exactly the same. I attached > /var/log/pki/pki-tomcat/ca/debug. The error message there is different: > ``` > [16/Jul/2020:16:24:57][profileChangeMonitor]: SignedAuditLogger: event > CLIENT_ACCESS_SESSION_ESTABLISH > 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) > at > com.netscape.cmscore.ldapconn.PKISocketFactory.makeSSLSocket(PKISocketFactory.java:120) > > at > com.netscape.cmscore.ldapconn.PKISocketFactory.makeSocket(PKISocketFactory.java:159) > > at netscape.ldap.LDAPConnSetupMgr.connectServer(Unknown Source) > at netscape.ldap.LDAPConnSetupMgr.openSerial(Unknown Source) > at netscape.ldap.LDAPConnSetupMgr.connect(Unknown Source) > at netscape.ldap.LDAPConnSetupMgr.openConnection(Unknown Source) > at netscape.ldap.LDAPConnThread.connect(Unknown Source) > at netscape.ldap.LDAPConnection.connect(Unknown Source) > at netscape.ldap.LDAPConnection.connect(Unknown Source) > at netscape.ldap.LDAPConnection.connect(Unknown Source) > at > com.netscape.cmscore.ldapconn.LdapBoundConnection.<init>(LdapBoundConnection.java:82) > > at > com.netscape.cmscore.ldapconn.LdapBoundConnFactory$BoundConnection.<init>(LdapBoundConnFactory.java:531) > > at > com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:187) > > at > com.netscape.cmscore.ldapconn.LdapBoundConnFactory.getConn(LdapBoundConnFactory.java:332) > > at > com.netscape.cmscore.ldapconn.LdapBoundConnFactory.getConn(LdapBoundConnFactory.java:295) > > at > com.netscape.cmscore.profile.LDAPProfileSubsystem.run(LDAPProfileSubsystem.java:426) > > at java.lang.Thread.run(Thread.java:748) > [...] > [16/Jul/2020:16:24:57][profileChangeMonitor]: Can't create master > connection in LdapBoundConnFactory::getConn! Could not connect to LDAP > server host ipa01.example.com port 636 Error > netscape.ldap.LDAPException: Unable to create socket: > java.net.ConnectException: Connection refused (Connection refused) (-1) > [16/Jul/2020:16:24:57][authorityMonitor]: Can't create master connection > in LdapBoundConnFactory::getConn! Could not connect to LDAP server host > ipa01.example.com port 636 Error netscape.ldap.LDAPException: Unable to > create socket: java.net.ConnectException: Connection refused (Connection > refused) (-1) > ``` > > Firewall is not restricting this and i am a bit puzzled on why the > connection fails. If the service is not running or the port not open > ldapsearch should also not work, right? > I might test a fresh ipa install without restoring any data. Maybe > something with my OS or network is wrong. > You can check with # netstat -tunpl | grep 636 if the ldap server is listening on this port. It's possible that the LDAP server is up but only listening to 389. To see if port 636 is enabled in the server config: # ldapsearch -x -D "cn=directory manager" -W -b cn=config -s base nsslapd-security The attribute value should be "nsslapd-security: on". flo > Best Regards > Lorenz

2 2

Recommendations for FreeIPA implemenation in existing organization
by Thomas Schneider 16 Jul '20

16 Jul '20

Hello, I'm planning to implement FreeIPA in an existing organization that is providing services - DNS - Active Directory - LDAP - Certificates My question for the experts is: What is your best practice / recommendation for implementation of FreeIPA considering the existing services? Should I simply *not activate* services in FreeIPA that already exist, e.g. DNS, Certificates? Regards Thomas

2 1

Looking for help to get my IPA server running again
by Lorenz Braun 16 Jul '20

16 Jul '20

Hi there, i have been running an IPA install (4.5.0) on a CentOS 7 server for quite a while and had some problems with it. Eventually everything got worse and now it is not really usable anymore. It started with someone accidentally shutting down the server. From that point one of the services did not run anymore. Not 100% sure but i think it was pki-tomcat. I "fixed" it temporarily by using the '--ignore-service-failures' flag with ipactl. Everything seemed fine until about one or two weeks ago. Some Clients could sometimes not get kerberos tickets. I couldn't quite figure out why. I used 'ipa-backup --data' in hopes of restoring it on a fresh OS with everything working again. Had to upgrade to IPA 4.6.6. It worked with 'ipa-restore --data --backend=userRoot'. 'kinit' works, but i can't use any 'ipa ...' commands. Here an example: ``` [root@ipa01 ~]# ipa -v user-find --all ipa: INFO: trying https://ipa01.example.com/ipa/json ipa: INFO: [try 1]: Forwarding 'schema' to json server 'https://ipa01.example.com/ipa/json' ipa: ERROR: No valid Negotiate header in server response ``` /var/log/httpd/error_log: ``` [Thu Jul 16 10:40:27.007724 2020] [auth_gssapi:error] [pid 2210] [client xx.xx.xx.1:40920] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ( SPNEGO cannot find mechanisms to negotiate)], referer: https://ipa01.example.com/ipa/xml ``` /var/log/messages: ``` [...] Jul 16 10:40:26 ipa01 gssproxy: [CID 14][2020/07/16 08:40:26]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-httpd", euid: 48,socket: (null) Jul 16 10:40:26 ipa01 gssproxy: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: BOTH initiator_time_req: 0 acceptor_time_req: 0 ) Jul 16 10:40:26 ipa01 gssproxy: gssproxy[2408]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, Preauthentication failed Jul 16 10:40:26 ipa01 gssproxy: GSSX_RES_ACQUIRE_CRED( status: { 851968 { 1 2 840 113554 1 2 2 } 2529638936 "Unspecified GSS failure. Minor code may provide more information" "Preauthentication failed" [ ] } output_cred_handle: <Null> ) Jul 16 10:40:26 ipa01 gssproxy: [CID 14][2020/07/16 08:40:26]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "ipa-httpd", euid: 48,socket: (null) Jul 16 10:40:26 ipa01 gssproxy: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: BOTH initiator_time_req: 0 acceptor_time_req: 0 ) Jul 16 10:40:27 ipa01 gssproxy: gssproxy[2408]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, Preauthentication failed Jul 16 10:40:27 ipa01 gssproxy: GSSX_RES_ACQUIRE_CRED( status: { 851968 { 1 2 840 113554 1 2 2 } 2529638936 "Unspecified GSS failure. Minor code may provide more information" "Preauthentication failed" [ ] } output_cred_handle: <Null> ) Jul 16 10:40:34 ipa01 [sssd[ldap_child[15047]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection. [...] ``` Does anyone know how to fix this or debug it further? I still have a snapshot of the old ipa machine if that helps. I am also thinking about just backing up the user database (usernames and passwords, everything else is nice but not required) and using a fresh install with just the user data. I how much different this would be from what i have done now to be honest. Re-installing the clients is not much work for me, because it is well automated and there are few clients anyway. I hope this was not too long and convoluted. I'll be glad about any help. Best regards Lorenz

2 3

certmapdata issue
by Shane Frasier 16 Jul '20

16 Jul '20

Hello, I have users who kinit using their PIV (smartcard) certificates. Everything works great for users who happen to be "full" employees, but contractors' certificates never match. "Full" employees have certificates issues by: OU=DHS CA4,OU=Certification Authorities,OU=Department of Homeland Security,O=U.S. Government,C=US Their certificates are issued to, for example: CN=JOHN J SMITH+UID=0123456789.DHS HQ,OU=People,OU=DHS HQ,OU=Department of Homeland Security,O=U.S. Government,C=US Contractors have certificates issued by: OU=DHS CA4,OU=Certification Authorities,OU=Department of Homeland Security,O=U.S. Government,C=US Their certificates are issued to, for example: CN=MAX M MUSTERMANN (affiliate)+UID=0123456789.DHS HQ,OU=People,OU=DHS HQ,OU=Department of Homeland Security,O=U.S. Government,C=US I have the usual certificate mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}) I also have a simple matching rule: <ISSUER>O=U.S. Government I currently have the following four certificate mapping data entries for each user: * X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,CN=MAX M MUSTERMANN (affiliate)+UID=0123456789.DHS HQ * X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,CN=MAX M MUSTERMANN (affiliate),UID=0123456789.DHS HQ * X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,UID=0123456789.DHS HQ+CN=MAX M MUSTERMANN (affiliate) * X509:<I>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=Certification Authorities,OU=DHS CA4<S>C=US,O=U.S. Government,OU=Department of Homeland Security,OU=DHS HQ,OU=People,UID=0123456789.DHS HQ,CN=MAX M MUSTERMANN (affiliate) Any thoughts as to why the contractors' certificates never match? I assume it has something to do with the "(affiliate)" that appears in their CN. Thanks, Shane Frasier

4 9

LDAP conflicts and ldapsubentry
by David Harvey 16 Jul '20

16 Jul '20

Dear list, I noted from TFM <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h…> that conflicting values have ldapSubEntry and nsds5ReplConflict attributes, however it only mentioned removing the latter. Should we in fact remove ldapsubentry as well when resolving these conflicts? For the two conflicts I had, I noted: 1. cn: ipservices was identical apart from the aforementioned attributes. *laregly resolved but ldapsubentry still in place taking the newer version over old 2. I had a subtly different "cn: System: Read POSIX details of SMB services". Conflicting entries (ipaPermDefaultAttr: uid vs ipaPermDefaultAttr: uidnumber) which I assume to be a schema change during upgrade that borked somehow? * I haven't actioned this one yet given the discrepancy. Recently upgraded packages in centos which took us from 4.7.6 (IIRC) to 4.8.4. Thanks as ever, David

2 2

freshly installed FreeIPA server dies
by Tony Brian Albers 14 Jul '20

14 Jul '20

Hi guys, This is a new install, software used is: ipa-server.x86_64 4.8.4-7.module+el8.2.0+6046+aaa49f96 389-ds-base.x86_64 1.4.2.4-8.module+el8.2.0+5959+cfcaedbd I followed the install instructions in the documentation, and everything went fine. I haven't added any users or groups yet. I have a master and a replica. The master dies, but the replica seems totally happy. I restarted the master yesterday at 13:25. However, after a short time running, the log files in /var/log/pki/pki-tomcat/ca/debug.. starts filling up with java SocketExceptions like these: 2020-07-08 13:57:49 [profileChangeMonitor] SEVERE: Profile change monitor: Caught exception: netscape.ldap.LDAPException: Server or network error (81) netscape.ldap.LDAPException: Server or network error (81) at netscape.ldap.LDAPConnThread.networkError(Unknown Source) at netscape.ldap.LDAPConnThread.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) 2020-07-08 13:57:49 [AuthorityMonitor] WARNING: AuthorityMonitor: Failed to execute LDAP search for lightweight CAs: netscape.ldap.LDAPException: Server or network error (81) netscape.ldap.LDAPException: Server or network error (81) at netscape.ldap.LDAPConnThread.networkError(Unknown Source) at netscape.ldap.LDAPConnThread.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) 2020-07-08 13:57:49 [profileChangeMonitor] SEVERE: Unable to create socket: java.net.SocketException: Network is unreachable (connect failed) java.net.SocketException: Network is unreachable (connect failed) ... So it's pretty obvious that the LDAP server is not working properly. In /var/log/dirsrv/slapd-YAK2-NET/errors I see: 389-Directory/1.4.2.4 B2020.121.2358 fipa001.yak2.net:636 (/etc/dirsrv/slapd-YAK2-NET) [08/Jul/2020:13:25:36.982866396 +0200] - INFO - slapd_extract_cert - CA CERT NAME: YAK2.NET IPA CA [08/Jul/2020:13:25:37.002136210 +0200] - WARN - Security Initialization - SSL alert: Sending pin request to SVRCore. You may need to run systemd-tty-ask-password-agent to provide the password. [08/Jul/2020:13:25:37.030257707 +0200] - INFO - slapd_extract_cert - SERVER CERT NAME: Server-Cert [08/Jul/2020:13:25:37.049921505 +0200] - INFO - Security Initialization - SSL info: Enabling default cipher set. [08/Jul/2020:13:25:37.074564197 +0200] - INFO - Security Initialization - SSL info: Configured NSS Ciphers [08/Jul/2020:13:25:37.091262372 +0200] - INFO - Security Initialization - SSL info: TLS_AES_128_GCM_SHA256: enabled ... All ciphers enabled ... [08/Jul/2020:13:25:37.601009917 +0200] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, ma x: TLS1.2 [08/Jul/2020:13:25:37.616336615 +0200] - INFO - Security Initialization - slapd_ssl_init2 - NSS adjusted SSL version range: min: TLS1.2, max: TLS1.2 ... [08/Jul/2020:13:25:38.547791102 +0200] - NOTICE - bdb_start - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [08/Jul/2020:13:25:38.792474100 +0200] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher AES [08/Jul/2020:13:25:38.817182778 +0200] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [08/Jul/2020:13:25:38.852524974 +0200] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher 3DES [08/Jul/2020:13:25:38.871423186 +0200] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [08/Jul/2020:13:25:38.880537833 +0200] - ERR - attrcrypt_init - All prepared ciphers are not available. Please disable attribute encryption. [08/Jul/2020:13:25:38.891681971 +0200] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher AES [08/Jul/2020:13:25:38.916694998 +0200] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [08/Jul/2020:13:25:38.925787580 +0200] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher 3DES [08/Jul/2020:13:25:38.934688993 +0200] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value. [08/Jul/2020:13:25:38.943696327 +0200] - ERR - attrcrypt_init - All prepared ciphers are not available. Please disable attribute encryption. [08/Jul/2020:13:25:38.963177992 +0200] - ERR - schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [08/Jul/2020:13:25:39.005290186 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=dns,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.016002719 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=dns,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.025021142 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=keys,cn=sec,cn=dns,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.034249703 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=dns,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.043141171 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=dns,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.052203339 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=groups,cn=compat,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.061377434 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=computers,cn=compat,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.070224153 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=ng,cn=compat,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.079482188 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target ou=sudoers,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.088423317 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=users,cn=compat,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.097485949 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.106344275 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.115510556 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.124588060 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.133557279 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.142529788 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.151543892 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.160697059 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.169730169 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.178596620 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.187737945 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=vaults,cn=kra,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.200014978 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=ad,cn=etc,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.215529397 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki- ca,cn=ca_renewal,cn=ipa,cn=etc,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.223802735 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki- ca,cn=ca_renewal,cn=ipa,cn=etc,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.223802735 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki- ca,cn=ca_renewal,cn=ipa,cn=etc,dc=yak2,dc=net does not exist [08/Jul/2020:13:25:39.295259710 +0200] - WARN - NSACLPlugin - acl_parse - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [08/Jul/2020:13:25:39.307599195 +0200] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=yak2,dc=net--no CoS Templates found, which should be added before the CoS Definition. ... [08/Jul/2020:13:25:39.414188379 +0200] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload - Disorderly shutdown for replica dc=yak2,dc=net. Check if DB RUV needs to be updated [08/Jul/2020:13:25:39.422657691 +0200] - ERR - set_krb5_creds - Could not get initial credentials for principal [ ldap/fipa001.yak2.net(a)YAK2.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [08/Jul/2020:13:25:39.431578492 +0200] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload - Disorderly shutdown for replica o=ipaca. Check if DB RUV needs to be updated [08/Jul/2020:13:25:39.441463670 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=caTofipa002.yak2.net" (fipa002:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [08/Jul/2020:13:25:39.458768924 +0200] - ERR - set_krb5_creds - Could not get initial credentials for principal [ ldap/fipa001.yak2.net(a)YAK2.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [08/Jul/2020:13:25:39.477747370 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofipa002.yak2.net" (fipa002:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [08/Jul/2020:13:25:39.494528440 +0200] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests [08/Jul/2020:13:25:39.503748199 +0200] - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests [08/Jul/2020:13:25:39.512913530 +0200] - INFO - slapd_daemon - Listening on /var/run/slapd-YAK2-NET.socket for LDAPI requests [08/Jul/2020:13:25:39.521834655 +0200] - ERR - schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [08/Jul/2020:13:25:42.619282707 +0200] - ERR - set_krb5_creds - Could not get initial credentials for principal [ ldap/fipa001.yak2.net(a)YAK2.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [08/Jul/2020:13:25:42.660769148 +0200] - ERR - set_krb5_creds - Could not get initial credentials for principal [ ldap/fipa001.yak2.net(a)YAK2.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [08/Jul/2020:13:25:44.517541271 +0200] - ERR - schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=yak2,dc=net [08/Jul/2020:13:25:44.570564330 +0200] - ERR - schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=yak2,dc=net [08/Jul/2020:13:25:44.614807034 +0200] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=yak2,dc=net [08/Jul/2020:13:25:44.635448724 +0200] - ERR - schema-compat-plugin - Finished plugin initialization. [08/Jul/2020:13:25:48.807433248 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofipa002.yak2.net" (fipa002:389): Replication bind with GSSAPI auth resumed [08/Jul/2020:13:25:48.853993542 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=caTofipa002.yak2.net" (fipa002:389): Replication bind with GSSAPI auth resumed [08/Jul/2020:15:00:49.240767214 +0200] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=caTofipa002.yak2.net" (fipa002:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [09/Jul/2020:07:42:10.753040947 +0200] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=caTofipa002.yak2.net" (fipa002:389): Replication bind with GSSAPI auth resumed The log files grow to huge sizes very quickly and fills up the /var filesystem which stops the server. It's not clear to me why this is happening, any advice and tips to get it fixed are appreciated. /tony -- Tony Albers - Systems Architect - IT Development Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142

2 7

OTP Radius 5 seconds timeout
by Sergiy Genyuk 13 Jul '20

13 Jul '20

Hello I have setup radius proxy (DUO) and associate user with it. Everything works except radius timeout. It is 5 seconds and you have to be blazing fast to push the button :-) I did adjust radius timeout in freeipa to 30 seconds but it is still 5 seconds. As well I have tried a trick with krb.conf [otp] settings, same still 5 seconds. Please point me to proper way to change radius timeout. Tested on Centos 8. Freeipa 4.8.4 ipa radiusproxy-find ----------------------------- 1 RADIUS proxy server matched ----------------------------- RADIUS proxy server name: duo2 Server: x.x.x.x Timeout: 30 Retries: 0 ---------------------------- Number of entries returned 1 ---------------------------- Thank you. Sergiy

3 7

kinit -n asking for password on clients
by John Ratliff 13 Jul '20

13 Jul '20

When trying to do pkinit, if I do kinit -n on one of the IdM servers, it works fine. If I try on a client machine, it asks me for the password for WELLKNOWN/ANONYMOUS@REALM. I have the pkinit_anchors setup for the realm. As I'm trying to do anonymous pkinit, I think I don't need a client certificate. On the server, I get this: $ KRB5_TRACE="/dev/stderr" kinit -n [13061] 1518402857.924212: Getting initial credentials for WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM [13061] 1518402857.929673: Sending request (200 bytes) to IDM.EXAMPLE.COM [13061] 1518402857.931830: Initiating TCP connection to stream 10.77.9.101:88 [13061] 1518402857.932241: Sending TCP request to stream 10.77.9.101:88 [13061] 1518402857.939162: Received answer (359 bytes) from stream 10.77.9.101:88 [13061] 1518402857.939180: Terminating TCP connection to stream 10.77.9.101:88 [13061] 1518402857.939284: Response was from master KDC [13061] 1518402857.939380: Received error from KDC: -1765328359/Additional pre-authentication required [13061] 1518402857.939474: Processing preauth types: 16, 15, 14, 136, 19, 147, 2, 133 [13061] 1518402857.939499: Selected etype info: etype aes256-cts, salt "IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params "" [13061] 1518402857.939509: Received cookie: MIT [13061] 1518402857.939563: Preauth module pkinit (147) (info) returned: 0/Success [13061] 1518402857.940352: PKINIT client computed kdc-req-body checksum 9/D98A0144E7E4ACC66B63EBCA98379AB9F055D143 [13061] 1518402857.940369: PKINIT client making DH request [13061] 1518402858.935: Preauth module pkinit (16) (real) returned: 0/Success [13061] 1518402858.956: Produced preauth for next request: 133, 16 [13061] 1518402858.994: Sending request (1408 bytes) to IDM.EXAMPLE.COM [13061] 1518402858.1091: Initiating TCP connection to stream 10.77.9.101:88 [13061] 1518402858.1187: Sending TCP request to stream 10.77.9.101:88 [13061] 1518402858.43063: Received answer (2880 bytes) from stream 10.77.9.101:88 [13061] 1518402858.43088: Terminating TCP connection to stream 10.77.9.101:88 [13061] 1518402858.43198: Response was from master KDC [13061] 1518402858.43258: Processing preauth types: 17, 19, 147 [13061] 1518402858.43273: Selected etype info: etype aes256-cts, salt "IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params "" [13061] 1518402858.43300: Preauth module pkinit (147) (info) returned: 0/Success [13061] 1518402858.44150: PKINIT client verified DH reply [13061] 1518402858.44189: PKINIT client found id-pkinit-san in KDC cert: krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM [13061] 1518402858.44199: PKINIT client matched KDC principal krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM against id-pkinit-san; no EKU check required [13061] 1518402858.62345: PKINIT client used KDF 2B06010502030602 to compute reply key aes256-cts/00E0 [13061] 1518402858.62395: Preauth module pkinit (17) (real) returned: 0/Success [13061] 1518402858.62402: Produced preauth for next request: (empty) [13061] 1518402858.62414: AS key determined by preauth: aes256-cts/00E0 [13061] 1518402858.62547: Decrypted AS reply; session key is: aes256-cts/96F0 [13061] 1518402858.62589: FAST negotiation: available [13061] 1518402858.62692: Initializing KEYRING:persistent:760400007:krb_ccache_f3PFEy1 with default princ WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS [13061] 1518402858.62770: Storing WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM in KEYRING:persistent:760400007:krb_ccache_f3PFEy1 [13061] 1518402858.62846: Storing config in KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: fast_avail: yes [13061] 1518402858.62878: Storing WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krb5_ccache_conf_data/fast_avail/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM@X-CACHECONF: in KEYRING:persistent:760400007:krb_ccache_f3PFEy1 [13061] 1518402858.62933: Storing config in KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: pa_type: 16 [13061] 1518402858.62954: Storing WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krb5_ccache_conf_data/pa_type/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM@X-CACHECONF: in KEYRING:persistent:760400007:krb_ccache_f3PFEy1 But on the client, I get this: $ KRB5_TRACE="/dev/stderr" kinit -n [2941] 1518402820.155827: Getting initial credentials for WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM [2941] 1518402820.156298: Sending request (200 bytes) to IDM.EXAMPLE.COM [2941] 1518402820.158723: Resolving hostname paine.example.com. [2941] 1518402820.159975: Resolving hostname phantom.example.com. [2941] 1518402820.160757: Resolving hostname paine.example.com. [2941] 1518402820.161411: Initiating TCP connection to stream 204.89.253.101:88 [2941] 1518402820.162065: Sending TCP request to stream 204.89.253.101:88 [2941] 1518402820.168495: Received answer (359 bytes) from stream 204.89.253.101:88 [2941] 1518402820.168532: Terminating TCP connection to stream 204.89.253.101:88 [2941] 1518402820.169917: Response was from master KDC [2941] 1518402820.169974: Received error from KDC: -1765328359/Additional pre-authentication required [2941] 1518402820.170029: Processing preauth types: 16, 15, 14, 136, 19, 147, 2, 133 [2941] 1518402820.170051: Selected etype info: etype aes256-cts, salt "IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params "" [2941] 1518402820.170062: Received cookie: MIT Password for WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM: [2941] 1518402833.34612: Preauth module encrypted_timestamp (2) (real) returned: -1765328252/Password read interrupted kinit: Pre-authentication failed: Password read interrupted while getting initial credentials Suggestions on what I'm missing? Thanks.

3 3

It ain't easy to dig a user's last login time info out of IdM/FreeIPA
by White, Daniel E. (GSFC-770.0)[NICS] 10 Jul '20

10 Jul '20

I want to get createtimestamp, krbLastSuccessfulAuth, and krbLastPwdChange for all active users The "ipa user-find" or "ipa user-show" commands only give krbLastPwdChange and failed login count/date The "ipa user-status" command shows "Last successful authentication", but it has to be run for each user I found this suggestion https://www.redhat.com/archives/freeipa-users/2016-May/msg00213.html Could you use ldapsearch? # ldapsearch -Y GSSAPI -b "cn=users,cn=accounts,dc=rhel72" createtimestamp krbLastSuccessfulAuth and tried it adding in krbLastPwdChange, and using a service account as described here https://www.freeipa.org/page/HowTo/LDAP#System_Accounts but it did not return any krbLastSuccessfulAuth values. A bit of tinkering revealed that I have to use the Directory Manager to get back the krbLastSuccessfulAuth. Is it possible to tweak the service account to allow it to read krbLastSuccessfulAuth ? ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290

3 3

Applying Custom Object Classes to New Computer Entries
by Anabela Mazurek 10 Jul '20

10 Jul '20

How can i define default classes for newly created Computer objects?

2 3

Looking for current Python API information
by White, Daniel E. (GSFC-770.0)[NICS] 10 Jul '20

10 Jul '20

Most seems to be before Python 2's EOL including https://www.freeipa.org/page/API_Examples This one seems current: https://github.com/opennode/python-freeipa https://python-freeipa.readthedocs.io/en/latest/ Anyone recommend it or one better ? ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290

1 0

IMPORTANT: DigiCert is revoking some intermediate CAs July 11, 2020
by Rob Crittenden 10 Jul '20

10 Jul '20

In case anyone is using certificates from DigiCert they are revoking 14 intermediate CA's after an audit of DigitCert's intermediate CAs for extended validation certificates (EV) has revealed an inconsistency. This revocation is going to happen by Saturday July 11, 2020 at 18:00 UTC. See https://knowledge.digicert.com/alerts/DigiCert-ICA-Replacement for details. rob

1 0

Re: FreeIPA/PKI CA/KRA Subsystem Certificate Renewal Failure (not yet expired)
by Ilya Kogan 09 Jul '20

09 Jul '20

Hi, I seem to be facing a similar issue with one of my KRAs. My KRA certificates were, for some reason, not automatically renewed when they expired last month. Using `ipa-cert-fix` correctly fixed them on _one_ host. On the other, they seem to be stuck in the renewal state and `ipa-cert-fix` claims there's nothing to do: ``` Request ID '20191031183458': status: MONITORING ca-error: Server at " http://ipa-one.mydomain.org:8080/ca/ee/ca/profileSubmit" replied: Missing credential: sessionID stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-kra',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-kra',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MYDOMAIN.ORG subject: CN=KRA Audit,O=MYDOMAIN.ORG expires: 2020-06-27 01:54:34 EDT key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-kra" track: yes auto-renew: yes Request ID '20191031183459': status: MONITORING ca-error: Server at " http://ipa-one.mydomain.org:8080/ca/ee/ca/profileSubmit" replied: Missing credential: sessionID stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='transportCert cert-pki-kra',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='transportCert cert-pki-kra',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MYDOMAIN.ORG subject: CN=KRA Transport Certificate,O=MYDOMAIN.ORG expires: 2020-06-27 01:54:30 EDT key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "transportCert cert-pki-kra" track: yes auto-renew: yes Request ID '20191031183500': status: MONITORING ca-error: Server at " http://ipa-one.mydomain.org:8080/ca/ee/ca/profileSubmit" replied: Missing credential: sessionID stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert cert-pki-kra',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert cert-pki-kra',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MYDOMAIN.ORG subject: CN=KRA Storage Certificate,O=MYDOMAIN.ORG expires: 2020-06-27 01:54:32 EDT key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "storageCert cert-pki-kra" track: yes auto-renew: yes ``` Here are the sequence of events that seem to have led to this: 1. Install FreeIPA Master many years ago and continue to upgrade it from time to time. 2. Install FreeIPA Replica a few years after and continue to upgrade it from time to time. 3. Allow the certificates to expire on both nodes. 4. Attempt to patch the replica via `yum upgrade` on the second node. 5. Notice after reboot that `pki-tomcatd` is having trouble and discover certificate issues. 5. Issue `ipa-cert-fix`, reboot again, and notice that things are working. Try and create a key in the vault. 6. Attempt to patch the master via `yum upgrade` on the first node. 7. Notice after reboot that everything seems to be ok. Try and create a key in the vault. 8. Notice a few days later that renewal seems to be broken on the first node. At this point `ipa-cert-fix` just shows that everything is fine. If I run it with -v, and then check the "storageCert cert-pki-kra" certificate with `openssl x509 -text -in`, I'm shown: Validity Not Before: Jun 29 00:52:33 2020 GMT Not After : Jun 19 00:52:33 2022 GMT On the second known, `getcert list` shows correct expirations for those certificates: Request ID '20191206005909': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert cert-pki-kra',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert cert-pki-kra',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=MYDOMAIN.ORG subject: CN=KRA Storage Certificate,O=MYDOMAIN.ORG expires: 2022-06-18 20:52:33 EDT key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "storageCert cert-pki-kra" track: yes auto-renew: yes It seems like _something_, perhaps `ipa-cert-fix` somehow renewed these certificates but...outside of certmonger? Is this some other version of https://bugzilla.redhat.com/show_bug.cgi?id=1788907? The certificates are not in CA_WORKING though, they're in MONITORING. What can I do to get myself out of this state as it seems like I'm in a "this could explode at any moment" situation? This is on Fedora 30 with IP version: Last metadata expiration check: 0:23:05 ago on Sat 04 Jul 2020 07:59:16 PM EDT. Installed Packages Name : certmonger Version : 0.79.9 Release : 1.fc30 Architecture : x86_64 Size : 3.4 M Source : certmonger-0.79.9-1.fc30.src.rpm Repository : @System From repo : updates .. snip .. Name : freeipa-server Version : 4.8.3 Release : 1.fc30 Architecture : x86_64 Size : 1.3 M Source : freeipa-4.8.3-1.fc30.src.rpm Repository : @System From repo : updates .. snip .. Thanks! Ilya Kogan w: github.com/ikogan e: ikogan(a)mythicnet.org <http://twitter.com/ilkogan> <https://www.linkedin.com/in/ilyakogan/>

3 8

Password Policy Question
by White, Daniel E. (GSFC-770.0)[NICS] 09 Jul '20

09 Jul '20

Are there settings in FreeIPA similar to the setting available from the chage command ? I am specifically looking for a setting for the time after a password expires to allow the user to update it. I am looking for the same "grace period" that the non-IPA shell password has. From the change man page: -M, --maxdays MAX_DAYS Set the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change his/her password before being able to use his/her account. -I, --inactive INACTIVE Set the number of days of inactivity after a password has expired before the account is locked. The INACTIVE option is the number of days of inactivity. A user whose account is locked must contact the system administrator before being able to use the system again. I find nothing like this in the documentation. I do know, however, that when a user is initially created, the password expire time is set to the current clock time. When the user logs in for the first time, they are prompted to change their password. I am looking for a parameter -- like chage's INACTIVE -- that defines a grace period from the time the password expires until the account is locked and requires admin intervention. Or does that only happen for the account creation ? ______________________________________________________________________________________________ Daniel E. White daniel.e.white(a)nasa.gov<mailto:daniel.e.white@nasa.gov> NICS Linux Engineer NASA Goddard Space Flight Center 8800 Greenbelt Road Building 14, Room E175 Greenbelt, MD 20771 Office: (301) 286-6919 Mobile: (240) 513-5290

3 10

Can't Add Replica: The changelog directory CLDB already exists and is not empty
by Andrey Ptashnik 09 Jul '20

09 Jul '20

Team, I'm trying to install FreeIPA replica and constantly hitting this error below. OS where replica is being installed is a fresh install. IPA version 4.6.6 After this error Master does not have any record of replica anyway. Can someone please shed some light why on the machine with fresh OS install I can see error such "directory [/var/lib/dirsrv/slapd-EXAMPLE-COM/cldb] already exists and is not empty" Command that I'm using from a client machine that is already in the domain: [root@server-02] # kinit admin [root@server-02] # ipa-replica-install --server server-01.example.com --domain example.com --setup-dns --setup-ca --forwarder 10.1xx.1xx.10 ---8<------8<------8<------8<------8<------8<------8<------8<--- [28/42]: ignore time skew for initial replication [29/42]: setting up initial replication [error] DatabaseError: Operations error: The changelog directory [/var/lib/dirsrv/slapd-EXAMPLE-COM/cldb] already exists and is not empty. Please choose a directory that does not exist or is empty. Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ---8<------8<------8<------8<------8<------8<------8<------8<--- Regards, Andrey

2 3

Options to deploy FreeIPA without domain delegation
by john doe 08 Jul '20

08 Jul '20

Are there any options to deploy it within an existing domain with the constraints being: - no domain delegation - write access to the applicable zone file prohibited - registering/using an external domain impossible; also no external nameserver access - FreeIPA allowing for no single label domain; hack to override not sensible if multi-forest windows connection where to be necessary in the future - apparently no alternative to DNS as for Kerberos config files?

2 1

Logging of ipa migrate-ds
by Alfred Victor 08 Jul '20

08 Jul '20

Hi FreeIPA, We are testing an IPA deployment and regularly using expect to perform ipa migrate-ds commands to keep the IPA environment refreshed. However, I cannot seem to get any log trail of the migrates...it is proving difficult in expect to capture/log the output, and there appears to be no logfile location option for migrate-ds. What would be the best way to capture the output of the commands? Alfred

2 1

idm ad integration question
by Rob Verduijn 08 Jul '20

08 Jul '20

Hello, I've been working with idm ad integration for some time now. But one thing has always confused me. In all the docs it will tell you to check the dns to see if the dns records resolve. dig +short -t SRV _kerberos._udp.idm.example.com. dig +short -t SRV _ldap._tcp.idm.example.com. dig +short -t TXT _kerberos.idm.example.com. dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com. dig +short -t SRV _kerberos._udp.dc._msdcs.ad.example.com. The last one will always fail because by default ms-ad does not generate such a record. However there is always a tcp record. dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com. Can freeipa work with the tcp record as well, or is it vital that you create a udp record for freeipa to work properly? Rob Verduijn

1 0

Adding new replica with CA fails.
by Guillermo Fuentes 07 Jul '20

07 Jul '20

Hi all, I'm having an issue creating a new replica with CA. The Directory Service installation works fine but adding the CA clone fails with a java.lang.NumberFormatException when getting the serial number range. This is the error logged in /var/log/pki/pki-tomcat/ca/debug: ###### ... [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: retrieving ou=ca, ou=requests,o=ipaca [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: updating nextRange from 80000001 to 90000001 [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: adding new range object: cn=80000001,ou=requests, ou=ranges,o=ipaca [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: getNextRange Next range has been added: 80000001 - 90000000 [20/Jun/2020:15:09:55][localhost-startStop-1]: Releasing ldap connection [20/Jun/2020:15:09:55][localhost-startStop-1]: returnConn: mNumConns now 3 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: next range: 80000001 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Next min serial number: 80000001 [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: Setting next min requests number: 80000001 [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: Setting next max requests number: 90000000 [20/Jun/2020:15:09:55][localhost-startStop-1]: Checking for a range conflict [20/Jun/2020:15:09:55][localhost-startStop-1]: In LdapBoundConnFactory::getConn() [20/Jun/2020:15:09:55][localhost-startStop-1]: masterConn is connected: true [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: conn is connected true [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: mNumConns now 2 [20/Jun/2020:15:09:55][localhost-startStop-1]: Releasing ldap connection [20/Jun/2020:15:09:55][localhost-startStop-1]: returnConn: mNumConns now 3 [20/Jun/2020:15:09:55][localhost-startStop-1]: CMSEngine: checking certificate serial number ranges [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Serial numbers left in range: 65536 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Last serial number: 2415656960 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Serial numbers available: 65536 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Low water mark: 33554432 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Requesting next range [20/Jun/2020:15:09:55][localhost-startStop-1]: In LdapBoundConnFactory::getConn() [20/Jun/2020:15:09:55][localhost-startStop-1]: masterConn is connected: true [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: conn is connected true [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: mNumConns now 2 [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: retrieving ou=certificateRepository, ou=ca,o=ipaca java.lang.NumberFormatException: For input string: "e0000001" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:580) at java.math.BigInteger.<init>(BigInteger.java:470) at java.math.BigInteger.<init>(BigInteger.java:606) at com.netscape.cmscore.dbs.DBSubsystem.getNextRange(DBSubsystem.java:417) at com.netscape.cmscore.dbs.Repository.checkRanges(Repository.java:546) at com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1268) at com.netscape.certsrv.apps.CMS.startup(CMS.java:204) at com.netscape.certsrv.apps.CMS.start(CMS.java:1459) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:117) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) ... ###### This is logged in /var/log/pki/pki-ca-spawn.20200620150752.log: ###### ... 2020-06-20 15:09:47 pkispawn : INFO ....... executing 'systemctl stop pki-tomcatd(a)pki-tomcat.service' 2020-06-20 15:09:48 pkispawn : INFO ....... removing temp SSL server cert from internal token: Server-Cert cert-pki-ca 2020-06-20 15:09:48 pki.nssdb : DEBUG Command: certutil -D -d /var/lib/pki/pki-tomcat/alias -f /tmp/tmptjRzW6/password.txt -n Server-Cert cert-pki-ca 2020-06-20 15:09:48 pkispawn : INFO ....... importing permanent SSL server cert into internal token: Server-Cert cert-pki-ca 2020-06-20 15:09:48 pki.nssdb : DEBUG Command: certutil -A -d /var/lib/pki/pki-tomcat/alias -f /tmp/tmplJLOg8/internal_password.txt -n Server-Cert cert-pki-ca -a -i /tmp/tmpeCzA_b/sslserver.crt -t ,, 2020-06-20 15:09:48 pkispawn : INFO ....... executing 'systemctl daemon-reload' 2020-06-20 15:09:48 pkispawn : INFO ....... executing 'systemctl start pki-tomcatd(a)pki-tomcat.service' 2020-06-20 15:09:48 pkispawn : INFO ........... FIPS mode is NOT enabled on this operating system. 2020-06-20 15:09:48 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:09:48 pkispawn : DEBUG ........... No connection - exception thrown: ('Connection aborted.', error(111, 'Connection refused')) 2020-06-20 15:09:49 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:09:49 pkispawn : DEBUG ........... No connection - exception thrown: ('Connection aborted.', error(111, 'Connection refused')) 2020-06-20 15:09:56 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:09:56 pkispawn : DEBUG ........... No connection - exception thrown: 500 Server Error: Internal Server Error 2020-06-20 15:09:57 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:09:57 pkispawn : DEBUG ........... No connection - exception thrown: 500 Server Error: Internal Server Error 2020-06-20 15:09:58 pkispawn : DEBUG ........... No connection - server may still be down ... repeats every second 2020-06-20 15:10:47 pkispawn : DEBUG ........... No connection - exception thrown: 500 Server Error: Internal Server Error 2020-06-20 15:10:48 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:10:48 pkispawn : DEBUG ........... No connection - exception thrown: 500 Server Error: Internal Server Error 2020-06-20 15:10:49 pkispawn : ERROR ... server failed to restart 2020-06-20 15:10:49 pkispawn : DEBUG ....... Error Type: RuntimeError 2020-06-20 15:10:49 pkispawn : DEBUG ....... Error Message: server failed to restart 2020-06-20 15:10:49 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 534, in main scriptlet.spawn(deployer) File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 1304, in spawn raise RuntimeError("server failed to restart") ###### And here is the failure in /var/log/ipareplica-ca-install.log: ###### ... --------------- Import complete --------------- Imported certificates into /etc/pki/pki-tomcat/alias: Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Third-party RSA CA C,, caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Third-party Root CA C,, ocspSigningCert cert-pki-ca u,u,u Installation failed: server failed to restart 2020-06-20T15:10:50Z DEBUG stderr=pkispawn : ERROR ... server failed to restart 2020-06-20T15:10:50Z CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpcQ1jxM' returned non-zero exit status 1 2020-06-20T15:10:50Z CRITICAL See the installation logs and the following files/directories for more information: 2020-06-20T15:10:50Z CRITICAL /var/log/pki/pki-tomcat 2020-06-20T15:10:50Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 567, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 557, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 675, in __spawn_instance pki_pin) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 167, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 408, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) RuntimeError: CA configuration failed. 2020-06-20T15:10:50Z DEBUG [error] RuntimeError: CA configuration failed. ... ###### Has anyone run into this? Is this a known bug/issue? Current environment of all replicas: - CentOS 7.8 - FreeIPA 4.6.6 Any help/guidance on fixing this would be really appreciated. Thanks so much, Guillermo

4 6

Plans for integrating DHCP
by Ronald Wimmer 07 Jul '20

07 Jul '20

Hi there, are there any plans to integrate a DHCP server into FreeIPA. We have several environments where a lack of DHCP is a showstopper at the moment. Cheers, Ronald

10 9

Adding Windows 10 client to freeIPA - Error : Failed to parse result: All enctypes provided are unsupported
by lovepreetdeol 07 Jul '20

07 Jul '20

Hi, Running freeIPA server on centos 8.2. Trying to setup mixed OS environment with linux and windows clients. Another centos8.2 machine connects to freeIPA without any problem. I am trying to connect a windows 10 client to the freeIPA and getting the following error : [root@directory ~]# [root@directory ~]# ipa-getkeytab -s directory.compnet.local -p host/win10.compnet.local -e arcfour-hmac -k krb5.keytab.win10 -P New Principal Password: Verify Principal Password: Failed to parse result: All enctypes provided are unsupported Retrying with pre-4.0 keytab retrieval method... Failed to parse result: All enctypes provided are unsupported Failed to get keytab! Failed to get keytab [root@directory ~]# References followed : https://www.rootusers.com/how-to-login-to-windows-with-a-freeipa-account/ https://www.freeipa.org/page/Windows_authentication_against_FreeIPA https://www.server-world.info/en/note?os=CentOS_7&p=ipa&f=8

3 2

Kerberos realm trusting ipa realm
by Gerald Vogt 07 Jul '20

07 Jul '20

Hi! I am trying to get a kerberos realm to trust the ipa realm. I'm running ipa-server-4.6.6-11.el7 on a CentOS 7. It uses realm IPA.EXAMPLE.COM. I have another KDC on another CentOS 7 which has another realm KRB.EXAMPLE.COM with a legacy service connected. Now I would like all users of my IPA realm to use that legacy service. Thus I need the KRB realm to trust the IPA realm. I don't need the IPA realm to trust the KRB realm. For the KRB KDC I have no problem adding the necessary krbtgt/KRB.EXAMPLE.COM(a)IPA.EXAMPLE.COM principal with a password. However, everything I find about adding it to the IPA Kerberos involves kadmin.local which seems not to be supported anymore: kadmin.local: Cannot open DB2 database '/var/kerberos/krb5kdc/principal': No such file or directory while initializing kadmin.local interface How do I add this principal correctly to my IPA kerberos? Is it possible? Thx.

2 3

Providing service level access without granting sudo access
by Saurabh Garg 07 Jul '20

07 Jul '20

Hi All, We have a requirement where we need to give a user access to stop and start a service like tomcat8 without giving sudo access on that machine. I tried adding tomcat8 service (running on an ubuntu host) on the Idm server using "ipa service-add" command. Later, when I tried creating a hbac policy to provide access to a user on that service, it doesn't show up. Is there any other way of providing service level access to a user on Redhat IdM? Please advice. Thanks, Saurabh Garg

2 1

idm user access write issue
by Kannappan M 06 Jul '20

06 Jul '20

Hi All, i have granted a bunch of users to a list of servers but except one server all the user are able to touch the files once they login to 3out of 4 servers , in one server alone am able to switch to user but not able to touch any files getting message as permission denied Regards Kanna

2 3

Re: Last FreeIPA master is failing
by Ricardo Mendes 06 Jul '20

06 Jul '20

Hi all, Came around to post the definite fix for my problem, don't know if it will help anyone since it was all a mess. As mentioned previously: > There's the expected "slapd-DOMAIN-IO" but I also have a "try_ca_renew-slapd-DOMAIN-IO" dir dated from 8 of June that resembles a copy of "slapd-DOMAIN-IO" so I was wondering if between one and other maybe copying some files would work? So I did this, then the error that I got on pki-tomcat/ca/debug was the old message of peer certificate expired. So since I had already reverted to self signed certificates I issued ipa-cert-fix command, failed. [root@main ~]# ipa-cert-fix Failed to get Server-Cert The ipa-cert-fix command failed. Then I tried the 'ipa-cacert-manage renew' command which completed successfully. [root@main ~]# ipa-cacert-manage renew Renewing CA certificate, please wait CA certificate successfully renewed The ipa-cacert-manage command was successful And then all ipa services were able to start correctly (finally able to leave out both the --skip-version-check and --ignore-service-failure): [root@main ~]# ipactl restart IPA version error: data needs to be upgraded (expected version '4.6.6-11.el7.centos', current version '4.6.5-11.el7.centos.4') Automatically running upgrade, for details see /var/log/ipaupgrade.log Be patient, this may take a few minutes. Restarting Directory Service Restarting krb5kdc Service Restarting kadmin Service Restarting named Service Restarting httpd Service Restarting ipa-custodia Service Restarting ntpd Service Restarting pki-tomcatd Service Restarting ipa-otpd Service Restarting ipa-ods-exporter Service Restarting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful

1 0

write permission to all users in idm server
by Kannappan M 06 Jul '20

06 Jul '20

Hi All i have problem with Write permission of all the users in a particular server alone server list 10.1.2.3 10.1.2.4 10.1.2.5 10.1.2.6 users list sam kim alias moore In the above users and servers list all the users are able to access all the 2.3,2.4 and 2.5 but non of the users are able to touch any files or folders in 10.1.2.6 but after login to 10.1.2.6 when i give the id sam or id kim or id alias or id moore all the ids are reflecting but non of the users not able to touch the files or folders please guide me to fix the issue. Regards Kanna

1 0

RADIUS proxy in FreeIPA
by Max Muller 04 Jul '20

04 Jul '20

Hi all! I keep trying to tune my FreeIPA server with FreeRADIUS. I deployed the FreeRADIUS for control authentication on VPN-server and I want use FreeIPA as RADIUS proxy (I want control from FreeIPA which users can use VPN). FreeRADIUS and FreeIPA run on one server. I add RADIUS-proxy in FreeIPA, but my RADIUS-server do not get requests from remote client. But test-util "radtest" from this server work fine. What am I doing wrong? Thanks for reply. [root@ipa ~]# ipa radiusproxy-find ----------------------------- 1 RADIUS proxy server matched ----------------------------- RADIUS proxy server name: radius Server: localhost.localdomain ---------------------------- Number of entries returned 1 ----------------------------

2 3

Is it normal to ID overrides not show on IPA Replica with its names?
by Vinícius Ferrão 03 Jul '20

03 Jul '20

Hello, I have two FreeIPA servers with AD trust enabled. Usually I do everything on the IPA #1 server, but I just observed that SIDs aren’t resolved on the replica, is it normal? I’m attaching a picture of the issue to illustrate it. [cid:E1C493F7-5F5F-437D-BF6F-4A33BDAB61FC] If this is not right, someone can help with debugging steps? I observed that I can’t do getent passwd ferrao on the replica either. Only on master: [root@ipa1 ~]# getent passwd ferrao ferrao(a)ad.example.com<mailto:ferrao@ad.example.com>:*:1499401105:1499401105:Vinícius Ferrão:/home/ferrao: [root@ipa2 ~]# getent passwd ferrao Thanks,

2 9

Adding new replica with CA fails.
by Guillermo Fuentes 02 Jul '20

02 Jul '20

Hi all, I'm having an issue creating a new replica with CA. The Directory Service installation works fine but adding the CA clone fails with a java.lang.NumberFormatException when getting the serial number range. This is the error logged in /var/log/pki/pki-tomcat/ca/debug: ###### ... [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: retrieving ou=ca, ou=requests,o=ipaca [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: updating nextRange from 80000001 to 90000001 [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: adding new range object: cn=80000001,ou=requests, ou=ranges,o=ipaca [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: getNextRange Next range has been added: 80000001 - 90000000 [20/Jun/2020:15:09:55][localhost-startStop-1]: Releasing ldap connection [20/Jun/2020:15:09:55][localhost-startStop-1]: returnConn: mNumConns now 3 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: next range: 80000001 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Next min serial number: 80000001 [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: Setting next min requests number: 80000001 [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: Setting next max requests number: 90000000 [20/Jun/2020:15:09:55][localhost-startStop-1]: Checking for a range conflict [20/Jun/2020:15:09:55][localhost-startStop-1]: In LdapBoundConnFactory::getConn() [20/Jun/2020:15:09:55][localhost-startStop-1]: masterConn is connected: true [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: conn is connected true [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: mNumConns now 2 [20/Jun/2020:15:09:55][localhost-startStop-1]: Releasing ldap connection [20/Jun/2020:15:09:55][localhost-startStop-1]: returnConn: mNumConns now 3 [20/Jun/2020:15:09:55][localhost-startStop-1]: CMSEngine: checking certificate serial number ranges [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Serial numbers left in range: 65536 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Last serial number: 2415656960 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Serial numbers available: 65536 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Low water mark: 33554432 [20/Jun/2020:15:09:55][localhost-startStop-1]: Repository: Requesting next range [20/Jun/2020:15:09:55][localhost-startStop-1]: In LdapBoundConnFactory::getConn() [20/Jun/2020:15:09:55][localhost-startStop-1]: masterConn is connected: true [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: conn is connected true [20/Jun/2020:15:09:55][localhost-startStop-1]: getConn: mNumConns now 2 [20/Jun/2020:15:09:55][localhost-startStop-1]: DBSubsystem: retrieving ou=certificateRepository, ou=ca,o=ipaca java.lang.NumberFormatException: For input string: "e0000001" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:580) at java.math.BigInteger.<init>(BigInteger.java:470) at java.math.BigInteger.<init>(BigInteger.java:606) at com.netscape.cmscore.dbs.DBSubsystem.getNextRange(DBSubsystem.java:417) at com.netscape.cmscore.dbs.Repository.checkRanges(Repository.java:546) at com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1268) at com.netscape.certsrv.apps.CMS.startup(CMS.java:204) at com.netscape.certsrv.apps.CMS.start(CMS.java:1459) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:117) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320) ... ###### This is logged in /var/log/pki/pki-ca-spawn.20200620150752.log: ###### ... 2020-06-20 15:09:47 pkispawn : INFO ....... executing 'systemctl stop pki-tomcatd(a)pki-tomcat.service' 2020-06-20 15:09:48 pkispawn : INFO ....... removing temp SSL server cert from internal token: Server-Cert cert-pki-ca 2020-06-20 15:09:48 pki.nssdb : DEBUG Command: certutil -D -d /var/lib/pki/pki-tomcat/alias -f /tmp/tmptjRzW6/password.txt -n Server-Cert cert-pki-ca 2020-06-20 15:09:48 pkispawn : INFO ....... importing permanent SSL server cert into internal token: Server-Cert cert-pki-ca 2020-06-20 15:09:48 pki.nssdb : DEBUG Command: certutil -A -d /var/lib/pki/pki-tomcat/alias -f /tmp/tmplJLOg8/internal_password.txt -n Server-Cert cert-pki-ca -a -i /tmp/tmpeCzA_b/sslserver.crt -t ,, 2020-06-20 15:09:48 pkispawn : INFO ....... executing 'systemctl daemon-reload' 2020-06-20 15:09:48 pkispawn : INFO ....... executing 'systemctl start pki-tomcatd(a)pki-tomcat.service' 2020-06-20 15:09:48 pkispawn : INFO ........... FIPS mode is NOT enabled on this operating system. 2020-06-20 15:09:48 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:09:48 pkispawn : DEBUG ........... No connection - exception thrown: ('Connection aborted.', error(111, 'Connection refused')) 2020-06-20 15:09:49 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:09:49 pkispawn : DEBUG ........... No connection - exception thrown: ('Connection aborted.', error(111, 'Connection refused')) 2020-06-20 15:09:56 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:09:56 pkispawn : DEBUG ........... No connection - exception thrown: 500 Server Error: Internal Server Error 2020-06-20 15:09:57 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:09:57 pkispawn : DEBUG ........... No connection - exception thrown: 500 Server Error: Internal Server Error 2020-06-20 15:09:58 pkispawn : DEBUG ........... No connection - server may still be down ... repeats every second 2020-06-20 15:10:47 pkispawn : DEBUG ........... No connection - exception thrown: 500 Server Error: Internal Server Error 2020-06-20 15:10:48 pkispawn : DEBUG ........... No connection - server may still be down 2020-06-20 15:10:48 pkispawn : DEBUG ........... No connection - exception thrown: 500 Server Error: Internal Server Error 2020-06-20 15:10:49 pkispawn : ERROR ... server failed to restart 2020-06-20 15:10:49 pkispawn : DEBUG ....... Error Type: RuntimeError 2020-06-20 15:10:49 pkispawn : DEBUG ....... Error Message: server failed to restart 2020-06-20 15:10:49 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 534, in main scriptlet.spawn(deployer) File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 1304, in spawn raise RuntimeError("server failed to restart") ###### And here is the failure in /var/log/ipareplica-ca-install.log: ###### ... --------------- Import complete --------------- Imported certificates into /etc/pki/pki-tomcat/alias: Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Third-party RSA CA C,, caSigningCert cert-pki-ca CTu,Cu,Cu subsystemCert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Third-party Root CA C,, ocspSigningCert cert-pki-ca u,u,u Installation failed: server failed to restart 2020-06-20T15:10:50Z DEBUG stderr=pkispawn : ERROR ... server failed to restart 2020-06-20T15:10:50Z CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpcQ1jxM' returned non-zero exit status 1 2020-06-20T15:10:50Z CRITICAL See the installation logs and the following files/directories for more information: 2020-06-20T15:10:50Z CRITICAL /var/log/pki/pki-tomcat 2020-06-20T15:10:50Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 567, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 557, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 675, in __spawn_instance pki_pin) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 167, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 408, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) RuntimeError: CA configuration failed. 2020-06-20T15:10:50Z DEBUG [error] RuntimeError: CA configuration failed. ... ###### Has anyone run into this? Is this a known bug/issue? Current environment of all replicas: - CentOS 7.8 - FreeIPA 4.6.6 Any help/guidance on fixing this would be really appreciated. Thanks so much, Guillermo -- *CONFIDENTIALITY NOTICE:* This e-mail message may contain material protected by the Health Insurance Portability and Accountability Act of 1996 and its implementing regulations and other state and federal laws and legal privileges. This message is only for the personal and confidential use of the individuals or organization to whom the message is addressed. If you are an unintended recipient, you have received this message in error, and any reading, distributing, copying or disclosure is unauthorized and strictly prohibited. All recipients are hereby notified that any unauthorized receipt does not waive any confidentiality obligations or privileges. If you have received this message in error, please notify the sender immediately at the above email address and confirm that you have deleted or destroyed the message.

1 0

User based access control to services?
by Dominik Vogt 02 Jul '20

02 Jul '20

In our setup, a service is running on some server machine, say, "sample/servername.domain" and a client for that service is running on a workstation (using the sample gssapi client and server code from the kerberos sources). Now, what is the proper way to do this in freeipa? 1. Allow users foo and bar to log in to the workstation but to no other machine of the kerberos real. 2. Deny access to sample/servername.domain from any host except from the workstation. 3. Allow user foo access the service. 4. Deny user bar access the service. 5. Deny both users access to anything else on the server. I don't quite understand how that fits into chapter 10/19 or 31 of the "Linux Domain Identity, Authentication, and Policy Guide" for RHEL 7". Chapter 10 deals with access to freeipa internal objects, and chapter 31 describes host based access control. But how is access control done for someuser@clientmachine -> service@servermachine? Ciao Dominik ^_^ ^_^ -- Dominik Vogt

2 2

Re: ipa-server-upgrade failed after yum update on CentOS7
by Florence Blanc-Renaud 01 Jul '20

01 Jul '20

Hi, as you have installed 4.6.5-11, the command ipa-cert-fix is available and should ease fixing the expired certs. The topology looks simple enough (a single master), so no need to worry about which server to fix first. More info available in [1] and in ipa-cert-fix man page. HTH, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… On 7/1/20 6:01 AM, Mariusz Stolarczyk via FreeIPA-users wrote: > The kinit command wouldn't work so it prevented the other commands. One > of my issues is that the IPA server tries to update itself: > > # ipactl start > IPA version error: data needs to be upgraded (expected version > '4.6.6-11.el7.centos', current version '4.6.5-11.el7.centos.4') > Automatically running upgrade, for details see /var/log/ipaupgrade.log > > > This seemed to get me past that: > > # ipactl start --skip-version-check --ignore-service-failure > Skipping version check > Existing service file detected! > Assuming stale, cleaning and proceeding > Starting Directory Service > Starting krb5kdc Service > Starting kadmin Service > Starting named Service > Starting httpd Service > Failed to start httpd Service > Forced start, ignoring httpd Service, continuing normal operation > Starting ipa-custodia Service > Starting ntpd Service > Starting pki-tomcatd Service > Failed to start pki-tomcatd Service > Forced start, ignoring pki-tomcatd Service, continuing normal operation > Starting smb Service > Starting winbind Service > Starting ipa-otpd Service > Starting ipa-dnskeysyncd Service > ipa: INFO: The ipactl command was successful > > > However I found some instructions to rollback the system clock to get > certmonger to renewal the expired certs. Now the httpd.service starts > but not the pki-tomcatd. > > > # ipactl start --skip-version-check --ignore-service-failure > Skipping version check > Existing service file detected! > Assuming stale, cleaning and proceeding > Starting Directory Service > Starting krb5kdc Service > Starting kadmin Service > Starting named Service > Starting httpd Service > Starting ipa-custodia Service > Starting ntpd Service > Starting pki-tomcatd Service > Failed to start pki-tomcatd Service > Forced start, ignoring pki-tomcatd Service, continuing normal operation > Starting smb Service > Starting winbind Service > Starting ipa-otpd Service > Starting ipa-dnskeysyncd Service > ipa: INFO: The ipactl command was successful > > > Now I was able to get the outputs: > > # ipa config-show | grep "CA renewal" > IPA CA renewal master: FAKE-HOST.FAKE-IPA-DOMAIN.lan > > > # ipa server-role-find > ---------------------- > 6 server roles matched > ---------------------- > Server name: FAKE-HOST.FAKE-IPA-DOMAIN.lan > Role name: CA server > Role status: enabled > > Server name: FAKE-HOST.FAKE-IPA-DOMAIN.lan > Role name: DNS server > Role status: enabled > > Server name: FAKE-HOST.FAKE-IPA-DOMAIN.lan > Role name: NTP server > Role status: enabled > > Server name: FAKE-HOST.FAKE-IPA-DOMAIN.lan > Role name: AD trust agent > Role status: enabled > > Server name: FAKE-HOST.FAKE-IPA-DOMAIN.lan > Role name: KRA server > Role status: absent > > Server name: FAKE-HOST.FAKE-IPA-DOMAIN.lan > Role name: AD trust controller > Role status: enabled > ---------------------------- > Number of entries returned 6 > ---------------------------- > > > # getcert list > Number of certificates and requests being tracked: 9. > Request ID '20171108154417': > status: MONITORING > stuck: no > key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' > certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' > CA: SelfSign > issuer: CN=FAKE-HOST.FAKE-IPA-DOMAIN.lan,O=FAKE-IPA-DOMAIN.LAN > subject: CN=FAKE-HOST.FAKE-IPA-DOMAIN.lan,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-09-13 20:50:34 UTC > principal name: krbtgt/FAKE-IPA-DOMAIN.LAN(a)FAKE-IPA-DOMAIN.LAN > certificate template/profile: KDCs_PKINIT_Certs > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert > track: yes > auto-renew: yes > Request ID '20181122014941': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=CA Audit,O=FAKE-IPA-DOMAIN.LAN > expires: 2022-05-18 03:13:17 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20181122014942': > 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=FAKE-IPA-DOMAIN.LAN > subject: CN=OCSP Subsystem,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-06-24 23:56:43 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 '20181122014943': > 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=FAKE-IPA-DOMAIN.LAN > subject: CN=CA Subsystem,O=FAKE-IPA-DOMAIN.LAN > expires: 2022-05-18 03:11:57 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 '20181122014944': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > expires: 2036-08-12 21:35:52 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "caSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20181122014945': > status: CA_UNREACHABLE > ca-error: Error 60 connecting to > https://FAKE-HOST.FAKE-IPA-DOMAIN.lan:8443/ca/agent/ca/profileReview: > Peer certificate cannot be authenticated with given CA certificates. > 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=FAKE-IPA-DOMAIN.LAN > subject: CN=IPA RA,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-06-24 23:56:33 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 > Request ID '20181122014946': > status: CA_UNREACHABLE > ca-error: Error 60 connecting to > https://FAKE-HOST.FAKE-IPA-DOMAIN.lan:8443/ca/agent/ca/profileReview: > Peer certificate cannot be authenticated with given CA certificates. > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=FAKE-HOST.FAKE-IPA-DOMAIN.lan,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-06-24 23:55:43 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 > "Server-Cert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20181122014947': > status: CA_UNREACHABLE > ca-error: Server at https://FAKE-HOST.FAKE-IPA-DOMAIN.lan/ipa/xml failed > request, will retry: -504 (libcurl failed to execute the HTTP POST > transaction, explaining: Failed connect to > FAKE-HOST.FAKE-IPA-DOMAIN.lan:443; Connection refused). > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=FAKE-HOST.FAKE-IPA-DOMAIN.lan,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-07-17 16:47:45 UTC > principal name: ldap/FAKE-HOST.FAKE-IPA-DOMAIN.lan(a)FAKE-IPA-DOMAIN.LAN > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv > FAKE-IPA-DOMAIN-LAN > track: yes > auto-renew: yes > Request ID '20181122014948': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=FAKE-HOST.FAKE-IPA-DOMAIN.lan,O=FAKE-IPA-DOMAIN.LAN > expires: 2022-03-16 22:14:54 UTC > dns: FAKE-HOST.FAKE-IPA-DOMAIN.lan > principal name: HTTP/FAKE-HOST.FAKE-IPA-DOMAIN.lan(a)FAKE-IPA-DOMAIN.LAN > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > > I am also able to restart pki-tomcatd service after two restart attempts: > > > # systemctl restart pki-tomcatd(a)pki-tomcat.service > # ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > httpd Service: RUNNING > ipa-custodia Service: RUNNING > ntpd Service: RUNNING > pki-tomcatd Service: STOPPED > smb Service: RUNNING > winbind Service: RUNNING > ipa-otpd Service: RUNNING > ipa-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > # systemctl restart pki-tomcatd(a)pki-tomcat.service > # ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > httpd Service: RUNNING > ipa-custodia Service: RUNNING > ntpd Service: RUNNING > pki-tomcatd Service: RUNNING > smb Service: RUNNING > winbind Service: RUNNING > ipa-otpd Service: RUNNING > ipa-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > # systemctl status pki-tomcatd(a)pki-tomcat.service > ● pki-tomcatd(a)pki-tomcat.service - PKI Tomcat Server pki-tomcat > Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; > vendor preset: disabled) > Active: active (running) since Tue 2020-06-30 20:55:41 PDT; 20s ago > Process: 9567 ExecStop=/usr/libexec/tomcat/server stop (code=exited, > status=0/SUCCESS) > Process: 9612 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited, > status=0/SUCCESS) > Main PID: 9749 (java) > CGroup: > /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd(a)pki-tomcat.service > └─9749 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java > -DRESTEASY_LIB=/usr/share/java/resteasy-base > -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath > /usr/share/tomcat/bin/bo... > > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: Jun 30, > 2020 8:55:56 PM org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: SEVERE: > The web application [/ca] appears to have started a thread named > [LDAPConnThread-0 ldaps://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan:636] > ...emory leak. > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: Jun 30, > 2020 8:55:56 PM org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: SEVERE: > The web application [/ca] appears to have started a thread named > [LDAPConnThread-2 ldaps://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan:636] > ...emory leak. > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: Jun 30, > 2020 8:55:56 PM org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: SEVERE: > The web application [/ca] appears to have started a thread named > [authorityMonitor] but has failed to stop it. Thi...emory leak. > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: Jun 30, > 2020 8:55:56 PM org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: SEVERE: > The web application [/ca] appears to have started a thread named > [LDAPConnThread-3 ldaps://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan:636] > ...emory leak. > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: Jun 30, > 2020 8:55:56 PM org.apache.catalina.loader.WebappClassLoaderBase > clearReferencesThreads > Jun 30 20:55:56 FAKE-IPA-HOST.FAKE-IPA-DOMAIN.lan server[9749]: SEVERE: > The web application [/ca] appears to have started a thread named > [profileChangeMonitor] but has failed to stop it....emory leak. > Hint: Some lines were ellipsized, use -l to show in full. > > > Not sure what to do next. > > Thanks, > -ms > > ------------------------------------------------------------------------ > *From:* Rob Crittenden <rcritten(a)redhat.com> > *Sent:* Tuesday, June 30, 2020 8:20 PM > *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>; > Florence Blanc-Renaud <flo(a)redhat.com> > *Cc:* Mariusz Stolarczyk <zeusuofm(a)hotmail.com> > *Subject:* Re: [Freeipa-users] Re: ipa-server-upgrade failed after yum > update on CentOS7 > Mariusz Stolarczyk via FreeIPA-users wrote: >> Thanks for the response. >> >> This is my main IPA server the rest of my small network are just linux >> clients. >> >> >> kinit: Cannot contact any KDC for realm 'FAKE-IPA-DOMAIN.LAN' while >> getting initial credentials > > The other information that Flo requested is needed as well. > > Three of your certificates expired on June 24 and to create a plan to > fix it we need the other info. > > rob > >> >> >> # getcert list >> Number of certificates and requests being tracked: 9. >> Request ID '20171108154417': >> status: MONITORING >> stuck: no >> key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' >> certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' >> CA: SelfSign >> issuer: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN >> subject: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN >> expires: 2020-09-13 20:50:34 UTC >> principal name: krbtgt/FAKE-IPA-DOMAIN.LAN(a)FAKE-IPA-DOMAIN.LAN >> certificate template/profile: KDCs_PKINIT_Certs >> pre-save command: >> post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert >> track: yes >> auto-renew: yes >> Request ID '20181122014941': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN >> subject: CN=CA Audit,O=FAKE-IPA-DOMAIN.LAN >> expires: 2022-05-18 03:13:17 UTC >> key usage: digitalSignature,nonRepudiation >> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad >> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert >> "auditSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20181122014942': >> status: CA_UNREACHABLE >> ca-error: Internal error >> 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=FAKE-IPA-DOMAIN.LAN >> subject: CN=OCSP Subsystem,O=FAKE-IPA-DOMAIN.LAN >> expires: 2020-06-24 23:56:43 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 '20181122014943': >> 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=FAKE-IPA-DOMAIN.LAN >> subject: CN=CA Subsystem,O=FAKE-IPA-DOMAIN.LAN >> expires: 2022-05-18 03:11:57 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 '20181122014944': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN >> subject: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN >> expires: 2036-08-12 21:35:52 UTC >> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign >> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad >> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert >> "caSigningCert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20181122014945': >> status: CA_UNREACHABLE >> ca-error: Internal error >> 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=FAKE-IPA-DOMAIN.LAN >> subject: CN=IPA RA,O=FAKE-IPA-DOMAIN.LAN >> expires: 2020-06-24 23:56:33 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 >> Request ID '20181122014946': >> status: CA_UNREACHABLE >> ca-error: Internal error >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB',pin set >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB' >> CA: dogtag-ipa-ca-renew-agent >> issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN >> subject: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN >> expires: 2020-06-24 23:55:43 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 >> "Server-Cert cert-pki-ca" >> track: yes >> auto-renew: yes >> Request ID '20181122014947': >> status: CA_UNREACHABLE >> ca-error: Error setting up ccache for "host" service on client using >> default keytab: Cannot contact any KDC for realm 'FAKE-IPA-DOMAIN.LAN'. >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN',nickname='Server-Cert',token='NSS >> Certificate DB',pinfile='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN',nickname='Server-Cert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN >> subject: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN >> expires: 2020-07-17 16:47:45 UTC >> principal name: ldap/sol.FAKE-IPA-DOMAIN.LAN(a)FAKE-IPA-DOMAIN.LAN >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv >> FAKE-IPA-DOMAIN-LAN >> track: yes >> auto-renew: yes >> Request ID '20181122014948': >> status: MONITORING >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN >> subject: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN >> expires: 2022-03-16 22:14:54 UTC >> dns: sol.FAKE-IPA-DOMAIN.LAN >> principal name: HTTP/sol.FAKE-IPA-DOMAIN.LAN(a)FAKE-IPA-DOMAIN.LAN >> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: /usr/libexec/ipa/certmonger/restart_httpd >> track: yes >> auto-renew: yes >> >> >> What can I do next? >> >> Thanks, >> -ms >> >> >> >> ------------------------------------------------------------------------ >> *From:* Florence Blanc-Renaud <flo(a)redhat.com> >> *Sent:* Tuesday, June 30, 2020 1:45 AM >> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >> *Cc:* Mariusz Stolarczyk <zeusuofm(a)hotmail.com> >> *Subject:* Re: [Freeipa-users] ipa-server-upgrade failed after yum >> update on CentOS7 >> >> On 6/30/20 10:24 AM, Mariusz Stolarczyk via FreeIPA-users wrote: >>> All, >>> >>> I did a routine server updates last night on my IPA server. After the >>> reboot I first noticed the DNS was not resolving and the ipa.service >>> failed. The ipa.service failed to start so I ran the following: >>> >>> >>> # ipactl start >>> IPA version error: data needs to be upgraded (expected version >>> '4.6.6-11.el7.centos', current version '4.6.5-11.el7.centos.4') >>> Automatically running upgrade, for details see /var/log/ipaupgrade.log >>> Be patient, this may take a few minutes. >>> Automatic upgrade failed: Update complete >>> 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] >>> [Verifying that KDC configuration is using ipa-kdb backend] >>> [Fix DS schema file syntax] >>> Syntax already fixed >>> [Removing RA cert from DS NSS database] >>> RA cert already removed >>> [Enable sidgen and extdom plugins by default] >>> [Updating HTTPD service IPA configuration] >>> [Updating HTTPD service IPA WSGI configuration] >>> Nothing to do for configure_httpd_wsgi_conf >>> [Updating mod_nss protocol versions] >>> Protocol versions already updated >>> [Updating mod_nss cipher suite] >>> [Updating mod_nss enabling OCSP] >>> [Fixing trust flags in /etc/httpd/alias] >>> Trust flags already processed >>> [Moving HTTPD service keytab to gssproxy] >>> [Removing self-signed CA] >>> [Removing Dogtag 9 CA] >>> [Checking for deprecated KDC configuration files] >>> [Checking for deprecated backups of Samba configuration files] >>> [Remove FILE: prefix from 'dedicated keytab file' in Samba configuration] >>> [Update 'max smbd processes' in Samba configuration to prevent unlimited >>> SMBLoris attack amplification] >>> [Add missing CA DNS records] >>> IPA CA DNS records already processed >>> [Removing deprecated DNS configuration options] >>> [Ensuring minimal number of connections] >>> [Updating GSSAPI configuration in DNS] >>> [Updating pid-file configuration in DNS] >>> [Checking global forwarding policy in named.conf to avoid conflicts with >>> automatic empty zones] >>> Changes to named.conf have been made, restart named >>> [Upgrading CA schema] >>> CA schema update complete (no changes) >>> [Verifying that CA audit signing cert has 2 year validity] >>> [Update certmonger certificate renewal configuration] >>> Certmonger certificate renewal configuration already up-to-date >>> [Enable PKIX certificate path discovery and validation] >>> PKIX already enabled >>> [Authorizing RA Agent to modify profiles] >>> [Authorizing RA Agent to manage lightweight CAs] >>> [Ensuring Lightweight CAs container exists in Dogtag database] >>> [Adding default OCSP URI configuration] >>> [Ensuring CA is using LDAPProfileSubsystem] >>> [Migrating certificate profiles to LDAP] >>> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run >>> command ipa-server-upgrade manually. >>> Unexpected error - see /var/log/ipaupgrade.log for details: >>> NetworkError: cannot connect to >>> 'https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffake-ipa-…': >> >>> [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) >>> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for >>> more information >>> >>> See the upgrade log for more details and/or run >>> /usr/sbin/ipa-server-upgrade again >>> Aborting ipactl >>> >>> >>> The end of the /var/log/ipaupgrade.log file: >>> >>> 2020-06-29T22:43:38Z DEBUG stderr= >>> 2020-06-29T22:43:38Z DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2020-06-29T22:43:38Z DEBUG Starting external process >>> 2020-06-29T22:43:38Z DEBUG args=/usr/bin/certutil -d >>> dbm:/etc/pki/pki-tomcat/alias -L -f /etc/pki/pki-tomcat/alias/pwdfile.txt >>> 2020-06-29T22:43:38Z DEBUG Process finished, return code=0 >>> 2020-06-29T22:43:38Z 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 >>> Server-Cert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u >>> ocspSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u >>> auditSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,Pu >>> >>> 2020-06-29T22:43:38Z DEBUG stderr= >>> 2020-06-29T22:43:38Z INFO Certmonger certificate renewal configuration >>> already up-to-date >>> 2020-06-29T22:43:38Z INFO [Enable PKIX certificate path discovery and >>> validation] >>> 2020-06-29T22:43:38Z DEBUG Loading StateFile from >>> '/var/lib/ipa/sysupgrade/sysupgrade.state' >>> 2020-06-29T22:43:38Z INFO PKIX already enabled >>> 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to modify profiles] >>> 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to manage lightweight CAs] >>> 2020-06-29T22:43:38Z INFO [Ensuring Lightweight CAs container exists in >>> Dogtag database] >>> 2020-06-29T22:43:38Z DEBUG Created connection context.ldap2_140346851657552 >>> 2020-06-29T22:43:38Z DEBUG flushing >>> ldapi://%2fvar%2frun%2fslapd-FAKE-IPA-DOMAIN-LAN.socket from SchemaCache >>> 2020-06-29T22:43:38Z DEBUG retrieving schema for SchemaCache >>> url=ldapi://%2fvar%2frun%2fslapd-FAKE-IPA-DOMAIN-LAN.socket >>> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50c3e8e60> >>> 2020-06-29T22:43:39Z DEBUG Destroyed connection >>> context.ldap2_140346851657552 >>> 2020-06-29T22:43:39Z INFO [Adding default OCSP URI configuration] >>> 2020-06-29T22:43:39Z INFO [Ensuring CA is using LDAPProfileSubsystem] >>> 2020-06-29T22:43:39Z INFO [Migrating certificate profiles to LDAP] >>> 2020-06-29T22:43:39Z DEBUG Created connection context.ldap2_140346825804304 >>> 2020-06-29T22:43:39Z DEBUG flushing >>> ldapi://%2fvar%2frun%2fslapd-FAKE-IPA-DOMAIN-LAN.socket from SchemaCache >>> 2020-06-29T22:43:39Z DEBUG retrieving schema for SchemaCache >>> url=ldapi://%2fvar%2frun%2fslapd-FAKE-IPA-DOMAIN-LAN.socket >>> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50ac19b90> >>> 2020-06-29T22:43:39Z DEBUG Destroyed connection >>> context.ldap2_140346825804304 >>> 2020-06-29T22:43:39Z DEBUG request GET >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffake-ipa-… >>> 2020-06-29T22:43:39Z DEBUG request body '' >>> 2020-06-29T22:43:39Z DEBUG httplib request failed: >>> Traceback (most recent call last): >>> Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line >>> 220, in _httplib_request >>> Â Â conn.request(method, path, body=request_body, headers=headers) >>> Â File "/usr/lib64/python2.7/httplib.py", line 1056, in request >>> Â Â self._send_request(method, url, body, headers) >>> Â File "/usr/lib64/python2.7/httplib.py", line 1090, in _send_request >>> Â Â self.endheaders(body) >>> Â File "/usr/lib64/python2.7/httplib.py", line 1052, in endheaders >>> Â Â self._send_output(message_body) >>> Â File "/usr/lib64/python2.7/httplib.py", line 890, in _send_output >>> Â Â self.send(msg) >>> Â File "/usr/lib64/python2.7/httplib.py", line 852, in send >>> Â Â self.connect() >>> Â File "/usr/lib64/python2.7/httplib.py", line 1275, in connect >>> Â Â server_hostname=sni_hostname) >>> Â File "/usr/lib64/python2.7/ssl.py", line 348, in wrap_socket >>> Â Â _context=self) >>> Â File "/usr/lib64/python2.7/ssl.py", line 609, in __init__ >>> Â Â self.do_handshake() >>> Â File "/usr/lib64/python2.7/ssl.py", line 831, in do_handshake >>> Â Â self._sslobj.do_handshake() >>> SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed >>> (_ssl.c:618) >>> 2020-06-29T22:43:39Z ERROR IPA server upgrade failed: Inspect >>> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. >>> 2020-06-29T22:43:39Z 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 2166, in upgrade >>> Â Â upgrade_configuration() >>> Â File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >>> line 2038, in upgrade_configuration >>> Â Â ca_enable_ldap_profile_subsystem(ca) >>> Â File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >>> line 425, 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 1311, in __enter__ >>> Â Â method='GET' >>> Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line >>> 167, in https_request >>> Â Â method=method, headers=headers) >>> Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line >>> 229, in _httplib_request >>> Â �� raise NetworkError(uri=uri, error=str(e)) >>> >>> 2020-06-29T22:43:39Z DEBUG The ipa-server-upgrade command failed, >>> exception: NetworkError: cannot connect to >>> 'https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffake-ipa-…': >> >>> [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) >>> 2020-06-29T22:43:39Z ERROR Unexpected error - see >>> /var/log/ipaupgrade.log for details: >>> NetworkError: cannot connect to >>> 'https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffake-ipa-…': >> >>> [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) >>> 2020-06-29T22:43:39Z ERROR The ipa-server-upgrade command failed. See >>> /var/log/ipaupgrade.log for more information >>> >>> >>> What should be my next debug steps? >>> >> Hi, >> >> I would check whether any certificate expired: >> $ getcert list >> >> Look specifically for the "status: " and "expires: " labels. If some >> certs have expired, you will need to find the CA renewal master and fix >> this host first. To find the CA renewal master: >> $ kinit admin >> $ ipa config-show | grep "CA renewal" >> >> If you need help, please mention: >> - the output of "ipa server-role-find" >> - the output of "getcert list" on all the server nodes >> - are the httpd and ldap server certificates issued by IPA CA or by an >> external Certificate Authority? >> >> HTH, >> flo >> >>> Thanks in advance, >>> -ms >>> >>> >>> _______________________________________________ >>> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… >>> List Guidelines: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… >>> List Archives: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… >>> >> >> >> _______________________________________________ >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… >> List Guidelines: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… >> List Archives: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… >> > > > _______________________________________________ > 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 1

Change password hash for LDAP
by Max Muller 01 Jul '20

01 Jul '20

Hi all! I want use FreeIPA with FreeRADIUS. As I can know, FreeIPA use PBKDF2_SHA256 hashes. But actual FreeRADIUS not support PBKDF2_SHA256 hashes. Is there way to change hash in FreeIPA? About FreeRADIUS and PBKDF2_SHA256 https://github.com/FreeRADIUS/freeradius-server/issues/2649

2 2

Groups and Permissions
by Mark Potter 01 Jul '20

01 Jul '20

I have noticed that group membership is functioning differently on CentOS 8 with FreeIPA 4.8.4-7 than I remember it functioning on CentOS 7. This is a clean install with no use of backups. I have a user user(2063) with a primary group of admingroup(2060). I set up a sudo rule for members of admingroup(2060) and still could not sudo. The user does not show up in admingroup(2060) as a member and could not use sudo until I added the user to the group. I do not remember this being the case when we were using CentOS 7 and the available packages. I have also seen this when creating a service use to set up crons to keep the new FreeIPA installation in sync with the OpenLDAP installation we are replacing. No users show as members of the group assigned as the user's GID. My memory could be incorrect but I do not remember having to add members to groups that had a primary GID of said group in order for sudo rules or ipa commands to work (after kinit of course). If this is by design then I will need to write something really quick to get members added to their primary groups or if it's a setting I haven't been able to find it. I would appreciate any help. -- *Mark Potter* Senior Linux Administrator DownUnder GeoSolutions

1 0

Re: ipa-server-upgrade failed after yum update on CentOS7
by Rob Crittenden 01 Jul '20

01 Jul '20

Mariusz Stolarczyk via FreeIPA-users wrote: > Thanks for the response. > > This is my main IPA server the rest of my small network are just linux > clients. > > > kinit: Cannot contact any KDC for realm 'FAKE-IPA-DOMAIN.LAN' while > getting initial credentials The other information that Flo requested is needed as well. Three of your certificates expired on June 24 and to create a plan to fix it we need the other info. rob > > > # getcert list > Number of certificates and requests being tracked: 9. > Request ID '20171108154417': > status: MONITORING > stuck: no > key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key' > certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' > CA: SelfSign > issuer: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN > subject: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-09-13 20:50:34 UTC > principal name: krbtgt/FAKE-IPA-DOMAIN.LAN(a)FAKE-IPA-DOMAIN.LAN > certificate template/profile: KDCs_PKINIT_Certs > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert > track: yes > auto-renew: yes > Request ID '20181122014941': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=CA Audit,O=FAKE-IPA-DOMAIN.LAN > expires: 2022-05-18 03:13:17 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20181122014942': > status: CA_UNREACHABLE > ca-error: Internal error > 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=FAKE-IPA-DOMAIN.LAN > subject: CN=OCSP Subsystem,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-06-24 23:56:43 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 '20181122014943': > 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=FAKE-IPA-DOMAIN.LAN > subject: CN=CA Subsystem,O=FAKE-IPA-DOMAIN.LAN > expires: 2022-05-18 03:11:57 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 '20181122014944': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > expires: 2036-08-12 21:35:52 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "caSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20181122014945': > status: CA_UNREACHABLE > ca-error: Internal error > 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=FAKE-IPA-DOMAIN.LAN > subject: CN=IPA RA,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-06-24 23:56:33 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 > Request ID '20181122014946': > status: CA_UNREACHABLE > ca-error: Internal error > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-06-24 23:55:43 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 > "Server-Cert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20181122014947': > status: CA_UNREACHABLE > ca-error: Error setting up ccache for "host" service on client using > default keytab: Cannot contact any KDC for realm 'FAKE-IPA-DOMAIN.LAN'. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-FAKE-IPA-DOMAIN-LAN',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN > expires: 2020-07-17 16:47:45 UTC > principal name: ldap/sol.FAKE-IPA-DOMAIN.LAN(a)FAKE-IPA-DOMAIN.LAN > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv > FAKE-IPA-DOMAIN-LAN > track: yes > auto-renew: yes > Request ID '20181122014948': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=FAKE-IPA-DOMAIN.LAN > subject: CN=sol.FAKE-IPA-DOMAIN.LAN,O=FAKE-IPA-DOMAIN.LAN > expires: 2022-03-16 22:14:54 UTC > dns: sol.FAKE-IPA-DOMAIN.LAN > principal name: HTTP/sol.FAKE-IPA-DOMAIN.LAN(a)FAKE-IPA-DOMAIN.LAN > key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > > What can I do next? > > Thanks, > -ms > > > > ------------------------------------------------------------------------ > *From:* Florence Blanc-Renaud <flo(a)redhat.com> > *Sent:* Tuesday, June 30, 2020 1:45 AM > *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > *Cc:* Mariusz Stolarczyk <zeusuofm(a)hotmail.com> > *Subject:* Re: [Freeipa-users] ipa-server-upgrade failed after yum > update on CentOS7 > > On 6/30/20 10:24 AM, Mariusz Stolarczyk via FreeIPA-users wrote: >> All, >> >> I did a routine server updates last night on my IPA server. After the >> reboot I first noticed the DNS was not resolving and the ipa.service >> failed. The ipa.service failed to start so I ran the following: >> >> >> # ipactl start >> IPA version error: data needs to be upgraded (expected version >> '4.6.6-11.el7.centos', current version '4.6.5-11.el7.centos.4') >> Automatically running upgrade, for details see /var/log/ipaupgrade.log >> Be patient, this may take a few minutes. >> Automatic upgrade failed: Update complete >> 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] >> [Verifying that KDC configuration is using ipa-kdb backend] >> [Fix DS schema file syntax] >> Syntax already fixed >> [Removing RA cert from DS NSS database] >> RA cert already removed >> [Enable sidgen and extdom plugins by default] >> [Updating HTTPD service IPA configuration] >> [Updating HTTPD service IPA WSGI configuration] >> Nothing to do for configure_httpd_wsgi_conf >> [Updating mod_nss protocol versions] >> Protocol versions already updated >> [Updating mod_nss cipher suite] >> [Updating mod_nss enabling OCSP] >> [Fixing trust flags in /etc/httpd/alias] >> Trust flags already processed >> [Moving HTTPD service keytab to gssproxy] >> [Removing self-signed CA] >> [Removing Dogtag 9 CA] >> [Checking for deprecated KDC configuration files] >> [Checking for deprecated backups of Samba configuration files] >> [Remove FILE: prefix from 'dedicated keytab file' in Samba configuration] >> [Update 'max smbd processes' in Samba configuration to prevent unlimited >> SMBLoris attack amplification] >> [Add missing CA DNS records] >> IPA CA DNS records already processed >> [Removing deprecated DNS configuration options] >> [Ensuring minimal number of connections] >> [Updating GSSAPI configuration in DNS] >> [Updating pid-file configuration in DNS] >> [Checking global forwarding policy in named.conf to avoid conflicts with >> automatic empty zones] >> Changes to named.conf have been made, restart named >> [Upgrading CA schema] >> CA schema update complete (no changes) >> [Verifying that CA audit signing cert has 2 year validity] >> [Update certmonger certificate renewal configuration] >> Certmonger certificate renewal configuration already up-to-date >> [Enable PKIX certificate path discovery and validation] >> PKIX already enabled >> [Authorizing RA Agent to modify profiles] >> [Authorizing RA Agent to manage lightweight CAs] >> [Ensuring Lightweight CAs container exists in Dogtag database] >> [Adding default OCSP URI configuration] >> [Ensuring CA is using LDAPProfileSubsystem] >> [Migrating certificate profiles to LDAP] >> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run >> command ipa-server-upgrade manually. >> Unexpected error - see /var/log/ipaupgrade.log for details: >> NetworkError: cannot connect to >> 'https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffake-ipa-…': > >> [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) >> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for >> more information >> >> See the upgrade log for more details and/or run >> /usr/sbin/ipa-server-upgrade again >> Aborting ipactl >> >> >> The end of the /var/log/ipaupgrade.log file: >> >> 2020-06-29T22:43:38Z DEBUG stderr= >> 2020-06-29T22:43:38Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2020-06-29T22:43:38Z DEBUG Starting external process >> 2020-06-29T22:43:38Z DEBUG args=/usr/bin/certutil -d >> dbm:/etc/pki/pki-tomcat/alias -L -f /etc/pki/pki-tomcat/alias/pwdfile.txt >> 2020-06-29T22:43:38Z DEBUG Process finished, return code=0 >> 2020-06-29T22:43:38Z 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 >> Server-Cert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u >> ocspSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u >> auditSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,Pu >> >> 2020-06-29T22:43:38Z DEBUG stderr= >> 2020-06-29T22:43:38Z INFO Certmonger certificate renewal configuration >> already up-to-date >> 2020-06-29T22:43:38Z INFO [Enable PKIX certificate path discovery and >> validation] >> 2020-06-29T22:43:38Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysupgrade/sysupgrade.state' >> 2020-06-29T22:43:38Z INFO PKIX already enabled >> 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to modify profiles] >> 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to manage lightweight CAs] >> 2020-06-29T22:43:38Z INFO [Ensuring Lightweight CAs container exists in >> Dogtag database] >> 2020-06-29T22:43:38Z DEBUG Created connection context.ldap2_140346851657552 >> 2020-06-29T22:43:38Z DEBUG flushing >> ldapi://%2fvar%2frun%2fslapd-FAKE-IPA-DOMAIN-LAN.socket from SchemaCache >> 2020-06-29T22:43:38Z DEBUG retrieving schema for SchemaCache >> url=ldapi://%2fvar%2frun%2fslapd-FAKE-IPA-DOMAIN-LAN.socket >> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50c3e8e60> >> 2020-06-29T22:43:39Z DEBUG Destroyed connection >> context.ldap2_140346851657552 >> 2020-06-29T22:43:39Z INFO [Adding default OCSP URI configuration] >> 2020-06-29T22:43:39Z INFO [Ensuring CA is using LDAPProfileSubsystem] >> 2020-06-29T22:43:39Z INFO [Migrating certificate profiles to LDAP] >> 2020-06-29T22:43:39Z DEBUG Created connection context.ldap2_140346825804304 >> 2020-06-29T22:43:39Z DEBUG flushing >> ldapi://%2fvar%2frun%2fslapd-FAKE-IPA-DOMAIN-LAN.socket from SchemaCache >> 2020-06-29T22:43:39Z DEBUG retrieving schema for SchemaCache >> url=ldapi://%2fvar%2frun%2fslapd-FAKE-IPA-DOMAIN-LAN.socket >> conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50ac19b90> >> 2020-06-29T22:43:39Z DEBUG Destroyed connection >> context.ldap2_140346825804304 >> 2020-06-29T22:43:39Z DEBUG request GET >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffake-ipa-… >> 2020-06-29T22:43:39Z DEBUG request body '' >> 2020-06-29T22:43:39Z DEBUG httplib request failed: >> Traceback (most recent call last): >> Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line >> 220, in _httplib_request >> Â Â conn.request(method, path, body=request_body, headers=headers) >> Â File "/usr/lib64/python2.7/httplib.py", line 1056, in request >> Â Â self._send_request(method, url, body, headers) >> Â File "/usr/lib64/python2.7/httplib.py", line 1090, in _send_request >> Â Â self.endheaders(body) >> Â File "/usr/lib64/python2.7/httplib.py", line 1052, in endheaders >> Â Â self._send_output(message_body) >> Â File "/usr/lib64/python2.7/httplib.py", line 890, in _send_output >> Â Â self.send(msg) >> Â File "/usr/lib64/python2.7/httplib.py", line 852, in send >> Â Â self.connect() >> Â File "/usr/lib64/python2.7/httplib.py", line 1275, in connect >> Â Â server_hostname=sni_hostname) >> Â File "/usr/lib64/python2.7/ssl.py", line 348, in wrap_socket >> Â Â _context=self) >> Â File "/usr/lib64/python2.7/ssl.py", line 609, in __init__ >> Â Â self.do_handshake() >> Â File "/usr/lib64/python2.7/ssl.py", line 831, in do_handshake >> Â Â self._sslobj.do_handshake() >> SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed >> (_ssl.c:618) >> 2020-06-29T22:43:39Z ERROR IPA server upgrade failed: Inspect >> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. >> 2020-06-29T22:43:39Z 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 2166, in upgrade >> Â Â upgrade_configuration() >> Â File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >> line 2038, in upgrade_configuration >> Â Â ca_enable_ldap_profile_subsystem(ca) >> Â File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >> line 425, 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 1311, in __enter__ >> Â Â method='GET' >> Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line >> 167, in https_request >> Â Â method=method, headers=headers) >> Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line >> 229, in _httplib_request >> Â �� raise NetworkError(uri=uri, error=str(e)) >> >> 2020-06-29T22:43:39Z DEBUG The ipa-server-upgrade command failed, >> exception: NetworkError: cannot connect to >> 'https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffake-ipa-…': > >> [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) >> 2020-06-29T22:43:39Z ERROR Unexpected error - see >> /var/log/ipaupgrade.log for details: >> NetworkError: cannot connect to >> 'https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffake-ipa-…': > >> [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) >> 2020-06-29T22:43:39Z ERROR The ipa-server-upgrade command failed. See >> /var/log/ipaupgrade.log for more information >> >> >> What should be my next debug steps? >> > Hi, > > I would check whether any certificate expired: > $ getcert list > > Look specifically for the "status: " and "expires: " labels. If some > certs have expired, you will need to find the CA renewal master and fix > this host first. To find the CA renewal master: > $ kinit admin > $ ipa config-show | grep "CA renewal" > > If you need help, please mention: > - the output of "ipa server-role-find" > - the output of "getcert list" on all the server nodes > - are the httpd and ldap server certificates issued by IPA CA or by an > external Certificate Authority? > > HTH, > flo > >> Thanks in advance, >> -ms >> >> >> _______________________________________________ >> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… >> List Guidelines: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… >> List Archives: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… >> > > > _______________________________________________ > 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 1

Re: ipa-server-upgrade failed after yum update on CentOS7
by Florence Blanc-Renaud 30 Jun '20

30 Jun '20

On 6/30/20 10:24 AM, Mariusz Stolarczyk via FreeIPA-users wrote: > All, > > I did a routine server updates last night on my IPA server. After the > reboot I first noticed the DNS was not resolving and the ipa.service > failed. The ipa.service failed to start so I ran the following: > > > # ipactl start > IPA version error: data needs to be upgraded (expected version > '4.6.6-11.el7.centos', current version '4.6.5-11.el7.centos.4') > Automatically running upgrade, for details see /var/log/ipaupgrade.log > Be patient, this may take a few minutes. > Automatic upgrade failed: Update complete > 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] > [Verifying that KDC configuration is using ipa-kdb backend] > [Fix DS schema file syntax] > Syntax already fixed > [Removing RA cert from DS NSS database] > RA cert already removed > [Enable sidgen and extdom plugins by default] > [Updating HTTPD service IPA configuration] > [Updating HTTPD service IPA WSGI configuration] > Nothing to do for configure_httpd_wsgi_conf > [Updating mod_nss protocol versions] > Protocol versions already updated > [Updating mod_nss cipher suite] > [Updating mod_nss enabling OCSP] > [Fixing trust flags in /etc/httpd/alias] > Trust flags already processed > [Moving HTTPD service keytab to gssproxy] > [Removing self-signed CA] > [Removing Dogtag 9 CA] > [Checking for deprecated KDC configuration files] > [Checking for deprecated backups of Samba configuration files] > [Remove FILE: prefix from 'dedicated keytab file' in Samba configuration] > [Update 'max smbd processes' in Samba configuration to prevent unlimited > SMBLoris attack amplification] > [Add missing CA DNS records] > IPA CA DNS records already processed > [Removing deprecated DNS configuration options] > [Ensuring minimal number of connections] > [Updating GSSAPI configuration in DNS] > [Updating pid-file configuration in DNS] > [Checking global forwarding policy in named.conf to avoid conflicts with > automatic empty zones] > Changes to named.conf have been made, restart named > [Upgrading CA schema] > CA schema update complete (no changes) > [Verifying that CA audit signing cert has 2 year validity] > [Update certmonger certificate renewal configuration] > Certmonger certificate renewal configuration already up-to-date > [Enable PKIX certificate path discovery and validation] > PKIX already enabled > [Authorizing RA Agent to modify profiles] > [Authorizing RA Agent to manage lightweight CAs] > [Ensuring Lightweight CAs container exists in Dogtag database] > [Adding default OCSP URI configuration] > [Ensuring CA is using LDAPProfileSubsystem] > [Migrating certificate profiles to LDAP] > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > command ipa-server-upgrade manually. > Unexpected error - see /var/log/ipaupgrade.log for details: > NetworkError: cannot connect to > 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': > [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information > > See the upgrade log for more details and/or run > /usr/sbin/ipa-server-upgrade again > Aborting ipactl > > > The end of the /var/log/ipaupgrade.log file: > > 2020-06-29T22:43:38Z DEBUG stderr= > 2020-06-29T22:43:38Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2020-06-29T22:43:38Z DEBUG Starting external process > 2020-06-29T22:43:38Z DEBUG args=/usr/bin/certutil -d > dbm:/etc/pki/pki-tomcat/alias -L -f /etc/pki/pki-tomcat/alias/pwdfile.txt > 2020-06-29T22:43:38Z DEBUG Process finished, return code=0 > 2020-06-29T22:43:38Z 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 > Server-Cert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u > ocspSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,u > auditSigningCert cert-pki-ca Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â u,u,Pu > > 2020-06-29T22:43:38Z DEBUG stderr= > 2020-06-29T22:43:38Z INFO Certmonger certificate renewal configuration > already up-to-date > 2020-06-29T22:43:38Z INFO [Enable PKIX certificate path discovery and > validation] > 2020-06-29T22:43:38Z DEBUG Loading StateFile from > '/var/lib/ipa/sysupgrade/sysupgrade.state' > 2020-06-29T22:43:38Z INFO PKIX already enabled > 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to modify profiles] > 2020-06-29T22:43:38Z INFO [Authorizing RA Agent to manage lightweight CAs] > 2020-06-29T22:43:38Z INFO [Ensuring Lightweight CAs container exists in > Dogtag database] > 2020-06-29T22:43:38Z DEBUG Created connection context.ldap2_140346851657552 > 2020-06-29T22:43:38Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket from SchemaCache > 2020-06-29T22:43:38Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket > conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50c3e8e60> > 2020-06-29T22:43:39Z DEBUG Destroyed connection > context.ldap2_140346851657552 > 2020-06-29T22:43:39Z INFO [Adding default OCSP URI configuration] > 2020-06-29T22:43:39Z INFO [Ensuring CA is using LDAPProfileSubsystem] > 2020-06-29T22:43:39Z INFO [Migrating certificate profiles to LDAP] > 2020-06-29T22:43:39Z DEBUG Created connection context.ldap2_140346825804304 > 2020-06-29T22:43:39Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket from SchemaCache > 2020-06-29T22:43:39Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-SEQUOIARC-LAN.socket > conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7fa50ac19b90> > 2020-06-29T22:43:39Z DEBUG Destroyed connection > context.ldap2_140346825804304 > 2020-06-29T22:43:39Z DEBUG request GET > https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login > 2020-06-29T22:43:39Z DEBUG request body '' > 2020-06-29T22:43:39Z DEBUG httplib request failed: > Traceback (most recent call last): > Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line > 220, in _httplib_request > Â Â conn.request(method, path, body=request_body, headers=headers) > Â File "/usr/lib64/python2.7/httplib.py", line 1056, in request > Â Â self._send_request(method, url, body, headers) > Â File "/usr/lib64/python2.7/httplib.py", line 1090, in _send_request > Â Â self.endheaders(body) > Â File "/usr/lib64/python2.7/httplib.py", line 1052, in endheaders > Â Â self._send_output(message_body) > Â File "/usr/lib64/python2.7/httplib.py", line 890, in _send_output > Â Â self.send(msg) > Â File "/usr/lib64/python2.7/httplib.py", line 852, in send > Â Â self.connect() > Â File "/usr/lib64/python2.7/httplib.py", line 1275, in connect > Â Â server_hostname=sni_hostname) > Â File "/usr/lib64/python2.7/ssl.py", line 348, in wrap_socket > Â Â _context=self) > Â File "/usr/lib64/python2.7/ssl.py", line 609, in __init__ > Â Â self.do_handshake() > Â File "/usr/lib64/python2.7/ssl.py", line 831, in do_handshake > Â Â self._sslobj.do_handshake() > SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed > (_ssl.c:618) > 2020-06-29T22:43:39Z ERROR IPA server upgrade failed: Inspect > /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. > 2020-06-29T22:43:39Z 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 2166, in upgrade > Â Â upgrade_configuration() > Â File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 2038, in upgrade_configuration > Â Â ca_enable_ldap_profile_subsystem(ca) > Â File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 425, 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 1311, in __enter__ > Â Â method='GET' > Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line > 167, in https_request > Â Â method=method, headers=headers) > Â File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line > 229, in _httplib_request > Â Â raise NetworkError(uri=uri, error=str(e)) > > 2020-06-29T22:43:39Z DEBUG The ipa-server-upgrade command failed, > exception: NetworkError: cannot connect to > 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': > [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) > 2020-06-29T22:43:39Z ERROR Unexpected error - see > /var/log/ipaupgrade.log for details: > NetworkError: cannot connect to > 'https://FAKE-IPA-HOST.FAKE-IPA-DOMAIN.LAN:8443/ca/rest/account/login': > [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) > 2020-06-29T22:43:39Z ERROR The ipa-server-upgrade command failed. See > /var/log/ipaupgrade.log for more information > > > What should be my next debug steps? > Hi, I would check whether any certificate expired: $ getcert list Look specifically for the "status: " and "expires: " labels. If some certs have expired, you will need to find the CA renewal master and fix this host first. To find the CA renewal master: $ kinit admin $ ipa config-show | grep "CA renewal" If you need help, please mention: - the output of "ipa server-role-find" - the output of "getcert list" on all the server nodes - are the httpd and ldap server certificates issued by IPA CA or by an external Certificate Authority? HTH, flo > Thanks in advance, > -ms > > > _______________________________________________ > 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 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users July 2020