June 2020 - FreeIPA-users - Fedora mailing-lists

certmonger failing
by Rob Verduijn 16 Jun '20

16 Jun '20

Hello, Today I upgraded my ipaserver from centos 8.1 to centos 8.2 And ipa-healthcheck --failures-only claims all my certs have expired in 1970. Which is a bit weird since they all seem to work fine for me. Everything seems to work except for a lot of errors in my logs from certmonger. I get a lot of these : ... [8777] Error authenticating to token "NSS Certificate DB". ... [8777] Error shutting down NSS. ... [8778] Token is named "NSS Generic Crypto Services", not "NSS Certificate DB", skipping. ... [8778] certread-n: Error authenticating to cert db slot NSS Certificate DB. ... [8778] Error locating certificate. ... [8778] Error shutting down NSS. ... [8779] Error authenticating to token "NSS Certificate DB". ... [8779] Error shutting down NSS. ... [8780] Token is named "NSS Generic Crypto Services", not "NSS Certificate DB", skipping. ... [8780] certread-n: Error authenticating to cert db slot NSS Certificate DB. Certmonger is up and running, but not functioning. Anybody know how to get certmonger to function properly again ? Rob

2 2

Re: Last FreeIPA master is failing
by Rob Crittenden 16 Jun '20

16 Jun '20

Ricardo Mendes via FreeIPA-users wrote: >>I think you need to see what certs and keys are in /etc/httpd/alias. >> Sounds like there is no Server-Cert nickname. > > certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt > certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt > > This is the output, and I'm adding getcert list in the end as well. > > > # certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > DSTRootCAX3 C,, > CN=main.domain.io u,u,u > letsencryptx3 C,, > letsencryptx3 C,, > ISRGRootCAX1 C,, > DOMAIN.IO IPA CA CT,C, > > # certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt > certutil: Checking token "NSS Certificate DB" in slot "NSS User Private > Key and Certificate Services" > < 0> rsa 493a92843c598413e3f50ca923706417821bf392 CN=main.domain.io > < 1> rsa e946257bb7a486f489287ccd72dab14067eae2b7 CN=main.domain.io > < 2> rsa 8bbe08dd006063eea896aee19f24da6b5f28f348 CN=main.domain.io > < 3> rsa ac96e477d65db3ba63213332c30ac7733bf70a10 (orphan) > < 4> rsa b40bea3d28cce1ea7274f8ecf47b2d70f5e0c0c1 CN=main.domain.io > # > Right the cert nickname is CN=main.domain.io. I'm assuming you manually installed the LE certs originally using ipa-server-certinstall right? That doesn't follow the pattern of using Server-Cert for the nickname by default. You can probably just hack the LE script and replace Server-Cert with CN=main.domain.io. It's important to know that the LE script was written specifically for the IPA demo site and a repo created to share the general method. It isn't shipped with IPA or otherwise really supported at all. No backwards compatibility testing is done, just what is needed for the demo site. So while it might eventually work fine for you it isn't intended to be a general-purpose tool. rob > # getcert list > Number of certificates and requests being tracked: 7. > Request ID '20190220114014': > 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: IPA > issuer: CN=Certificate Authority,O=DOMAIN.IO > subject: CN=main.domain.io,O=DOMAIN.IO > expires: 2021-02-20 11:40:16 UTC > principal name: krbtgt/DOMAIN.IO(a)DOMAIN.IO > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-pkinit-KPKdc > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert > track: yes > auto-renew: yes > Request ID '20190819230939': > 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=DOMAIN.IO > subject: CN=CA Audit,O=DOMAIN.IO > expires: 2021-02-09 11:36:51 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 '20190819230940': > 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=DOMAIN.IO > subject: CN=OCSP Subsystem,O=DOMAIN.IO > expires: 2021-02-09 11:36:48 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 '20190819230941': > 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=DOMAIN.IO > subject: CN=CA Subsystem,O=DOMAIN.IO > expires: 2021-02-09 11:36:50 UTC > 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 > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20190819230942': > 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=DOMAIN.IO > subject: CN=Certificate Authority,O=DOMAIN.IO > expires: 2039-02-20 11:36:43 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 '20190819230943': > status: MONITORING > stuck: no > key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key' > certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=DOMAIN.IO > subject: CN=IPA RA,O=DOMAIN.IO > expires: 2021-02-09 11:37:44 UTC > key usage: digitalSignature,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 '20190819230944': > status: MONITORING > 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=DOMAIN.IO > subject: CN=main.domain.io,O=DOMAIN.IO > expires: 2021-02-09 11:36:49 UTC > dns: main.domain.io > key usage: digitalSignature,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth > 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 > > >> > (btw https://lists.fedoraproject.org is down) > >> Related to the Fedora infrastructure move. > > hope all is going well! > > Ricardo > _______________________________________________ > 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

[CVE-2020-10747] FreeIPA 4.6.9 released
by Alexander Bokovoy 15 Jun '20

15 Jun '20

Hello! The FreeIPA team would like to announce FreeIPA 4.6.9 release! It can be downloaded from http://www.freeipa.org/page/Downloads. == Highlights in 4.6.9 == * CVE-2020-10747 It was found that if an account with a name corresponding to an account local to a system, such as 'root', was created via IPA, such account could access any enrolled machine with that identitity and the local system privileges. This also bypass the absence of explicit HBAC rules. Since the account can only be created by user administrators in FreeIPA, several changes were done to tighten permissions and prevent creation of 'root' identity by mistake. root principal alias ------------------- The principal "root@REALM" is now a Kerberos principal alias for "admin". This prevent user with "User Administrator" role or "System: Add User" privilege to create an account with "root" principal name. Modified user permissions ------------------------- Several user permissions no longer apply to admin users and filter on posixAccount object class. This prevents user managers from modifying admin acounts: - System: Manage User Certificates - System: Manage User Principals - System: Manage User SSH Public Keys - System: Modify Users - System: Remove Users - System: Unlock user ``System: Unlock User`` permission is now restricted because the permission also allows a user manager to lock an admin account. ``System: Modify Users`` is restricted to prevent user managers from changing login shell or notification channels (mail, mobile) of admin accounts. New user permission ------------------- - System: Change Admin User password This new permission allows manipulation of admin user password fields. By default only the ``PassSync Service`` privilege is allowed to modify admin user password fields. Modified group permissions -------------------------- Group permissions are now restricted as well. Group admins can no longer modify the admins group and are limited to groups with object class ``ipausergroup``. - System: Modify Groups - System: Remove Groups The permission ``System: Modify Group Membership`` was already limited. == Upgrading == Upgrade instructions are available on [[Upgrade]] page. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahos…) or #freeipa channel on Freenode. == Resolved tickets == * [https://pagure.io/freeipa/issue/8326 #8326] CVE-2020-10747 == Detailed changelog since 4.6.8 == === Alexander Bokovoy (1) === * Become FreeIPA 4.6.9 [https://pagure.io/freeipa/c/4f1f8754742d55263a7da89575c5d94b5ea4c7e3 commit] === Christian Heimes (1) === * Prevent local account takeover [https://pagure.io/freeipa/c/316ac7cd62ac130f88b374c1f9f47b41806187c1 commit] [https://pagure.io/freeipa/issue/8326 #8326] -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

1 0

[CVE-2020-10747] FreeIPA 4.8.8 released
by Alexander Bokovoy 15 Jun '20

15 Jun '20

Hello! The FreeIPA team would like to announce FreeIPA 4.8.8 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora distributions will be available from the official repository soon. == Highlights in 4.8.8 == * CVE-2020-10747 It was found that if an account with a name corresponding to an account local to a system, such as 'root', was created via IPA, such account could access any enrolled machine with that identitity and the local system privileges. This also bypass the absence of explicit HBAC rules. Since the account can only be created by user administrators in FreeIPA, several changes were done to tighten permissions and prevent creation of 'root' identity by mistake. root principal alias ------------------- The principal "root@REALM" is now a Kerberos principal alias for "admin". This prevent user with "User Administrator" role or "System: Add User" privilege to create an account with "root" principal name. Modified user permissions ------------------------- Several user permissions no longer apply to admin users and filter on posixAccount object class. This prevents user managers from modifying admin acounts: - System: Manage User Certificates - System: Manage User Principals - System: Manage User SSH Public Keys - System: Modify Users - System: Remove Users - System: Unlock user ``System: Unlock User`` permission is now restricted because the permission also allows a user manager to lock an admin account. ``System: Modify Users`` is restricted to prevent user managers from changing login shell or notification channels (mail, mobile) of admin accounts. New user permission ------------------- - System: Change Admin User password This new permission allows manipulation of admin user password fields. By default only the ``PassSync Service`` privilege is allowed to modify admin user password fields. Modified group permissions -------------------------- Group permissions are now restricted as well. Group admins can no longer modify the admins group and are limited to groups with object class ``ipausergroup``. - System: Modify Groups - System: Remove Groups The permission ``System: Modify Group Membership`` was already limited. == Upgrading == Upgrade instructions are available on [[Upgrade]] page. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahos…) or #freeipa channel on Freenode. == Resolved tickets == * [https://pagure.io/freeipa/issue/8326 #8326] CVE-2020-10747 == Detailed changelog since 4.8.7 == === Alexander Bokovoy (1) === * Become FreeIPA 4.8.8 [https://pagure.io/freeipa/c/86ab7590779b9e25c6a52cf5a785925103d9ee8a commit] === Christian Heimes (1) === * Prevent local account takeover [https://pagure.io/freeipa/c/65c2736bd20ffb9d98769e71d905f71d1a4d857e commit] [https://pagure.io/freeipa/issue/8326 #8326] -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

1 0

automember hostgroup by account?
by Amos 14 Jun '20

14 Jun '20

Is it possible to have an automember rule to add a host to a hostgroup based on the account used with ipa-install-client? Amos

3 6

Re: Last FreeIPA master is failing
by Rob Crittenden 11 Jun '20

11 Jun '20

Ricardo Mendes wrote: > Hi Rob, > > Again thanks for your reply. So I got went to the commit that lasted > from 2017 and re-ran setup-le.sh > Output is here: > > https://pastebin.com/JAaD4R21 > > In the end I get this error: > > ipaplatform.redhat.tasks: INFO: Systemwide CA database updated. > ipalib.backend: DEBUG: Destroyed connection > context.rpcclient_140213913461328 > ipapython.admintool: INFO: The ipa-certupdate command was successful > certutil: Server-Cert is neither a key-type nor a nickname nor a key-id: > SEC_ERROR_INVALID_ARGS: security library: invalid arguments. > > If I try renew-le > > # bash renew-le.sh > certutil: could not find certificate named "Server-Cert": > PR_FILE_NOT_FOUND_ERROR: File not found > certutil: Server-Cert is neither a key-type nor a nickname nor a key-id: > SEC_ERROR_INVALID_ARGS: security library: invalid arguments. I think you need to see what certs and keys are in /etc/httpd/alias. Sounds like there is no Server-Cert nickname. certutil -L -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt certutil -K -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt > (btw https://lists.fedoraproject.org is down) Related to the Fedora infrastructure move. rob > > > Ricardo Mendes via FreeIPA-users wrote: > >> Ok so I don't know what happened the server really did take a long >> time to come up but it did. >> >> Everything looks pretty much the same. The setup-le.sh command I ran >> that said >> >>> The ipa-certupdate command was successful >> But I can't see it. I have to start ipa services with >> --ignore-service-failure and --skip-version-check >> When I go to web I still see the old expired certificate from May 21st. >> >> I tried to run renew-le and I get this error: >> >> # bash renew-le.sh >> Error opening Certificate /var/lib/ipa/certs/httpd.crt >> 140430772283280:error:02001002:system library:fopen:No such file or >> directory:bss_file.c:402:fopen('/var/lib/ipa/certs/httpd.crt','r') >> 140430772283280:error:20074002:BIO routines:FILE_CTRL:system >> lib:bss_file.c:404: >> unable to load certificate >> > That's the incompatibilities I mentioned. I think if you pop the top one > or two commits off then it will start to work again. Look for a commit > that's like "switch to mod_ssl" and pop that off. > > rob > >

2 1

Last FreeIPA master is failing
by Ricardo Mendes 11 Jun '20

11 Jun '20

Hi all, I'm having serious issues with our FreeIPA setup and I need some direction. Our FreeIPA setup had two master-replicas. Late last month one of the hypervisors at OVH died, they replaced hardware but the server is having issues so hasn't come up yet. So for all matters, one master-replica is dead. The original master was configured with letsencrypt-freeipa which failed to renew certificates. There are around 10 clients connected to it, and several services authenticate against it. One for example is Gitlab, but I am still able to login to Gitlab. Another example we have a number of pfSense routers that also use LDAP auth and that always fails we had to fallback to the local admin user. One of the most critical services is the DNS. When DNS goes down, everything goes down, including email. This is currently one of the most critical services. ipactl always fails. I have to manually start the services using systemctl, like `systemctl start {named-pkcs11,httpd,ipa-custodia,ipa-dnskeysyncd,ipa-ods-exporter,ods-enforcerd,krb5kdc,kadmin}` getcert list returns 7 certificates, all MONITORING, none expired. # getcert list -d /etc/httpd/alias -n ipaCert No request found that matched arguments. I can run ldap commands on the cli. ALL ipa commands fail: # ipa userlist ipa: ERROR: cannot connect to 'any of the configured servers': https://main.domain.io/ipa/json, https://secondary.domain.io/ipa/json # certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI DSTRootCAX3 C,, CN=main.domain.io u,u,u letsencryptx3 C,, letsencryptx3 C,, ISRGRootCAX1 C,, DOMAIN.IO IPA CA CT,C, the ipa-cert-fix command with increased verbosity: ``` ipapython.ipautil: DEBUG: stderr= ipapython.ipautil: DEBUG: Starting external process ipapython.ipautil: DEBUG: args=/usr/bin/certutil -d dbm:/etc/pki/pki-tomcat/alias -L -n transportCert cert-pki-kra -a -f /etc/pki/pki-tomcat/alias/pwdfile.txt ipapython.ipautil: DEBUG: Process finished, return code=255 ipapython.ipautil: DEBUG: stdout= ipapython.ipautil: DEBUG: stderr=certutil: Could not find cert: transportCert cert-pki-kra : PR_FILE_NOT_FOUND_ERROR: File not found ipapython.ipautil: DEBUG: Starting external process ipapython.ipautil: DEBUG: args=/usr/bin/certutil -d dbm:/etc/pki/pki-tomcat/alias -L -n storageCert cert-pki-kra -a -f /etc/pki/pki-tomcat/alias/pwdfile.txt ipapython.ipautil: DEBUG: Process finished, return code=255 ipapython.ipautil: DEBUG: stdout= ipapython.ipautil: DEBUG: stderr=certutil: Could not find cert: storageCert cert-pki-kra : PR_FILE_NOT_FOUND_ERROR: File not found ipapython.ipautil: DEBUG: Starting external process ipapython.ipautil: DEBUG: args=/usr/bin/certutil -d dbm:/etc/pki/pki-tomcat/alias -L -n auditSigningCert cert-pki-kra -a -f /etc/pki/pki-tomcat/alias/pwdfile.txt ipapython.ipautil: DEBUG: Process finished, return code=255 ipapython.ipautil: DEBUG: stdout= ipapython.ipautil: DEBUG: stderr=certutil: Could not find cert: auditSigningCert cert-pki-kra : PR_FILE_NOT_FOUND_ERROR: File not found ipapython.ipautil: DEBUG: Starting external process ipapython.ipautil: DEBUG: args=/usr/bin/certutil -d dbm:/etc/httpd/alias -L -n Server-Cert -a -f /etc/httpd/alias/pwdfile.txt ipapython.ipautil: DEBUG: Process finished, return code=255 ipapython.ipautil: DEBUG: stdout= ipapython.ipautil: DEBUG: stderr=certutil: Could not find cert: Server-Cert : PR_FILE_NOT_FOUND_ERROR: File not found 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/ipaserver/install/ipa_cert_fix.py", line 100, in run certs, extra_certs = expired_certs(now) File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cert_fix.py", line 142, in expired_certs return expired_dogtag_certs(now), expired_ipa_certs(now) File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cert_fix.py", line 191, in expired_ipa_certs cert = db.get_cert('Server-Cert') File "/usr/lib/python2.7/site-packages/ipapython/certdb.py", line 744, in get_cert raise RuntimeError("Failed to get %s" % nickname) ipapython.admintool: DEBUG: The ipa-cert-fix command failed, exception: RuntimeError: Failed to get Server-Cert ipapython.admintool: ERROR: Failed to get Server-Cert ipapython.admintool: ERROR: The ipa-cert-fix command failed. ``` I thought this command was to fix the certificates, so I don't get it why it fails if one certificate is missing. But anyway, can someone PLEASE give me some help I'm not great with certificates and I'm not being able to fix this. If there's a way of creating a new master from start and then importing the data would be nice, but looking at ipa-backup/restore it clearly says it has to be the same server.

3 10

Better way to upgrade IPAServer4.6.4 to 4.6.5 + OS 7.6 to 7.7?
by Karim Bourenane 11 Jun '20

11 Jun '20

Hello Team I have some questions : 1°) I need your help, to find the better way to upgrade my 3 servers linked (replicat). I want to upgrade servers from CentOS 7.6 to CentOS7.7 with update in same time the IPAServer (or separately ?) After searching on Freeipa.org and other site, i find : #ipactl stop #ipa-server-upgrade #ipactl start I not need to delete first the replication link before ? What is the better solution ways ? 2°) Is not better to migrate my IPAServers's to 4.7 or 4.8 version ? Or i need steps too ? Thanks you for your help Best Regard Bien à vous Mr Karim Bourenane +33686464439 +32 493 86 63 54

4 10

IPA web login: 401 "Login failed due to an unknown reason."
by Chris Carr 11 Jun '20

11 Jun '20

We are unable to login to the FreeIPA web console. However, it is able to tell when I use an incorrect password (shows "The password you entered is incorrect.") Also one of the CentOS servers getting ssh login credentials from our ipa server is using my old password (expired several weeks ago.) These lines are from httpd error.log ipa: INFO: 401 Unauthorized: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618) SSL Library Error: -12269 The server has rejected your certificate as expired I've spent quite a bit of time researching the issue. At first I thought it was because a recent upgrade to FreeIPA (CentOS 7) ipa-server-4.6.6-11.el7.centos.x86_64 But when I looked back in /var/log/messages I can see the error(s) appear to have started occurring before the upgrade. from journalctl: Jun 03 22:41:52 ipa.michiganlabs.com systemd[1]: Started IPA key daemon. Jun 03 22:41:54 ipa.michiganlabs.com python2[14471]: GSSAPI client step 1 Jun 03 22:41:54 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: ipa-dnskeysyncd: INFO LDAP bind... Jun 03 22:41:54 ipa.michiganlabs.com python2[14471]: GSSAPI client step 1 Jun 03 22:41:54 ipa.michiganlabs.com python2[14471]: GSSAPI client step 1 Jun 03 22:41:54 ipa.michiganlabs.com python2[14471]: GSSAPI client step 2 Jun 03 22:41:54 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: ipa-dnskeysyncd: INFO Commencing sync process Jun 03 22:41:54 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: ipaserver.dnssec.keysyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BIND Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: GSSAPI client step 1 Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: GSSAPI client step 1 Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: GSSAPI client step 1 Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: ObjectStore.cpp(59): Failed to enumerate object store in /var/lib/softhsm/tokens/ Jun 03 22:41:55 ipa.michiganlabs.com python2[14481]: SoftHSM.cpp(476): Could not load the object store Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: Traceback (most recent call last): Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 116, in <module> Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_poll Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: self.syncrepl_refreshdone() Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 126, in syncrepl_refreshdon Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: self.hsm_replica_sync() Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 192, in hsm_replica_sync Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 563, in run Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: raise CalledProcessError(p.returncode, arg_string, str(output)) Jun 03 22:41:55 ipa.michiganlabs.com ipa-dnskeysyncd[14471]: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit Jun 03 22:41:55 ipa.michiganlabs.com systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILURE Jun 03 22:41:55 ipa.michiganlabs.com systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. Jun 03 22:41:55 ipa.michiganlabs.com systemd[1]: ipa-dnskeysyncd.service failed. Jun 03 22:42:55 ipa.michiganlabs.com systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling restart. Jun 03 22:42:55 ipa.michiganlabs.com systemd[1]: Stopped IPA key daemon. possibly relevant output of > getcert list -c IPA Number of certificates and requests being tracked: 8. Request ID '20170928130908': status: CA_UNCONFIGURED ca-error: Unable to determine principal name for signing request. stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IPA-MICHIGANLABS-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IPA-MICHIGANLABS-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IPA-MICHIGANLABS-COM',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IPA-MICHIGANLABS-COM track: yes auto-renew: yes possibly relevant SELinux info: > ausearch -m AVC,USER_AVC -ts recent type=PROCTITLE msg=audit(1591756304.759:2543): proctitle=2F7573722F62696E2F707974686F6E32002F7573722F6C6962657865632F6970612F6970612D646E736B657973796E632D7265706C696361 type=SYSCALL msg=audit(1591756304.759:2543): arch=c000003e syscall=257 success=no exit=-13 a0=ffffffffffffff9c a1=de4478 a2=90800 a3=0 items=0 ppid=22017 pid=22027 auid=4294967295 uid=994 gid=25 euid=994 suid=994 fsuid=994 egid=25 sgid=25 fsgid=25 tty=(none) ses=4294967295 comm="ipa-dnskeysync-" exe="/usr/bin/python2.7" subj=system_u:system_r:ipa_dnskey_t:s0 key=(null) type=AVC msg=audit(1591756304.759:2543): avc: denied { read } for pid=22027 comm="ipa-dnskeysync-" name="tokens" dev="dm-6" ino=1373802 scontext=system_u:system_r:ipa_dnskey_t:s0 tcontext=system_u:object_r:named_cache_t:s0 tclass=dir permissive=0 output of > 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 ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful NOTE: it hangs for like at least 30 seconds when trying to display "ipa-dnskeysyncd Service: RUNNING" This server was setup slightly less than two years ago using this as a basis of instructions: https://www.digitalocean.com/community/tutorials/how-to-set-up-centralized-… Also there was this note: "ipa.michiganlabs.com - Delegate ipa. dns to FreeIPA server" Thanks for any assistance

2 1

External users report being member of a lot of groups
by TOULMONDE Sébastien (NBU/MST) 11 Jun '20

11 Jun '20

Hi - I have an IPA setup (4.6.6) with a trust to AD servers. The users can login to the servers via ssh and everything is allowed via HBAC groups. I have some users that are admins so I created an all-servers access group. But when I issue the "id" or "groups" command, users are reported being member of groups they don't belong to, for example: User id094844 (an external user in AD), is reported member of: [root@el6983 ~]# id id094844 | tr ',' '\n' | grep acc 1856201464(acc-devredhat-hbac-usergroup(a)dev.ipa.bc) 1856233001(acc-el2720-hbac-usergroup(a)dev.ipa.bc) 1856230575(acc-el2740-hbac-usergroup(a)dev.ipa.bc) 1856231052(acc-el2741-hbac-usergroup(a)dev.ipa.bc) [...] But if I check the group membership of acc-el2740-hbac-usergroup (my POSIX group): [root@el6983 ~]# ipa group-show acc-el2740-hbac-usergroup Group name: acc-el2740-hbac-usergroup GID: 1856230575 Member users: id999026 Member groups: acc-el2740-hbac-usergroup-ext, ai-it_rpa_accesses, cmos, is-storage_backup_bo, is-storage_backup_fo Member of HBAC rule: acc-el2740-hbac Indirect Member users: abiaload, abidload Indirect Member groups: ai-it_rpa_accesses-extgrp, is-storage_backup_fo-extgrp, is-storage_backup_bo-extgrp, cmos- extgrp # Checking my external group: [root@el6983 ~]# ipa group-show acc-el2740-hbac-usergroup-ext Group name: acc-el2740-hbac-usergroup-ext Member of groups: acc-el2740-hbac-usergroup Indirect Member of HBAC rule: acc-el2740-hbac And id094844 isn't member of any groups nested in acc-el2740-hbac-usergroup As we have a lot of servers, I'm afraid that we'll get a lot of membership once our migration is over... Any way to fix this? Thanks! Sébastien Toulmonde Linux Engineering | ITS Linux CC [Proximus]<http://www.proximus.be/> Connect with us on: [Proximus Facebook]<https://www.facebook.com/proximusBe> [Proximus Twitter] <https://twitter.com/proximus> [Proximus YouTube] <https://www.youtube.com/proximus> [Proximus LinkedIn] <https://www.linkedin.com/company/proximus> 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users June 2020