September 2019 - FreeIPA-users - Fedora mailing-lists

Resilience when accessing CA
by Dmitry Perets 12 Sep '19

12 Sep '19

Hi, In several scenarios when CA must be accessed, I face issues with the algorithm to select IPA server running CA. Wanted to check if there is an easy solution in place that I am missing... For example, if I run "ipa vault-retrieve" on IPA server that doesn't run CA/KRA, it will forward the request to another IPA server. But how will it choose one? From my tests, looks like the algorithm is: - If "ca_host" is defined in /etc/ipa/default.conf, use that IPA server - If it's not defined, fallback to LDAP lookup - query "cn=masters,cn=ipa,cn=etc,<base-dn>" for servers that have KRA and... choose the first result. So the problem is that neither of these two methods is redundant. If the chosen IPA server is down, it just fails, it doesn't try the others. Is there any solution for this? I thought it was specific to Vault access, but I discovered the same thing when I simply do "ipa host-disable" for some host. Seems that also in this case there is a need to access CA, so the IPA server applies the same algorithm as above - so it looks. And again, no redundancy. If it cannot reach the chosen IPA server, it won't try any other. Can you confirm that the algorighm is as described above? Or am I missing anything? Thanks. --- Regards, Dmitry Perets

2 2

ipausers unable to sudo
by Albert Szostkiewicz 10 Sep '19

10 Sep '19

Hi! I've reinstalled ipa-client on a workstation and for some reason now ipa users are not part of sudoers File `/etc/nsswitch.conf` contains `sudoers: files sss` File '/etc/sssd/sssd.conf' contains `[sssd] services = nss, pam, ssh, sudo, autofs` There is no 'sudo_provider' within sssd.conf I've tried to go through provided troubleshooting guide but even seeing discrepancies, I am not sure what should i do about it. Here are snippets of what troubleshooting was suggesting to look for: [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 default options for [myipauser@home.mydomain.com@home.mydomain.com] [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [myipauser@home.mydomain.com@home.mydomain.com] [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=myipauser@home.mydomain.com)(sudoUser=#1907400001)(sudoUser=%editors@home.mydomain.com)(sudoUser=%trust\20admins@home.mydomain.com)(sudoUser=%admins@home.mydomain.com)(sudoUser=%ipausers@home.mydomain.com)(sudoUser=%mymaingroup@home.mydomain.com)(sudoUser=%gogs_users@home.mydomain.com)(sudoUser=%admins@home.mydomain.com))))] # record 28 dn: name=su,cn=hbac_services,cn=custom,cn=home.mydomain.com,cn=sysdb # record 29 dn: name=myipauser(a)home.mydomain.com,cn=users,cn=home.mydomain.com,cn=sysdb [sdap_search_bases_ex_done] (0x0400): Receiving data from base [cn=sudo,dc=home,dc=mydomain,dc=com] [sssd[be[home.mydomain.com]]] [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules [sysdb_sudo_store_rule] (0x0400): Adding sudo rule All [sssd[be[home.mydomain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipasudocmdgrp)(entryUSN>=24976))][cn=sudo,dc=home,dc=mydomain,dc=com]. I do not have '[sdap_sudo_refresh_load_done]' within sssd_$domain.log > ldapsearch -x -H ldap://ipaserver.home.mydomain.com -b dc=ipaserver,dc=home,dc=mydomain,dc=com '$filter' # extended LDIF # # LDAPv3 # base <dc=ipaserver,dc=home,dc=mydomain,dc=com> with scope subtree # filter: (objectclass=*) # requesting: $filter # # search result search: 2 result: 0 Success # numResponses: 1 > ldapsearch -x -D "cn=Directory Manager" -w "$password" -H ldap://ipaserver.home.mydomain.com -b dc=ipaserver,dc=home,dc=mydomain,dc=com '$filter' ldap_bind: Server is unwilling to perform (53) additional info: Unauthenticated binds are not allowed > ldapsearch -Y GSSAPI -H ldap://ipaserver.home.mydomain.com -b dc=ipaserver,dc=home,dc=mydomain,dc=com '$filter' SASL/GSSAPI authentication started SASL username: host/myworkstation.home.mydomain.com(a)HOME.MYDOMAIN.COM SASL SSF: 256 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=ipaserver,dc=home,dc=mydomain,dc=com> with scope subtree # filter: (objectclass=*) # requesting: $filter # # search result search: 4 result: 0 Success # numResponses: 1 sudo[411] -> sudo_parseln_v2 @ ./parseln.c:59 sudo[411] <- sudo_parseln_v2 @ ./parseln.c:129 := 0 sudo[411] <- sudo_sss_open @ ./sssd.c:628 := 0 sudo[411] Looking for cn=default sudo[411] Received 0 rule(s) Any help would be appreciated! Cheers!

3 5

Issues with config between FreeIPA and Dell EMC Unity NAS server
by Kevin Vasko 10 Sep '19

10 Sep '19

I’m trying to integrate the “NAS Server” on our Dell EMC Unity with our FreeIPA server so we can secure our NFS shares. Our FreeIPA server is run of the mill setup. We don’t have any special configuration. The Dell EMC Box NAS configuration settings is asking for the following. Realm: KDC Servers: Port: Base DN: Custom Principal: Custom Principal password: Keytab You can get a better visual from these screenshots. https://imgur.com/a/H6pWemL Info about the environment (I switched example.com from our regular domain but it’s a direct replacement). ny.example.com is my main domain/realm (e.g. NY.EXAMPLE.COM) My other domain is la.example.com. My KDC (IPA servers) are ipa.ny.example.com and ipa.la.example.com, they are replicas. The Dell EMC Unity NAS server I’m setting up will be nfssrv.la.example.com. So this is what I did. In FreeIPA I create a new host manually through the gui. Principle alias: nfssrv.la.example.com(a)NY.EXAMPLE.COM I then created a new service with that host through the gui nfs/nfssrv.la.example.com(a)NY.EXAMPLE.COM I then went into the freeIPA server and generated a keytab "ipa-getkeytab -s ipa.ny.example.com -p nfs/nfssrv.la.example.com(a)NY.EXAMPLE.COM -k /tmp/nfssrv.keytab -P <entered passwd>" The principal in the ipa-getkeytab command and the password I supplied to the ipa-getkeytab command is what I supplied in the Dell EMC Unity dialogs. However, when I do all of this, I keep getting errors in the Dell EMC Unity log stating “In the NAS server nfssrv.la.example.com, ONE LDAP server for Domain ny.example.com goes back from failure.” “LDAP client settings on NAS server nfssrv.la.example.com are not valid within domain ny.example.com”. So the questions I have are. 1) Am I generating the keytab appropriately? 2) Am I supplying the correct information to the “Specifiy Custom principal” “Principal” fields with the principal of the actual server? 3) The last thing I am unsure about is the “Retrieve Current Schema”. This schema was automatically generated. It states is for the Fedora Directory Service so I assumed that’s was correct since I’m using CentOS with FreeIPA. I haven’t changed anything in the scheme (at least that i’m aware of). Any way to validate this? If anyone can provide any advice/suggestions I would greatly appreciate it. The following is the “Current Schema” listed in the LDAP section. # ----------------------------------------------------------------------------- # This template was automatically generated by the EMC Nas server # - Adjustments could be required to fit your specific LDAP configuration. # - The following setup fits the Fedora Directory service schema. # Containers nss_base_passwd ou=people,dc=ny,dc=example,dc=com nss_base_group ou=group,dc=ny,dc=example,dc=com nss_base_hosts ou=hosts, dc=ny,dc=example,dc=com nss_base_netgroup ou=netgroup,dc=ny,dc=example,dc=com # - The parameter fast_search allows fast search encoding to boost performances with big LDAP repositories. # The parameter is set to 1 by default on this configuration,# Some issue could occurs on Microsoft Active Directory server. # If you encounter some issue on LDAP lookup, set the value of the parameter to 0 fast_search 1 -Kevin

3 7

Re: Cert Issue
by Rob Crittenden 09 Sep '19

09 Sep '19

Randy Morgan wrote: > On 9/9/2019 11:31 AM, Rob Crittenden wrote: >> Randy Morgan via FreeIPA-users wrote: >>> We have been working to solve an expired certificate issue in IPA. >>> There is an open ticket in Red Hat supportCASE 02438518. We have tried >>> many things but so far have had no luck getting the certs to update. >>> Currently the system is running RHEL 8.0 and IPA 4.7.1. >>> >>> pki-server cert-fix -n 'subsystemCert cert-pki-ca' -d >>> /var/lib/pki/pki-tomcat/alias/ -C /root/passwd -vvv >>> INFO: Loading instance: pki-tomcat >>> INFO: Loading instance registry: >>> /etc/sysconfig/pki/tomcat/pki-tomcat/pki-tomcat >>> INFO: Loading password config: /etc/pki/pki-tomcat/password.conf >>> INFO: Loading subsystem: ca >>> INFO: Loading subsystem config: /var/lib/pki/pki-tomcat/ca/conf/CS.cfg >>> INFO: Getting signing cert info for ca from CS.cfg >>> INFO: Getting signing cert info for ca from NSS database >>> INFO: Getting ocsp_signing cert info for ca from CS.cfg >>> INFO: Getting ocsp_signing cert info for ca from NSS database >>> INFO: Getting sslserver cert info for ca from CS.cfg >>> INFO: Getting sslserver cert info for ca from NSS database >>> INFO: Getting subsystem cert info for ca from CS.cfg >>> INFO: Getting subsystem cert info for ca from NSS database >>> INFO: Getting audit_signing cert info for ca from CS.cfg >>> INFO: Getting audit_signing cert info for ca from NSS database >>> INFO: Fixing the following certs: ['ca_ocsp_signing', 'sslserver', >>> 'subsystem', 'ca_audit_signing'] >>> INFO: Stopping the instance to proceed with system cert renewal >>> INFO: Selftests disabled for subsystems: ca >>> INFO: Getting sslserver cert info for ca from CS.cfg >>> INFO: Getting sslserver cert info for ca from NSS database >>> INFO: Trying to create a new temp cert for sslserver. >>> INFO: Generate temp SSL certificate >>> INFO: Getting sslserver cert info for ca from CS.cfg >>> INFO: Getting sslserver cert info for ca from NSS database >>> INFO: CSR for sslserver has been written to >>> /tmp/tmpg_738l5a/sslserver.csr >>> INFO: Getting signing cert info for ca from CS.cfg >>> INFO: Getting signing cert info for ca from NSS database >>> INFO: CA cert written to /tmp/tmpg_738l5a/ca_certificate.crt >>> INFO: AKI: 0x1D0F356A3E7A6968A231723231EB22DA5A01F542 >>> INFO: Temp cert for sslserver is available at >>> /etc/pki/pki-tomcat/certs/sslserver.crt. >>> INFO: Getting sslserver cert info for ca from CS.cfg >>> INFO: Getting sslserver cert info for ca from NSS database >>> INFO: Getting sslserver cert info for ca from CS.cfg >>> INFO: Getting sslserver cert info for ca from NSS database >>> INFO: Updating CS.cfg with the new certificate >>> INFO: Getting ocsp_signing cert info for ca from CS.cfg >>> INFO: Getting ocsp_signing cert info for ca from NSS database >>> INFO: Trying to setup a secure connection to CA subsystem. >>> INFO: Secure connection with CA is established. >>> INFO: Placing cert creation request for serial: 49 >>> Traceback (most recent call last): >>> File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", >>> line 600, in urlopen >>> chunked=chunked) >>> File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", >>> line 343, in _make_request >>> self._validate_conn(conn) >>> File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", >>> line 849, in _validate_conn >>> conn.connect() >>> File "/usr/lib/python3.6/site-packages/urllib3/connection.py", >>> line 356, in connect >>> ssl_context=context) >>> File "/usr/lib/python3.6/site-packages/urllib3/util/ssl_.py", line >>> 350, in ssl_wrap_socket >>> context.load_cert_chain(certfile, keyfile) >>> ssl.SSLError: [X509: KEY_VALUES_MISMATCH] key values mismatch >>> (_ssl.c:3550) >>> >>> During handling of the above exception, another exception occurred: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python3.6/site-packages/requests/adapters.py", line >>> 449, in send >>> timeout=timeout >>> File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", >>> line 638, in urlopen >>> _stacktrace=sys.exc_info()[2]) >>> File "/usr/lib/python3.6/site-packages/urllib3/util/retry.py", >>> line 398, in increment >>> raise MaxRetryError(_pool, url, error or ResponseError(cause)) >>> urllib3.exceptions.MaxRetryError: >>> HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries >>> exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal >>> (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] >>> key values mismatch (_ssl.c:3550)'),)) >>> >>> During handling of the above exception, another exception occurred: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python3.6/site-packages/pki/server/pkiserver.py", >>> line 119, in <module> >>> cli.execute(sys.argv) >>> File "/usr/lib/python3.6/site-packages/pki/server/pkiserver.py", >>> line 111, in execute >>> super(PKIServerCLI, self).execute(args) >>> File "/usr/lib/python3.6/site-packages/pki/cli/__init__.py", line >>> 204, in execute >>> module.execute(module_args) >>> File "/usr/lib/python3.6/site-packages/pki/cli/__init__.py", line >>> 204, in execute >>> module.execute(module_args) >>> File "/usr/lib/python3.6/site-packages/pki/server/cli/cert.py", >>> line 1154, in execute >>> renew=True) >>> File "/usr/lib/python3.6/site-packages/pki/server/__init__.py", >>> line 1709, in cert_create >>> PKIServer.renew_certificate(connection, new_cert_file, serial) >>> File "/usr/lib/python3.6/site-packages/pki/server/__init__.py", >>> line 202, in renew_certificate >>> ret = cert_client.enroll_cert(inputs=inputs, >>> profile_id='caManualRenewal') >>> File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, >>> in handler >>> return fn_call(inst, *args, **kwargs) >>> File "/usr/lib/python3.6/site-packages/pki/cert.py", line 1011, in >>> enroll_cert >>> enroll_request = self.create_enrollment_request(profile_id, inputs) >>> File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, >>> in handler >>> return fn_call(inst, *args, **kwargs) >>> File "/usr/lib/python3.6/site-packages/pki/cert.py", line 962, in >>> create_enrollment_request >>> enrollment_template = self.get_enrollment_template(profile_id) >>> File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, >>> in handler >>> return fn_call(inst, *args, **kwargs) >>> File "/usr/lib/python3.6/site-packages/pki/cert.py", line 942, in >>> get_enrollment_template >>> r = self.connection.get(url, self.headers) >>> File "/usr/lib/python3.6/site-packages/pki/client.py", line 46, in >>> wrapper >>> return func(self, *args, **kwargs) >>> File "/usr/lib/python3.6/site-packages/pki/client.py", line 160, >>> in get >>> timeout=timeout, >>> File "/usr/lib/python3.6/site-packages/requests/sessions.py", line >>> 537, in get >>> return self.request('GET', url, **kwargs) >>> File "/usr/lib/python3.6/site-packages/requests/sessions.py", line >>> 524, in request >>> resp = self.send(prep, **send_kwargs) >>> File "/usr/lib/python3.6/site-packages/requests/sessions.py", line >>> 637, in send >>> r = adapter.send(request, **kwargs) >>> File "/usr/lib/python3.6/site-packages/requests/adapters.py", line >>> 514, in send >>> raise SSLError(e, request=request) >>> requests.exceptions.SSLError: >>> HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries >>> exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal >>> (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] >>> key values mismatch (_ssl.c:3550)'),)) >>> ERROR: HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max >>> retries exceeded with url: >>> /ca/rest/certrequests/profiles/caManualRenewal (Caused by >>> SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] key values >>> mismatch (_ssl.c:3550)'),)) >>> >>> [root@ipa2 ~]# echo "--Certificate:" && openssl x509 -noout -modulus -in >>> /var/lib/ipa/ra-agent.pem && echo "--Key:" && openssl rsa -noout >>> -modulus -in /var/lib/ipa/ra-agent.key >>> --Certificate: >>> Modulus=CBA68178847F53CC0D4A45871FEA7CCFD879D6423923DF75E557011E4C458BD5207ACBB4EAFC7A460C050878621E22406E7661105F7D8E7AF448AA1F0988C908F3173B77D87581BE7006ED09F76F0D4D736050088E986133DE851A0FB93A101AA77921CC24063A94E5076FD74D4D81139E7A2AAC61B86D07D424158CE56913ABB08C1CDBDAE35CE2D7BCEB9EF9D5A909FFF502A02E1E847DC44E8672A8889A65A721DC78FE70C24D9E12BB4E88D7AD0A49948E2BF40A22431731872ADFC3B81E368C655EB9B00DC37D04526EE2917445D2FAEBCF116821486FF088E500F12128A8D90309E8ED275CDD48E77BDE0E3358A6A81BD9DD2AD5AC6F68315C96FC50E9 >>> >>> --Key: >>> Modulus=CBA68178847F53CC0D4A45871FEA7CCFD879D6423923DF75E557011E4C458BD5207ACBB4EAFC7A460C050878621E22406E7661105F7D8E7AF448AA1F0988C908F3173B77D87581BE7006ED09F76F0D4D736050088E986133DE851A0FB93A101AA77921CC24063A94E5076FD74D4D81139E7A2AAC61B86D07D424158CE56913ABB08C1CDBDAE35CE2D7BCEB9EF9D5A909FFF502A02E1E847DC44E8672A8889A65A721DC78FE70C24D9E12BB4E88D7AD0A49948E2BF40A22431731872ADFC3B81E368C655EB9B00DC37D04526EE2917445D2FAEBCF116821486FF088E500F12128A8D90309E8ED275CDD48E77BDE0E3358A6A81BD9DD2AD5AC6F68315C96FC50E9 >>> >>> [root@ipa2 ~]# openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key >>> | openssl md5 >>> (stdin)= 0915781edbe620c5791cda50f310c538 >>> [root@ipa2 ~]# openssl x509 -noout -modulus -in >>> /var/lib/ipa/ra-agent.pem | openssl md5 >>> (stdin)= 0915781edbe620c5791cda50f310c538 >>> >>> Looking at the cert and the key, they are a match and modulus also >>> matches. What I can't figure out is why I am seeing this error if the >>> key and cert match. Is it possible to have a timestamp issue, or is >>> there some other reason that I can't find. Any help would be greatly >>> appreciated. >> I'm not familiar with this command but based on the options you are >> passing you compared the wrong cert. You compared the RA agent cert and >> you asked to renew the subsystem cert. >> >> You might want to see what cert owns serial number 49. >> >> rob > > > The reason these are the two compared is that there are no other keys on > the server. Looking through the documentation seems to indicate that > all certs are generated from this key pair. Is that not correct, and if > it is not correct then where are the keys located for the other certs, I > have been unable to locate them anywhere on the server. The certs and keys are stored in the NSS database in /etc/pki/pki-tomcat/alias/ rob

1 0

Cert Issue
by Randy Morgan 09 Sep '19

09 Sep '19

We have been working to solve an expired certificate issue in IPA. There is an open ticket in Red Hat supportCASE 02438518. We have tried many things but so far have had no luck getting the certs to update. Currently the system is running RHEL 8.0 and IPA 4.7.1. pki-server cert-fix -n 'subsystemCert cert-pki-ca' -d /var/lib/pki/pki-tomcat/alias/ -C /root/passwd -vvv INFO: Loading instance: pki-tomcat INFO: Loading instance registry: /etc/sysconfig/pki/tomcat/pki-tomcat/pki-tomcat INFO: Loading password config: /etc/pki/pki-tomcat/password.conf INFO: Loading subsystem: ca INFO: Loading subsystem config: /var/lib/pki/pki-tomcat/ca/conf/CS.cfg INFO: Getting signing cert info for ca from CS.cfg INFO: Getting signing cert info for ca from NSS database INFO: Getting ocsp_signing cert info for ca from CS.cfg INFO: Getting ocsp_signing cert info for ca from NSS database INFO: Getting sslserver cert info for ca from CS.cfg INFO: Getting sslserver cert info for ca from NSS database INFO: Getting subsystem cert info for ca from CS.cfg INFO: Getting subsystem cert info for ca from NSS database INFO: Getting audit_signing cert info for ca from CS.cfg INFO: Getting audit_signing cert info for ca from NSS database INFO: Fixing the following certs: ['ca_ocsp_signing', 'sslserver', 'subsystem', 'ca_audit_signing'] INFO: Stopping the instance to proceed with system cert renewal INFO: Selftests disabled for subsystems: ca INFO: Getting sslserver cert info for ca from CS.cfg INFO: Getting sslserver cert info for ca from NSS database INFO: Trying to create a new temp cert for sslserver. INFO: Generate temp SSL certificate INFO: Getting sslserver cert info for ca from CS.cfg INFO: Getting sslserver cert info for ca from NSS database INFO: CSR for sslserver has been written to /tmp/tmpg_738l5a/sslserver.csr INFO: Getting signing cert info for ca from CS.cfg INFO: Getting signing cert info for ca from NSS database INFO: CA cert written to /tmp/tmpg_738l5a/ca_certificate.crt INFO: AKI: 0x1D0F356A3E7A6968A231723231EB22DA5A01F542 INFO: Temp cert for sslserver is available at /etc/pki/pki-tomcat/certs/sslserver.crt. INFO: Getting sslserver cert info for ca from CS.cfg INFO: Getting sslserver cert info for ca from NSS database INFO: Getting sslserver cert info for ca from CS.cfg INFO: Getting sslserver cert info for ca from NSS database INFO: Updating CS.cfg with the new certificate INFO: Getting ocsp_signing cert info for ca from CS.cfg INFO: Getting ocsp_signing cert info for ca from NSS database INFO: Trying to setup a secure connection to CA subsystem. INFO: Secure connection with CA is established. INFO: Placing cert creation request for serial: 49 Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 600, in urlopen chunked=chunked) File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 343, in _make_request self._validate_conn(conn) File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 849, in _validate_conn conn.connect() File "/usr/lib/python3.6/site-packages/urllib3/connection.py", line 356, in connect ssl_context=context) File "/usr/lib/python3.6/site-packages/urllib3/util/ssl_.py", line 350, in ssl_wrap_socket context.load_cert_chain(certfile, keyfile) ssl.SSLError: [X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:3550) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 449, in send timeout=timeout File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 638, in urlopen _stacktrace=sys.exc_info()[2]) File "/usr/lib/python3.6/site-packages/urllib3/util/retry.py", line 398, in increment raise MaxRetryError(_pool, url, error or ResponseError(cause)) urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:3550)'),)) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/pki/server/pkiserver.py", line 119, in <module> cli.execute(sys.argv) File "/usr/lib/python3.6/site-packages/pki/server/pkiserver.py", line 111, in execute super(PKIServerCLI, self).execute(args) File "/usr/lib/python3.6/site-packages/pki/cli/__init__.py", line 204, in execute module.execute(module_args) File "/usr/lib/python3.6/site-packages/pki/cli/__init__.py", line 204, in execute module.execute(module_args) File "/usr/lib/python3.6/site-packages/pki/server/cli/cert.py", line 1154, in execute renew=True) File "/usr/lib/python3.6/site-packages/pki/server/__init__.py", line 1709, in cert_create PKIServer.renew_certificate(connection, new_cert_file, serial) File "/usr/lib/python3.6/site-packages/pki/server/__init__.py", line 202, in renew_certificate ret = cert_client.enroll_cert(inputs=inputs, profile_id='caManualRenewal') File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, in handler return fn_call(inst, *args, **kwargs) File "/usr/lib/python3.6/site-packages/pki/cert.py", line 1011, in enroll_cert enroll_request = self.create_enrollment_request(profile_id, inputs) File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, in handler return fn_call(inst, *args, **kwargs) File "/usr/lib/python3.6/site-packages/pki/cert.py", line 962, in create_enrollment_request enrollment_template = self.get_enrollment_template(profile_id) File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, in handler return fn_call(inst, *args, **kwargs) File "/usr/lib/python3.6/site-packages/pki/cert.py", line 942, in get_enrollment_template r = self.connection.get(url, self.headers) File "/usr/lib/python3.6/site-packages/pki/client.py", line 46, in wrapper return func(self, *args, **kwargs) File "/usr/lib/python3.6/site-packages/pki/client.py", line 160, in get timeout=timeout, File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 537, in get return self.request('GET', url, **kwargs) File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 524, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 637, in send r = adapter.send(request, **kwargs) File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 514, in send raise SSLError(e, request=request) requests.exceptions.SSLError: HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:3550)'),)) ERROR: HTTPSConnectionPool(host='ipa2.chem.byu.edu', port=8443): Max retries exceeded with url: /ca/rest/certrequests/profiles/caManualRenewal (Caused by SSLError(SSLError(185073780, '[X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:3550)'),)) [root@ipa2 ~]# echo "--Certificate:" && openssl x509 -noout -modulus -in /var/lib/ipa/ra-agent.pem && echo "--Key:" && openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key --Certificate: Modulus=CBA68178847F53CC0D4A45871FEA7CCFD879D6423923DF75E557011E4C458BD5207ACBB4EAFC7A460C050878621E22406E7661105F7D8E7AF448AA1F0988C908F3173B77D87581BE7006ED09F76F0D4D736050088E986133DE851A0FB93A101AA77921CC24063A94E5076FD74D4D81139E7A2AAC61B86D07D424158CE56913ABB08C1CDBDAE35CE2D7BCEB9EF9D5A909FFF502A02E1E847DC44E8672A8889A65A721DC78FE70C24D9E12BB4E88D7AD0A49948E2BF40A22431731872ADFC3B81E368C655EB9B00DC37D04526EE2917445D2FAEBCF116821486FF088E500F12128A8D90309E8ED275CDD48E77BDE0E3358A6A81BD9DD2AD5AC6F68315C96FC50E9 --Key: Modulus=CBA68178847F53CC0D4A45871FEA7CCFD879D6423923DF75E557011E4C458BD5207ACBB4EAFC7A460C050878621E22406E7661105F7D8E7AF448AA1F0988C908F3173B77D87581BE7006ED09F76F0D4D736050088E986133DE851A0FB93A101AA77921CC24063A94E5076FD74D4D81139E7A2AAC61B86D07D424158CE56913ABB08C1CDBDAE35CE2D7BCEB9EF9D5A909FFF502A02E1E847DC44E8672A8889A65A721DC78FE70C24D9E12BB4E88D7AD0A49948E2BF40A22431731872ADFC3B81E368C655EB9B00DC37D04526EE2917445D2FAEBCF116821486FF088E500F12128A8D90309E8ED275CDD48E77BDE0E3358A6A81BD9DD2AD5AC6F68315C96FC50E9 [root@ipa2 ~]# openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key | openssl md5 (stdin)= 0915781edbe620c5791cda50f310c538 [root@ipa2 ~]# openssl x509 -noout -modulus -in /var/lib/ipa/ra-agent.pem | openssl md5 (stdin)= 0915781edbe620c5791cda50f310c538 Looking at the cert and the key, they are a match and modulus also matches. What I can't figure out is why I am seeing this error if the key and cert match. Is it possible to have a timestamp issue, or is there some other reason that I can't find. Any help would be greatly appreciated. Randy Morgan

2 1

NFS failure after upgrade
by Petros Triantafyllidis 06 Sep '19

06 Sep '19

Hi all, I have a setup with two servers running CenOS 7.6 which I updated recently to ipa-server-4.6.4-10.el7.centos.6.x86_64. The update apparently completed successfully and after that I went through the update of several clients (ipa-client-4.6.4-10.el7.centos.6.x86_64) some of which export kerberized nfs shares. However, after the upgrade, the nfs shares are not accessible neither by other clients nor by servers. I don't know if it's a coincidence, but I can access only shares exported by a non-upgraded client. When trying to mount by hand from server (:fidias) with admin credentials I receive: [root@fidias]# mount -t nfs4 -o sec=krb5 medusa:/export/teras /teras mount.nfs4: access denied by server while mounting medusa:/export/teras [root@fidias]# ipa-getkeytab -r -s fidias.geo.auth.gr -p nfs/medusa.geo.auth.gr -k medusa-nfs.keytab Failed to parse result: Insufficient access rights Failed to get keytab [root@fidias]# KRB5_TRACE=/dev/stderr kinit -k -t /etc/krb5.keytab nfs/medusa.geo.auth.gr [26055] 1567693076.930983: Resolving unique ccache of type KEYRING [26055] 1567693076.930984: Getting initial credentials for nfs/medusa.geo.auth.gr(a)GEO.SS.LAN [26055] 1567693076.930985: Looked up etypes in keytab: (empty) [26055] 1567693076.930986: Getting initial credentials for nfs/medusa.geo.auth.gr(a)GEO.SS.LAN [26055] 1567693076.930987: Looked up etypes in keytab: (empty) kinit: Keytab contains no suitable keys for nfs/medusa.geo.auth.gr(a)GEO.SS.LAN while getting initial credentials How can this be fixed? Thanks in advance, Petros -- Dr. TRIANTAFYLLIDIS PETROS Aristotle University - Department of Geophysics, POBox 112, 54124 Thessaloniki,GREECE-TEL:+30-2310998585,FAX:2310991403

2 2

subCA OCSP on IPA Replica
by David Etchen 06 Sep '19

06 Sep '19

Hi Guys, I have a 2 host basic IPA setup both IPA servers are running dns & ca. I'm running on Centos 7.6 using freeipa version 4.6.4 & dogtag version 10.5.9 I've made a subCA called vpnca and a certificate policy and all this is working fine with the exception of OCSP on the 2nd IPA box. The original master works fine and issues OCSP responses for certifcates issued by the vpnca (subCA) however the replica IPA box fails to respond. I've had a look through the logs and found in the /var/log/pki/pki-tomcat/ca/debug log an error on the 2nd box when doing an OCSP request against it for a certificate issued by the subCA. I should note here that OCSP requests for certificates issued by the main IPA CA work fine it's only for ones issued by the subCA on the replica that seem to be broken. I have also spotted the 2nd IPA server complaining that is can't get caSigningCert [04/Sep/2019:13:24:01][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Running ExternalProcessKeyRetriever [04/Sep/2019:13:24:01][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: About to execute command: [/usr/libexec/ipa/ipa-pki-retrieve-key, caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93, man-fb-ipa-01.testhost.com] [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Failed to retrieve key from any host. [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: KeyRetriever did not return a result. [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Retrying in 1946 seconds I'm presuming this is the reason OCSP is failing as it can't sign the response for the subCA? Does anyone know if this is a known issue or if there is something I need to modify to get the OCSP working on the replica host? Any help would be greatly appreciated Thanks Dave See logs below. 2nd IPA Replica (Broken) /var/log/pki/pki-tomcat/ca/debug [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet:service() uri = /ca/ocsp [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: caOCSP start to service. [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: IP: 10.128.164.2 [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: no authMgrName [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.authorize(DirAclAuthz) [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditSubjectID [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.164.2} [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditSubjectID: subjectID: null [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditGroupID [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditGroupID auditContext {locale=en_GB, ipAddress=10.128.164.2} [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditGroupID: groupID: null [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2 [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3 [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: AAclAuthz.checkPermission(certServer.ee.request.ocsp, submit) [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: checkAllowEntries(): expressions: ipaddress=".*" [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: evaluating expressions: ipaddress=".*" [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: evaluated expression: ipaddress=".*" to be true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: DirAclAuthz: authorization passed [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: SignedAuditLogger: event AUTHZ [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: Servlet Path: /ocsp [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: RequestURI: /ca/ocsp [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: PathInfo: null [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: HTTP method: POST [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: processing POST request [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: decoding request [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: validating request [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CertificateAuthority: validating OCSP request [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CertificateAuthority: processing request for cert 0x1b [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3 java.lang.NullPointerException at com.netscape.ca.CertificateAuthority.getResponderIDByName(CertificateAuthority.java:2340) at com.netscape.ca.CertificateAuthority.validate(CertificateAuthority.java:2473) at com.netscape.ca.CertificateAuthority.validate(CertificateAuthority.java:2428) at com.netscape.cms.servlet.ocsp.OCSPServlet.process(OCSPServlet.java:222) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:493) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) 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) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) 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) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) 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) [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditSubjectID [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.164.2} [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditSubjectID: subjectID: null [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: SignedAuditLogger: event OCSP_GENERATION [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: response is null [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.java: renderTemplate [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: curDate=Wed Sep 04 12:25:14 BST 2019 id=caOCSP time=213 If I look at 1st IPA server which is working I see 1st IPA Master (Working) /var/log/pki/pki-tomcat/ca/debug [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet:service() uri = /ca/ocsp [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: caOCSP start to service. [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: IP: 10.128.167.2 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: no authMgrName [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet.authorize(DirAclAuthz) [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditSubjectID [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.167.2} [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditSubjectID: subjectID: null [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditGroupID [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditGroupID auditContext {locale=en_GB, ipAddress=10.128.167.2} [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditGroupID: groupID: null [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn() [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 2 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 3 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: AAclAuthz.checkPermission(certServer.ee.request.ocsp, submit) [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: checkAllowEntries(): expressions: ipaddress=".*" [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: evaluating expressions: ipaddress=".*" [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: evaluated expression: ipaddress=".*" to be true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: DirAclAuthz: authorization passed [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: event AUTHZ [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: Servlet Path: /ocsp [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: RequestURI: /ca/ocsp [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: PathInfo: null [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: HTTP method: POST [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: processing POST request [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: decoding request [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: validating request [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn() [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn() [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CertificateAuthority: validating OCSP request [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CertificateAuthority: processing request for cert 0x1b [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn() [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: adding signature [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Getting algorithm context for SHA256withRSA RSASignatureWithSHA256Digest [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Signing Certificate [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditSubjectID [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.167.2} [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditSubjectID: subjectID: null [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: event OCSP_GENERATION [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Request: [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: MGwwaqADAgEAMD4wPDA6MAkGBSsOAwIaBQAEFK377uGJz9Owh8lyIT07pU1YHAEs^M BBTDA9mf27XJPVL0EOy+SaFKAxCZhAIBG6IjMCEwHwYJKwYBBQUHMAECBBIEEJMj^M ZAn0Vjd91e0eZdmHXyo=^M [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Serial Number: 27 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Response Size: [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: 2364 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Response Data: **SNIP**

2 8

Problems joining an Ubuntu client to IPA server and using AD Credentials
by Jokinen Eemeli 06 Sep '19

06 Sep '19

Hi! I have a problem I could use help on resolving: We have a working IPA Cluster and I try to join in with Ubuntu 16.04 freeipa-client. Everything seems to go smoothly, it creates config files that look just right. However when I try to login with SSH using AD Credentials I've joined the IPA with I can't login and auth.log gives me an error -- Sep 5 15:46:29 testcomputer2 sshd[1907]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<ip> user=<user>@<ad.domain> Sep 5 15:46:29 testcomputer2 sshd[1907]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<ip> user=<user>@<ad.domain> Sep 5 15:46:29 testcomputer2 sshd[1907]: pam_sss(sshd:auth): received for user <user>@<ad.domain>: 4 (System error) Sep 5 15:46:31 testcomputer2 sshd[1907]: Failed password for <user>@<ad.domain> from <ip> port 42416 ssh2 -- Couldn't find anything solid but then I turned on debug levels and looked into krb5_child.log. Our ipadomain is ipa.company.domain but for some reason it tries to find the username from company.domain and of course it can't find the username there. -- (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [<company.domain>] (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.927017: Getting initial credentials for <user>@<company.domain> (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.927076: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_<ipa.company.domain> (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.927109: Retrieving host/testcomputer2.<ipa.company.domain>@<ipa.company.domain> -> krb5_ccache_conf_data/fast_avail/krbtgt\/<company.domain>\@<company.domain>@X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_<ipa.company.domain> with result: -1765328243/Matching credential not found (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.927151: Sending request (172 bytes) to <company.domain> (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938377: Retrying AS request with master KDC (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938418: Getting initial credentials for <user>@<company.domain> (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938442: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_<ipa.company.domain> (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938467: Retrieving host/testcomputer2.<ipa.company.domain>@<ipa.company.domain> -> krb5_ccache_conf_data/fast_avail/krbtgt\/<company.domain>\@<company.domain>@X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_<ipa.company.domain> with result: -1765328243/Matching credential not found (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [sss_child_krb5_trace_cb] (0x4000): [1909] 1567687589.938511: Sending request (172 bytes) to <company.domain> (master) (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [get_and_save_tgt] (0x0020): 1232: [-1765328230][Cannot find KDC for realm "<company.domain>"] (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [map_krb5_error] (0x0020): 1301: [-1765328230][Cannot find KDC for realm "<company.domain>"] (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [pack_response_packet] (0x2000): response packet size: [4] (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [k5c_send_data] (0x4000): Response sent. (Thu Sep 5 15:46:29 2019) [[sssd[krb5_child[1909]]]] [main] (0x0400): krb5_child completed successfully -- Seems like it converts ad.domain to company.domain and not to ipa.company.domain for some reason. But like I said the configuration on /var/lib/sss/pubconf/krb5.include.d seems legit. -- [domain_realm] .<ad.domain> = <AD.DOMAIN> <ad.domain> = <AD.DOMAIN> [capaths] <AD.DOMAIN> = { <IPA.COMPANY.DOMAIN> = <AD.DOMAIN> } <IPA.COMPANY.DOMAIN> = { <AD.DOMAIN> = <AD.DOMAIN> } -- Any ideas why it's dropping the subdomain out? Eemeli

2 8

Certmonger managed certificate signed by sub-ca
by Ben Rawson 05 Sep '19

05 Sep '19

I'm having some trouble getting sub-ca signed certificates issued and managed by certmonger. The implementation here [https://www.freeipa.org/page/V4/Sub-CAs] describes how that should work. I see that the -X option can be passed to ipa-getcert to specify the issuer, but every time I create a request with -X specified I get an error. Steps to reproduce: 1. Create a new CA named "Test" through the FreeIPA web UI. 2. Run the following on a host enrolled in freeIPA: ipa-getcert request -k /root/test.key -f /root/test.crt -I "testrequest" -X "Test" 3. Run ipa-getcert list and receive the an error message: Request ID 'test': status: CA_REJECTED ca-error: Server at https://ipa02.mgmt.crosschx.com/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. ). stuck: yes key pair storage: type=FILE,location='/root/test.key' certificate: type=FILE,location='/root/test.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes Running FreeIPA 4.6.4 Thanks for the help!

1 0

KrbException: Identifier doesn't match expected value (906)
by lune voo 05 Sep '19

05 Sep '19

Hello everyone. I am using a old version of IPA (3.0) on a RHEL6.6. (I know it is old ^_^). I send you this mail because I had a problem during the night during the execution of a spark job. The error which occured was the following : 19/09/05 03:06:01 INFO Client: Application report for <MYAPPLICATION> (state: FINISHED) 19/09/05 03:06:01 INFO Client: client token: N/A diagnostics: N/A ApplicationMaster host: <APPMASTERIP> ApplicationMaster RPC port: 0 queue: <QUEUE> start time: 1567040464637 final status: SUCCEEDED tracking URL: http://<RM_HOST>:<RM_PORT>/proxy/<MYAPPLICATION2>/ user: <myuser> Exception in thread "main" java.io.IOException: Login failure for <myuser> from keytab <LOCAL_PATH_FOR_KEYTAB>/<myuser>.headless.keytab: javax.security.auth.login.LoginException: Generic error (description in e-text) (60) - HANDLE_AUTHDATA at org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytabAndReturnUGI(UserGroupInformation.java:1351) at org.apache.spark.deploy.yarn.Client.cleanupStagingDir(Client.scala:210) at org.apache.spark.deploy.yarn.Client.monitorApplication(Client.scala:1204) at org.apache.spark.deploy.yarn.Client.run(Client.scala:1258) at org.apache.spark.deploy.yarn.Client$.main(Client.scala:1307) at org.apache.spark.deploy.yarn.Client.main(Client.scala) 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.spark.deploy.SparkSubmit$.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:751) at org.apache.spark.deploy.SparkSubmit$.doRunMain$1(SparkSubmit.scala:187) at org.apache.spark.deploy.SparkSubmit$.submit(SparkSubmit.scala:212) at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:126) at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala) Caused by: javax.security.auth.login.LoginException: Generic error (description in e-text) (60) - HANDLE_AUTHDATA at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:804) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) 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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytabAndReturnUGI(UserGroupInformation.java:1340) ... 14 more Caused by: KrbException: Generic error (description in e-text) (60) - HANDLE_AUTHDATA at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:82) at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:316) at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:776) ... 27 more Caused by: KrbException: Identifier doesn't match expected value (906) at sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) at sun.security.krb5.internal.ASRep.init(ASRep.java:64) at sun.security.krb5.internal.ASRep.<init>(ASRep.java:59) at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:60) ... 30 more 19/09/05 03:06:01 INFO ShutdownHookManager: Shutdown hook called The error occurred after the end of a spark job in fact. I was wondering if this kind of error means something for you ? I checked on google and saw the problem could come : 1. from the krb5.conf file 2. from the keytab 3. from the fact that the login of <myuser> is mispelled during the TGT step 4. from the encryption between the client and the server As a note at the beginning of the job, there is a kinit performed on this host and the kinit is OK. So I checked the krb5.conf and it is OK. I checked the keytab file and it is OK. I was wondering if I could see maybe more information on the client side. Do you know where are located the logs on the client side please ? Do you know which logs I could check on server side please ? Best regards. Lune.

1 1

Unable to add external domain global groups
by Martijn Bakkes 04 Sep '19

04 Sep '19

We have a one way trust set up on our IPA with our AD. ( IPA trusting AD ). I am able to add domain local groups as external member is an IPA group. However, when I try to add a domain global group I receive the error: invalid 'trusted domain object': no trusted domain matched the specified flat name Has anybody run in to this issue. I can only find this error referenced in cases where the trust wasn't working.

3 20

Re: kadmin service fails to start
by Mike Conner 04 Sep '19

04 Sep '19

Thanks for the reply. I ran `nestat -tulpn` after restarting the rpcbind service and did not see anything listening on 749. Unfortunately, I didn't think to run it before I restarted the rpcbind service. Is it possible kadmin think the port is in use even after rpcbind has moved off it?

2 1

subCA OCSP on IPA Replica
by David Etchen 04 Sep '19

04 Sep '19

Hi Guys, I have a 2 host basic IPA setup both IPA servers are running dns & ca. I'm running on Centos 7.6 using freeipa version 4.6.4 & dogtag version 10.5.9 I've made a subCA called vpnca and a certificate policy and all this is working fine with the exception of OCSP on the 2nd IPA box. The original master works fine and issues OCSP responses for certifcates issued by the vpnca (subCA) however the replica IPA box fails to respond. I've had a look through the logs and found in the /var/log/pki/pki-tomcat/ca/debug log an error on the 2nd box when doing an OCSP request against it for a certificate issued by the subCA. I should note here that OCSP requests for certificates issued by the main IPA CA work fine it's only for ones issued by the subCA on the replica that seem to be broken. I have also spotted the 2nd IPA server complaining that is can't get caSigningCert [04/Sep/2019:13:24:01][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Running ExternalProcessKeyRetriever [04/Sep/2019:13:24:01][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: About to execute command: [/usr/libexec/ipa/ipa-pki-retrieve-key, caSigningCert cert-pki-ca dd4ea812-c044-41c0-93bf-ec376c732c93, man-fb-ipa-01.testhost.com] [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Failed to retrieve key from any host. [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: KeyRetriever did not return a result. [04/Sep/2019:13:24:02][KeyRetrieverRunner-dd4ea812-c044-41c0-93bf-ec376c732c93]: Retrying in 1946 seconds I'm presuming this is the reason OCSP is failing as it can't sign the response for the subCA? Does anyone know if this is a known issue or if there is something I need to modify to get the OCSP working on the replica host? Any help would be greatly appreciated Thanks Dave See logs below. 2nd IPA Replica (Broken) /var/log/pki/pki-tomcat/ca/debug [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet:service() uri = /ca/ocsp [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: caOCSP start to service. [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: IP: 10.128.164.2 [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: no authMgrName [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.authorize(DirAclAuthz) [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditSubjectID [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.164.2} [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditSubjectID: subjectID: null [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditGroupID [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditGroupID auditContext {locale=en_GB, ipAddress=10.128.164.2} [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditGroupID: groupID: null [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2 [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3 [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: AAclAuthz.checkPermission(certServer.ee.request.ocsp, submit) [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: checkAllowEntries(): expressions: ipaddress=".*" [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: evaluating expressions: ipaddress=".*" [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: evaluated expression: ipaddress=".*" to be true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: DirAclAuthz: authorization passed [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: SignedAuditLogger: event AUTHZ [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: Servlet Path: /ocsp [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: RequestURI: /ca/ocsp [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: PathInfo: null [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: HTTP method: POST [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: processing POST request [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: decoding request [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: validating request [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [04/Sep/2019:12:25:13][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CertificateAuthority: validating OCSP request [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CertificateAuthority: processing request for cert 0x1b [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: In LdapBoundConnFactory::getConn() [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: masterConn is connected: true [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: conn is connected true [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: getConn: mNumConns now 2 [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: returnConn: mNumConns now 3 java.lang.NullPointerException at com.netscape.ca.CertificateAuthority.getResponderIDByName(CertificateAuthority.java:2340) at com.netscape.ca.CertificateAuthority.validate(CertificateAuthority.java:2473) at com.netscape.ca.CertificateAuthority.validate(CertificateAuthority.java:2428) at com.netscape.cms.servlet.ocsp.OCSPServlet.process(OCSPServlet.java:222) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:493) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) 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) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) 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) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) 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) [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: in auditSubjectID [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.164.2} [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet auditSubjectID: subjectID: null [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: SignedAuditLogger: event OCSP_GENERATION [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: OCSPServlet: response is null [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet.java: renderTemplate [04/Sep/2019:12:25:14][ajp-bio-127.0.0.1-8009-exec-1]: CMSServlet: curDate=Wed Sep 04 12:25:14 BST 2019 id=caOCSP time=213 If I look at 1st IPA server which is working I see 1st IPA Master (Working) /var/log/pki/pki-tomcat/ca/debug [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet:service() uri = /ca/ocsp [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: caOCSP start to service. [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: IP: 10.128.167.2 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: no authMgrName [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet.authorize(DirAclAuthz) [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditSubjectID [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.167.2} [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditSubjectID: subjectID: null [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditGroupID [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditGroupID auditContext {locale=en_GB, ipAddress=10.128.167.2} [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditGroupID: groupID: null [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn() [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 2 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 3 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: AAclAuthz.checkPermission(certServer.ee.request.ocsp, submit) [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: checkAllowEntries(): expressions: ipaddress=".*" [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: evaluating expressions: ipaddress=".*" [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: evaluated expression: ipaddress=".*" to be true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: DirAclAuthz: authorization passed [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: event AUTHZ [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: Servlet Path: /ocsp [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: RequestURI: /ca/ocsp [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: PathInfo: null [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: HTTP method: POST [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: processing POST request [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: decoding request [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: validating request [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn() [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn() [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CertificateAuthority: validating OCSP request [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CertificateAuthority: processing request for cert 0x1b [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn() [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 4 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 5 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: adding signature [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Getting algorithm context for SHA256withRSA RSASignatureWithSHA256Digest [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Signing Certificate [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: in auditSubjectID [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet: auditSubjectID auditContext {locale=en_GB, ipAddress=10.128.167.2} [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: CMSServlet auditSubjectID: subjectID: null [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: event OCSP_GENERATION [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Request: [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: MGwwaqADAgEAMD4wPDA6MAkGBSsOAwIaBQAEFK377uGJz9Owh8lyIT07pU1YHAEs^M BBTDA9mf27XJPVL0EOy+SaFKAxCZhAIBG6IjMCEwHwYJKwYBBQUHMAECBBIEEJMj^M ZAn0Vjd91e0eZdmHXyo=^M [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: Serial Number: 27 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Response Size: [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: 2364 [04/Sep/2019:13:22:06][ajp-bio-127.0.0.1-8009-exec-15]: OCSPServlet: OCSP Response Data: **SNIP**

1 0

kadmin service fails to start
by Mike Conner 04 Sep '19

04 Sep '19

I've had a FreeIPA installation running without issues until today directory services went down and when I attempt to restart services using `ipactl restart` the kadmin service fails to start. I've been digging through logs and searching for answers but haven't found anything that makes sense to me. The only change I introduced (that I'm aware of) was that I upgraded ipa-server on the replica a week or two ago. Master is running IPA 4.5 and replica is running IPA 4.6. Any help with troubleshooting would be greatly appreciated. -Mike

2 3

ldapsearch for AD users via FreeIPA
by Tom K. 03 Sep '19

03 Sep '19

Hey All, I've been following this post to refine an ldapsearch query in an attempt to return a list of AD users via IPA: https://www.redhat.com/archives/freeipa-users/2017-February/msg00300.html But haven't had luck yet. What I've tried so far: LDAPTLS_CACERT=/etc/ipa/ca.crt ldapsearch -H ldaps://idmipa03.mws.mds.xyz:636 -D "uid=admin,cn=users,cn=accounts,dc=mws,dc=mds,dc=xyz" -w "<SECRET>" -b "dc=mws,dc=mds,dc=xyz" -v "(&(objectClass=posixAccount)(uid=*))" |grep dn: [root@idmipa03 ~]# cat ad-lookup.update dn:cn=users,cn=Schema Compatibility,cn=plugins,cn=config add:schema-compat-lookup-nsswitch: user dn:cn=groups,cn=Schema Compatibility,cn=plugins,cn=config add:schema-compat-lookup-nsswitch: group [root@idmipa03 ~]# [root@idmipa03 ~]# [root@idmipa03 ~]# ipa-compat-manage status Directory Manager password: Plugin Enabled [root@idmipa03 ~]# [root@idmipa03 ~]# [root@idmipa03 ~]# ipa-ldap-updater ad-lookup.update Update complete, no data were modified The ipa-ldap-updater command was successful [root@idmipa03 ~]# Still I don't get a list of AD users. Did not use --enable-compat on installation of the IPA servers. What am I missing? -- Thx, TK.

2 2

'ipa-ca' DNS record - where used?
by Dmitry Perets 02 Sep '19

02 Sep '19

Hi, I know of one usage - all the IPA ansible modules (ipa_*) query for 'ipa-ca' record to find the IPA server. But for other cases - looks like IPA clients mostly rely on entries like '_kerberos.*' and '_ldap.*'... What other functionality uses 'ipa-ca' record? Thanks. --- Regards, Dmitry Perets

3 3

spake_preauth_groups
by Rob Verduijn 02 Sep '19

02 Sep '19

Hello, I found out that running ipa on rhel8 in the file /etc/krb5.conf.d/freeipa the setting [libdefaults] spake_preauth_groups=edwards25519 prevents ad domain account users from logging in to the ipa server running on rhel8 according to this site it's protection against dictionary attacks https://web.mit.edu/kerberos/krb5-latest/doc/admin/spake.html commenting those two lines and restarting the sssd service allows the ad domain users to login to the rhel8 systems however, this means I lose the extra protection against dictionary attacks. Is there a way to have both ? ( login for ad users on rhel8 and dictionary attack protection ) Cheers Rob

2 2

NFS Errors
by Tobi Berninger 02 Sep '19

02 Sep '19

Hello, sadly we had a power shortage (a transformer exploded in the building next to us....) and all server shutted down immediately - i started them again. now we have some strange errors: First only two clients werent able to access their nfs home - two days latter all clients cant access them... I first check the date but it is synced all over the system and not the problem. then i discovered an error in the logs that the callback ip wasnt right, fixed that too... still cant get access to the nfs server - only the one share that is accessiable for all users is mounted. Keytabes was renewed on NFSserver as on the clients. the krb5 logs dont show any real clue... I use virtualized Centos Based Server (Up to Date): IpaServer NFSServer BackupNFSServer Any ideas? Thanks

2 1

Can login with non-existing user
by Ronald Wimmer 02 Sep '19

02 Sep '19

I have managed to login to an IPA client with a non-existing user. My AD user is z123456(a)addomain.mydomain.at and I have created a similar user called i123456(a)ipadomain.mydomain.at. What happened now is that I could log in with the i-User and what I get to see after logging in is this: [i123456@addomain.mydomain.at@as12314 ~]$ id uid=1246600007(i123456(a)addomain.mydomain.at) gid=1246600007(i123456(a)addomain.mydomain.at) groups=1246600007(i123456@addomain.mydomain.at),1246600016(my-ad-group@ipadomain.mydomain.at) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [i123456@addomain.mydomain.at@as12314 ~]$ whoami i123456(a)addomain.mydomain.at The user i123456(a)addomain.mydomain.at does NOT exist. addomain is set as default domain in the client's sssd.conf. What is wrong here? Are things just displayed wrong or could it be more? Which files do you need in order to analyze this issue? Cheers, Ronald

2 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users September 2019