FreeIPA-users March 2024

freeipa-users@lists.fedorahosted.org

32 participants
52 discussions

"Credential cache is empty" error preventing certmonger from renewing a host's certificate
by Sam Morris 11 Apr '24

11 Apr '24

I've got an IPA client on which certmonger is unable to renew a certificate. Here are the log messages from certmonger... 2023-06-20 08:24:49 [622035] Certificate submission attempt complete. 2023-06-20 08:24:49 [622035] Child status = 2. 2023-06-20 08:24:49 [622035] Child output: "Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is > " 2023-06-20 08:24:49 [622035] Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more infor> Here's the tracking request, nothing looks out of the ordinary to me... # getcert list -i 20220519165212 Number of certificates and requests being tracked: 2. Request ID '20220519165212': status: MONITORING ca-error: Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cre. stuck: no key pair storage: type=FILE,location='/etc/cockpit/ws-certs.d/51-myhost.key' certificate: type=FILE,location='/etc/cockpit/ws-certs.d/51-myhost.crt' CA: IPA issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM subject: CN=myhost.ipa.example.com,O=IPA.EXAMPLE.COM issued: 2023-03-25 16:52:45 UTC expires: 2023-06-23 16:52:45 UTC dns: myhost.ipa.example.com principal name: host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes In order to rule out a problem with ipa5, I used 'ipactl' to stop everything on it, then re-ran 'getcert resubmit -i 20220519165212'. In the subsequent output of 'getcert list -i 20220519165212' I saw the same error message displayed but with the name of a different IPA server. So I don't think this is a problem with a particular IPA server. Next I extracted the CSR data from '/var/lib/certmonger/requests/20220519165212' to a file, authenticated as host/myhost.ipa.example.com (with 'kinit -k') and then ran 'ipa cert-request host.req --principal=host/myhost.ipa.example.com', which worked! So perhaps the problem is with certmonger, or with the way in which it interacts with the IPA server that differs from simply running 'ipa cert-request' as I did manually. I also tried to look for logs on the server side, but I didn't find anything very useful. /var/log/httpd/access_log has: 192.168.0.4 - - [20/Jun/2023:13:21:53 +0000] "POST /ipa/json HTTP/1.1" 401 2719 192.168.0.4 - host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [20/Jun/2023:13:21:53 +0000] "POST /ipa/json HTTP/1.1" 200 526 So it looks like certmonger is having no problem authenticating to ipaapi. httpd is logging: $ journalctl -u httpd -e Jun 20 13:21:56 [121899]: GSSAPI client step 1 Jun 20 13:21:56 [121899]: GSSAPI client step 1 Jun 20 13:21:57 [121899]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) So is looks like ipaapi might be having trouble using Kerberos as a client? I added KRB5_TRACE=/var/lib/httpd/krb5.trace to httpd.service's Environment= and restarted it, then re-ran 'getcert resubmit' on the tracking request. I got these messages: [124285] 1687270136.437160: Initializing FILE:/tmp/krb5cc-httpd with default princ HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM [124285] 1687270136.437161: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> Encrypted/Credentials/v1@X-GSSPROXY: in FILE:/tmp/krb5cc-httpd [124285] 1687270136.437163: Retrieving HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> Encrypted/Credentials/v1@X-GSSPROXY: from FILE:/tmp/krb5cc-httpd with result: 0/Success [124285] 1687270136.437165: Initializing FILE:/run/ipa/ccaches/host~myhost.ipa.example.com@IPA.EXAMPLE.COM-h3azdl with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [124285] 1687270136.437166: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> Encrypted/Credentials/v1@X-GSSPROXY: in FILE:/run/ipa/ccaches/host~myhost.ipa.example.com@IPA.EXAMPLE.COM-h3azdl No errors there either. I set KRB5_TRACE=/var/lib/gssproxy/krb5.trace in gssproxy.service's Environment= and got: [124798] 1687270460.854044: Resolving unique ccache of type MEMORY [124798] 1687270460.854045: Initializing MEMORY:GJanRRF with default princ HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270460.854046: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:GJanRRF [124798] 1687270460.854047: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:GJanRRF [124798] 1687270460.854048: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:GJanRRF [124798] 1687270460.854049: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:GJanRRF [124798] 1687270460.854052: Destroying ccache MEMORY:GJanRRF [124798] 1687270460.854054: Resolving unique ccache of type MEMORY [124798] 1687270460.854055: Initializing MEMORY:Cn5E8Va with default princ HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270460.854056: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:Cn5E8Va [124798] 1687270460.854057: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:Cn5E8Va [124798] 1687270460.854058: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:Cn5E8Va [124798] 1687270460.854059: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:Cn5E8Va [124798] 1687270460.854062: Destroying ccache MEMORY:Cn5E8Va [124798] 1687270460.854064: Resolving unique ccache of type MEMORY [124798] 1687270460.854065: Initializing MEMORY:8e5DNHy with default princ HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270460.854066: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:8e5DNHy [124798] 1687270460.854067: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:8e5DNHy [124798] 1687270460.854068: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:8e5DNHy [124798] 1687270460.854069: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:8e5DNHy [124798] 1687270460.854071: Decrypted AP-REQ with server principal HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM: aes256-cts/E0A2 [124798] 1687270460.854072: AP-REQ ticket: host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM, session key aes256-cts/1952 [124798] 1687270460.854073: Negotiated enctype based on authenticator: aes256-cts [124798] 1687270460.854074: Authenticator contains subkey: aes256-cts/2098 [124798] 1687270460.854075: Resolving unique ccache of type MEMORY [124798] 1687270460.854076: Initializing MEMORY:FX6Yqgq with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270460.854077: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:FX6Yqgq [124798] 1687270460.854078: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:FX6Yqgq [124798] 1687270460.854079: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:FX6Yqgq [124798] 1687270460.854080: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:FX6Yqgq [124798] 1687270460.854081: Storing config in MEMORY:FX6Yqgq for : proxy_impersonator: HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270460.854082: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:FX6Yqgq [124798] 1687270460.854083: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:FX6Yqgq [124798] 1687270460.854085: Creating AP-REP, time 1687270460.725581, subkey aes256-cts/BB66, seqnum 668121546 [124798] 1687270461.005570: Destroying ccache MEMORY:FX6Yqgq [124798] 1687270461.005573: Destroying ccache MEMORY:8e5DNHy [124798] 1687270461.005575: Resolving unique ccache of type MEMORY [124798] 1687270461.005576: Initializing MEMORY:NmnNwyD with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270461.005577: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:NmnNwyD [124798] 1687270461.005578: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:NmnNwyD [124798] 1687270461.005579: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:NmnNwyD [124798] 1687270461.005580: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:NmnNwyD [124798] 1687270461.005581: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:NmnNwyD [124798] 1687270461.005582: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:NmnNwyD [124798] 1687270461.005585: Destroying ccache MEMORY:NmnNwyD [124798] 1687270461.005587: Resolving unique ccache of type MEMORY [124798] 1687270461.005588: Initializing MEMORY:gUnl8Xt with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270461.005589: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:gUnl8Xt [124798] 1687270461.005590: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:gUnl8Xt [124798] 1687270461.005591: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:gUnl8Xt [124798] 1687270461.005592: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:gUnl8Xt [124798] 1687270461.005593: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:gUnl8Xt [124798] 1687270461.005594: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:gUnl8Xt [124798] 1687270461.005597: Destroying ccache MEMORY:gUnl8Xt [124798] 1687270461.005599: Resolving unique ccache of type MEMORY [124798] 1687270461.005600: Initializing MEMORY:wBGblf3 with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270461.005601: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:wBGblf3 [124798] 1687270461.005602: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:wBGblf3 [124798] 1687270461.005603: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:wBGblf3 [124798] 1687270461.005604: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:wBGblf3 [124798] 1687270461.005605: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:wBGblf3 [124798] 1687270461.005606: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:wBGblf3 [124798] 1687270461.005609: Destroying ccache MEMORY:wBGblf3 [124798] 1687270461.005611: Resolving unique ccache of type MEMORY [124798] 1687270461.005612: Initializing MEMORY:4uHf47g with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270461.005613: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:4uHf47g [124798] 1687270461.005614: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:4uHf47g [124798] 1687270461.005615: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:4uHf47g [124798] 1687270461.005616: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:4uHf47g [124798] 1687270461.005617: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:4uHf47g [124798] 1687270461.005618: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:4uHf47g [124798] 1687270461.005621: Destroying ccache MEMORY:4uHf47g [124798] 1687270461.005623: Resolving unique ccache of type MEMORY [124798] 1687270461.005624: Initializing MEMORY:9LUdBez with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270461.005625: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:9LUdBez [124798] 1687270461.005626: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:9LUdBez [124798] 1687270461.005627: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:9LUdBez [124798] 1687270461.005628: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:9LUdBez [124798] 1687270461.005629: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:9LUdBez [124798] 1687270461.005630: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:9LUdBez [124798] 1687270461.005634: Initializing MEMORY:cred_allowed_0x7f85d9152380 with default princ host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM [124798] 1687270461.005635: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM in MEMORY:cred_allowed_0x7f85d9152380 [124798] 1687270461.005636: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:cred_allowed_0x7f85d9152380 [124798] 1687270461.005637: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/IPA.EXAMPLE.COM\@IPA.EXAMPLE.COM@X-CACHECONF: in MEMORY:cred_allowed_0x7f85d9152380 [124798] 1687270461.005638: Storing HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time@X-CACHECONF: in MEMORY:cred_allowed_0x7f85d9152380 [124798] 1687270461.005639: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: in MEMORY:cred_allowed_0x7f85d9152380 [124798] 1687270461.005640: Storing host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM in MEMORY:cred_allowed_0x7f85d9152380 [124798] 1687270461.005641: Destroying ccache MEMORY:cred_allowed_0x7f85d9152380 [124798] 1687270461.005644: Getting credentials host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> ldap/ipa5.ipa.example.com@ using ccache MEMORY:9LUdBez [124798] 1687270461.005645: Retrieving host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from MEMORY:9LUdBez with result: -1765328243/Matching credential not found [124798] 1687270461.005646: Retrieving host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> ldap/ipa5.ipa.example.com@ from MEMORY:9LUdBez with result: -1765328243/Matching credential not found [124798] 1687270461.005647: Retrying host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> ldap/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM with result: -1765328243/Matching credential not found [124798] 1687270461.005648: Retrieving host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM from MEMORY:9LUdBez with result: 0/Success [124798] 1687270461.005649: Getting credentials HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM using ccache MEMORY:9LUdBez [124798] 1687270461.005650: Retrieving host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from MEMORY:9LUdBez with result: -1765328243/Matching credential not found [124798] 1687270461.005651: Retrieving HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM -> krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM from MEMORY:9LUdBez with result: 0/Success [124798] 1687270461.005652: Get cred via TGT krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM after requesting ldap/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM (canonicalize on) [124798] 1687270461.005653: Generated subkey for TGS request: aes256-cts/FBB4 [124798] 1687270461.005654: etypes requested in TGS request: aes256-cts, aes256-sha2, camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts [124798] 1687270461.005656: Encoding request body and padata into FAST request [124798] 1687270461.005657: Sending request (5335 bytes) to IPA.EXAMPLE.COM [124798] 1687270461.005658: Initiating TCP connection to stream 192.168.0.5:88 [124798] 1687270461.005659: Sending TCP request to stream 192.168.0.5:88 [124798] 1687270461.005660: Received answer (508 bytes) from stream 192.168.0.5:88 [124798] 1687270461.005661: Terminating TCP connection to stream 192.168.0.5:88 [124798] 1687270461.005662: Response was from master KDC [124798] 1687270461.005663: Decoding FAST response [124798] 1687270461.005664: Decoding FAST response [124798] 1687270461.005665: Got cred; -1765328371/KDC can't fulfill requested option [124798] 1687270461.005669: Destroying ccache MEMORY:9LUdBez The only thing that looks like an error in that output is "KDC can't fulfill requested option". The last place I can think of looking is in /var/log/krb5kdc.log: Jun 20 14:17:34 ipa5.ipa.example.com krb5kdc[119948](info): TGS_REQ : handle_authdata (-1765328371) Jun 20 14:17:34 ipa5.ipa.example.com krb5kdc[119948](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha1-96(17), aes128-cts-hmac-sha256-128(19), camellia128-cts-cmac(25)}) 192.168.0.5: HANDLE_AUTHDATA: authtime 1687270653, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM for ldap/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM, KDC can't fulfill requested option Jun 20 14:17:34 ipa5.ipa.example.com krb5kdc[119948](info): ... CONSTRAINED-DELEGATION s4u-client=host/myhost.ipa.example.com(a)IPA.EXAMPLE.COM Jun 20 14:17:34 ipa5.ipa.example.com krb5kdc[119948](info): closing down fd 12 There's another instance of "KDC can't fulfill requested option". My best guess is that there's something wrong with the constrained delegation setup that lets ipaapi access the directory on behalf of the client host? But this looks fine: $ ipa servicedelegationrule-show ipa-http-delegation Delegation name: ipa-http-delegation Allowed Target: ipa-ldap-delegation-targets, ipa-cifs-delegation-targets Member principals: HTTP/ipa3.ipa.example.com(a)IPA.EXAMPLE.COM, HTTP/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM, HTTP/ipa6.ipa.example.com(a)IPA.EXAMPLE.COM $ ipa servicedelegationtarget-show ipa-ldap-delegation-targets Delegation name: ipa-ldap-delegation-targets Member principals: ldap/ipa3.ipa.example.com(a)IPA.EXAMPLE.COM, ldap/ipa5.ipa.example.com(a)IPA.EXAMPLE.COM, ldap/ipa6.ipa.example.com(a)IPA.EXAMPLE.COM ... and in any case a simple 'ipa cert-request' as the host worked fine, it's only certmonger's attempts to request a certificate that are failing. The IPA client has: ipa-client-4.9.11-5.module+el8.8.0+18147+84fe6ec1.x86_64 certmonger-0.79.17-2.el8.x86_64 ... and the server has: ipa-server-4.9.11-5.module+el8.8.0+18146+a1d8660b.x86_64 Any troubleshooting help is really appreciated! -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

2 5

CA Subsystem certificate
by Travis West 05 Apr '24

05 Apr '24

The person who set this up is no longer available. We have 6 IPA servers in a cluster, all set as MASTER. All servers are running IPA v. 4.6.4. On 8 March the CA Subsystem certificate expired. When looking at the certificate I noticed it had an incorrect Common Name, which may be why it didn't renew. I checked the pki-tomcat CS.cfg and the two lines ca.subsystem.cert - Has cert with incorrect hostname listed ca.subsystem.certreq - Has cert request for correct ca subsystem cert (Common Name CA Subsystem) I tried removing the errant ca subsystem cert from the NSS DB in pki-tomcat/alias and was successful. I then tried to request a new SubSystem Cert using this command getcert request -I CASubsystem -c dogtag-ipa-renew-agent -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -N 'cn=CA Subsystem,o=IPA.*****.NET' -P 'PIN_FROM_FILE' -t 'NSS Certificate DB' And that seems to at least have issued the request because 'getcert list' shows the request, but with a CA_REJECTED message. If I do an ldapsearch for the certificate, it shows the the correct cert with CN=CA Subystem, but the one that expired on 8 March. How can I get a valid CA Subsystem cert again so I can start the CA on all IPA servers?

3 38

Re: upgrade idm servers rhel 7 to 8 problems
by Natxo Asenjo 04 Apr '24

04 Apr '24

hi, posting back to the list. Apparently the idm server cannot find a SID of a domain when trying to resolve the user account. It does find the user account, but there are sids coupled to the account correspondig to a domain wich cannot be resolved. It took me a while but the sid of that child domain is not the one not resolved. It turns out, the sid of the domain not resolving is the one of the idm realm itself., we have some idm groups mapped to the AD groups we allow in idm for rbac, and if I look at the ipaNTSecurityIdentifier attributes of the id groups, those are the not resolved groups. This is unexpected (to me at least). so we have this trust (verified on two different idm servers, same value): ipa trust-find --------------- 1 trust matched --------------- Realm name: domain.local Domain NetBIOS name: DOMAIN Domain Security Identifier: S-1-5-21-1416133915-1866970209-3316290679 Trust type: Active Directory domain ---------------------------- Number of entries returned 1 but inside this idm domain, we have some idm posix groups with the ipantsecurityidentifier of the not resolvable domain, for instance: S-1-5-21-1214650608-3976977395-3073169311-101072 So basically, it is not matching because of this ipantsecurityidentifier, I think. I do not know how to fix this at this moment, or why it has happened. Any ideas?

2 3

Client install fails with: "Joining realm failed: JSON-RPC call failed: Timeout was reached"
by slek kus 03 Apr '24

03 Apr '24

Hi, not sure what might be an issue. Clients in the same network join just fine. The failing client is on another network. The following ports have been allowed: 53, 389, 636, 88, 464 Saw a list somewhere, mentioning 123, 80 and 443. Are these porst nessecary for the client/idm communication?

3 3

ACME certs fail to renew
by Antoine Gatineau 02 Apr '24

02 Apr '24

Hello, I have a strange issue regarding acme service. My acme certificates fail to renew. `ipa-acme-manage status`fails with error: Failed to authenticate to CA REST API The ipa-acme-manage command failed. certbot client fails with error "Failed to renew certificate office.empire.lan with error: <Response [404]>" $ ipa cert-show 49 Issuing CA: ipa Certificate: "The certificate content" Subject: CN=office.empire.lan Subject DNS name: office.empire.lan Issuer: CN=Certificate Authority,O=EMPIRE.LAN Not Before: Sun Dec 24 14:05:50 2023 UTC Not After: Sat Mar 23 14:05:50 2024 UTC Serial number: 49 Serial number (hex): 0x31 Revoked: False So last successful renewal was on Dec 24th. Since then I have not really done anything appart updating. I don't see any issue in ipaupgrade.log I am running on centos stream 9 idm-jss.x86_64 5.5.0-1.el9 idm-jss-tomcat.x86_64 5.5.0-1.el9 idm-ldapjdk.noarch 5.5.0-1.el9 idm-pki-acme.noarch 11.5.0-1.el9 idm-pki-base.noarch 11.5.0-1.el9 idm-pki-ca.noarch 11.5.0-1.el9 idm-pki-java.noarch 11.5.0-1.el9 idm-pki-kra.noarch 11.5.0-1.el9 idm-pki-server.noarch 11.5.0-1.el9 idm-pki-tools.x86_64 11.5.0-1.el9 ipa-client.x86_64 4.11.0-9.el9 ipa-client-common.noarch 4.11.0-9.el9 ipa-common.noarch 4.11.0-9.el9 ipa-healthcheck.noarch 0.16-2.el9 ipa-healthcheck-core.noarch 0.16-2.el9 ipa-selinux.noarch 4.11.0-9.el9 ipa-server.x86_64 4.11.0-9.el9 ipa-server-common.noarch 4.11.0-9.el9 ipa-server-dns.noarch 4.11.0-9.el9 I have followed closely the update on centos stream 9 Running `ipa-acme-manage status` with the -d switch gives me ipapython.ipaldap: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-EMPIRE-LAN.socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f123c07e2e0> ipaserver.masters: DEBUG: Discovery: available servers for service 'CA' are ipa-server-01.empire.lan, ipa-server-02.empire.lan ipaserver.masters: DEBUG: Discovery: using ipa-server-01.empire.lan for 'CA' service ipapython.dogtag: DEBUG: request POST https://ipa-server-01.empire.lan:8443/acme/login ipapython.dogtag: DEBUG: request body '' ipapython.dogtag: DEBUG: response status 404 ipapython.dogtag: DEBUG: response headers Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 765 Date: Thu, 28 Mar 2024 10:00:59 GMT ipapython.dogtag: DEBUG: response body (decoded): b'<!doctype html><html lang="en"><head><title>HTTP Status 404 \xe2\x80\x93 Not Found</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 404 \xe2\x80\x93 Not Found</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Message</b> The requested resource [/acme/login] is not available</p><p><b>Description</b> The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.</p><hr class="line" /><h3>Apache Tomcat/9.0.62</h3></body></html>' ipapython.admintool: DEBUG: File "/usr/lib/python3.9/site-packages/ipapython/admintool.py", line 180, in execute return_value = self.run() File "/usr/lib/python3.9/site-packages/ipaserver/install/ipa_acme_manage.py", line 403, in run with state as ca_api: File "/usr/lib/python3.9/site-packages/ipaserver/install/ipa_acme_manage.py", line 103, in __enter__ raise errors.RemoteRetrieveError( ipapython.admintool: DEBUG: The ipa-acme-manage command failed, exception: RemoteRetrieveError: Failed to authenticate to CA REST API ipapython.admintool: ERROR: Failed to authenticate to CA REST API ipapython.admintool: ERROR: The ipa-acme-manage command failed. So it looks like the acme subsystem is not started. But logs for the acme subsystem in /var/log/pki/pki-tomcat/acme/debug.2024-03-28.log don't show any issue. (see attached log) How can I go further in troubleshooting/fixing this issue? Thanks

2 3

problem with configuration replication in ipa server
by Richard Halley 01 Apr '24

01 Apr '24

Hi everyone, I'm configuring the freeipa replication as follows: 1) ipa-client-install --domain=pippo.internal --realm=PIPPO.INTERNAL -N 2) I add the client to the ipaserver host group 3) ipa-replica-install -N --setup-dns --forwarder 8.8.8.8 --forwarder 8.8.4.4 --forwarder 1.1.1.1 --setup-ca After running ipa-replica-install I get the following error: Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipapython.admintool: ERROR A replication agreement for this host already exists. It needs to be removed. Run this command: %% ipa-replica-manage del pluto.pippo.internal --force ipapython.admintool: ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information I would like to point out that I have attempted the configuration several times without success. Before proceeding with the uninstall commands of the client and the replica on the replica server, I delete the replica on the server (which fails because it does not find any replica) and then proceed with deleting the client. In the replication log file I have the following error: 2024-03-28T12:05:10Z DEBUG The ipa-replica-install command failed, exception: ScriptError: A replication agreement for this host already exists. It needs to be removed. Run this command: %% ipa-replica-manage del pluto.pippo.internal --force 2024-03-28T12:05:10Z ERROR A replication agreement for this host already exists. It needs to be removed. Run this command: %% ipa-replica-manage del pluto.pippo.internal --force 2024-03-28T12:05:10Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information I can't understand where the problem is. Could it be something dirty in LDAP? Thank you very much

2 1

Revoked certificates not appearing in CRL
by Sam Morris 25 Mar '24

25 Mar '24

It looks like my CRL renewal master (RHEL 8) is not producing the CRL correctly. I've got two certificates that were requested by certmonger running on an ipa client. I'm pretty sure I revoked them as an admin logged into a second ipa client. Status of all replication agreements on all ipa servers is green. The CRL renewal master knows the certificates were issued & revoked: $ ipa cert-find --validnotbefore-from=2024-03-14 --status=REVOKED ---------------------- 2 certificates matched ---------------------- Issuing CA: ipa Subject: CN=myhost.example.com,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Not Before: Thu Mar 14 20:29:31 2024 UTC Not After: Wed Jul 17 20:29:31 2024 UTC Serial number: 1342111806 Serial number (hex): 0x4FFF003E Status: REVOKED Revoked: True Issuing CA: ipa Subject: CN=myhost.example.com,O=EXAMPLE.COM Issuer: CN=Certificate Authority,O=EXAMPLE.COM Not Before: Thu Mar 14 20:35:03 2024 UTC Not After: Wed Jul 17 20:35:03 2024 UTC Serial number: 1342111807 Serial number (hex): 0x4FFF003F Status: REVOKED Revoked: True ---------------------------- Number of entries returned 2 ---------------------------- * Both certificates are revoked * Both certificates have 'not after' dates in the future. But looking at the current CRL: $ openssl crl -in /var/lib/ipa/pki-ca/publish/MasterCRL.bin -inform der -noout -text Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: O = EXAMPLE.COM, CN = Certificate Authority Last Update: Mar 23 13:18:45 2024 GMT Next Update: Mar 23 17:00:00 2024 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:1B:89:B8:D6:6F:4D:41:C1:BD:47:A3:9B:21:36:8C:71:10:59:8C:A6 X509v3 CRL Number: 10526 Revoked Certificates: Serial Number: 2FFE002B Revocation Date: May 19 17:01:12 2022 GMT CRL entry extensions: X509v3 CRL Reason Code: Key Compromise Signature Algorithm: sha256WithRSAEncryption 0f:2f:59:9b:9c:1c:ac:fd:6a:e5:d7:87:94:97:e3:a8:cf:07: fe:86:8b:4e:a6:37:dc:76:c1:ef:f3:69:9e:e3:5c:8a:dd:12: cb:fa:4a:97:21:ae:fa:ee:91:bb:37:9e:cb:bb:49:10:58:95: bd:24:98:df:a1:45:90:b3:f1:51:af:2b:c9:cb:c3:89:23:a8: f5:8d:3f:d4:4e:4b:a6:ef:d6:96:94:36:da:a1:0c:ab:32:27: 85:24:0d:9c:52:17:17:4d:ae:3a:83:59:39:a9:08:33:7d:f4: 05:74:e3:7d:1e:df:8e:f8:4c:c0:fd:7f:8b:a2:b4:0a:a2:fc: 57:9b:00:c2:29:9e:74:0f:c2:4a:0e:5c:e6:f0:1e:ff:71:a9: f9:cb:a1:6f:b4:48:16:59:42:78:2a:38:1d:14:b7:d3:58:cb: 21:ad:61:bb:c9:20:e6:c2:39:97:bf:a6:f8:fe:26:32:51:eb: 67:b4:0c:b9:ea:96:ea:b0:66:cf:7c:73:74:69:fc:08:d9:a7: 13:23:34:3e:a6:f1:b3:0d:0f:54:46:22:71:6c:16:81:a8:97: 79:c5:a0:20:03:5d:51:d7:fb:25:33:3b:7a:55:59:dd:a6:cb: 3e:00:1d:2a:c7:a3:7a:8b:3b:1f:d9:36:23:c5:c3:f4:ff:14: 86:0b:61:fc * The CRL was just generated a few minutes ago * The two revoked certificates are not present * The certificate that is present in the list expired in July 2022, according to 'ipa cert-show 0x2FFE002B' To force CRL generation I'm running: $ curl https://$HOSTNAME:8443/ca/agent/ca/updateCRL --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key Nothing suspicious shows up in Dogtag's logs: ==> /var/log/pki/pki-tomcat/ca/debug.2024-03-23.log <== 2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: Getting SSL client certificate. 2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: CertUserDBAuthentication: UID ipara authenticated. 2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: UGSubsystem: retrieving user uid=ipara,ou=People,o=ipaca 2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: AAclAuthz: Granting update permission for certServer.ca.crl 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CRLIssuingPoint: Updating MasterCRL 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CASigningUnit: Getting algorithm context for SHA256withRSA RSASignatureWithSHA256Digest 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CASigningUnit: Signing Certificate 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CRLReposiotry: Updating CRL issuing point record 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: LDAPSession: Modifying LDAP entry cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: Getting crl publishing rules 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapXCertRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCaCertRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: FileCrlRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: true 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: type: crl 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: predicate: null 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapUserCertRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCrlRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing CRL 10529 to MasterCRL 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: Getting crl publishing rules 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapXCertRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCaCertRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: FileCrlRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: true 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: type: crl 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: predicate: null 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapUserCertRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCrlRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing rules: 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: - rule: FileCrlRule 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: mapper: NoMap 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing to CN=Certificate Authority,O=EXAMPLE.COM 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: - publisher: FileBaseCRLPublisher 2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Published CRL ==> /var/log/pki/pki-tomcat/ca/signedAudit/ca_audit <== 0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=--][ServerIP=--][SubjectID=CN=IPA RA,O=EXAMPLE.COM][Outcome=Success] access session establish success 0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=AUTH][SubjectID=ipara][Outcome=Success][AuthMgr=certUserDBAuthMgr] authentication success 0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=AUTHZ][SubjectID=ipara][Outcome=Success][aclResource=certServer.ca.crl][Op=update] authorization success 0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ROLE_ASSUME][SubjectID=ipara][Outcome=Success][Role=Certificate Manager Agents, Registration Manager Agents, Security Domain Administrators, Enterprise ACME Administrators] assume privileged role 0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=SCHEDULE_CRL_GENERATION][SubjectID=ipara][Outcome=Success] schedule for CRL generation 0.https-jsse-nio-8443-exec-7 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=--][ServerIP=--][SubjectID=--][Outcome=Success][Info=serverAlertReceived: CLOSE_NOTIFY] access session terminated 0.https-jsse-nio-8443-exec-7 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=--][ServerIP=--][SubjectID=--][Outcome=Success][Info=serverAlertSent: CLOSE_NOTIFY] access session terminated This may be related to <https://pagure.io/freeipa/issue/9505>. I've not had the chance to test revocation on an ipa server yet. Any other debugging I can do just let me know. -- Sam Morris <https://robots.org.uk/> CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

1 1

upgrade idm servers rhel 7 to 8 problems
by Natxo Asenjo 25 Mar '24

25 Mar '24

hi, at work we are having *interesting* problems with our migration from idm servers running rhel 7 to new rhel 8 idm servers. We have a AD -> idm trust in place, this is working properly. AD is domain.local IDM is idm.domain.local We add replicas to the set, and this runs properly. No replication errors. Basically the problem is we cannot log in to newly joined systems running rhel 8 as trusted users from AD. We have a new rhel 8 idm server which has also the trust agent and trust controller role installed. We want to login as a trusted AD user to a rhel 8 host which has this new rhel 8 idm server as its ipa host, we have forced it using this sssd.conf: [domain/idm.domain.local] id_provider = ipa ipa_server = ds.idm.domain.local ipa_domain = idm.domain.local ipa_hostname = host.idm.domain.local auth_provider = ipa chpass_provider = ipa access_provider = ipa cache_credentials = True ldap_tls_cacert = /etc/ipa/ca.crt dyndns_update = True dyndns_iface = ens192 krb5_store_password_if_offline = True [sssd] services = nss, pam, ssh, sudo domains = idm.domain.local full_name_format = %1$s debug = 9 [nss] homedir_substring = /home override_homedir = /home/%u [pam] [sudo] [autofs] [ssh] [pac] [ifp] [session_recording] We also modified krb5.conf on the client to find the IDM realm only on the rhel 8 idm server, not the rhel 7. So we disabled srv dns autodiscovery for the IDM.DOMAIN.LOCAL realm: # cat /etc/krb5.conf #File modified by ipa-client-install includedir /etc/krb5.conf.d/ [libdefaults] default_realm = IDM.DOMAIN.LOCAL dns_lookup_realm = true rdns = false dns_canonicalize_hostname = false dns_lookup_kdc = true ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] IDM.DOMAIN.LOCAL = { kdc = ds.idm.domain.local:88 master_kdc = ds.idm.domain.local:88 admin_server = ds.idm.domain.local:749 kpasswd_server = ds.idm.domain.local:464 default_domain = idm.domain.local pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem } [domain_realm] .idm.domain.local = IDM.DOMAIN.LOCAL idm.domain.local = IDM.DOMAIN.LOCAL host.idm.domain.local = IDM.DOMAIN.LOCAL On the rhel 8 client, I can kinit with the host keytab, this work, I get a ticket with the host principal. I can also kinit using a trusted AD user, this works, I get a ticket of the AD domain. But as soon as I try logging in from ssh, it does not work. It does not recognize the user. Running id trusteduser@ad does not wok either (no such user) I have run out of ideas, to be honest. I do not know how to troubleshoot this anymore. The rhel8 idm server finds the users, I can log in there without any problem too thanks to the rbac rules, but this rhel8 client simpley will not see the users. Any ideas? Thanks in advance. -- Groeten, natxo

2 11

cannot login into account after migration to 4.10.x
by Piotr Miedzik 22 Mar '24

22 Mar '24

Hi I have problem with some users after updating freeipa server. As of freeipa 4.10 I'm not able to login if user was created with uid specified (ipa user-add testx --uid=1001 --first=p --last=m --password) It also doesn't work for accounts created with previous freeipa versions. steps to reproduce: 1) install podman run --rm -p 10.58.0.45:53:53/udp -p 10.58.0.45:53:53 -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p 464:464 -p 88:88/udp -p 464:464/udp -p 123:123/udp --name ipa01 -ti -h ipa01.dev.example.com -v /srv/ipa01-data/:/data:Z -e freeipa/freeipa-server:fedora-36-4.9.11 2) create account testx with uid ipa user-add testx --uid=1001 --first=p --last=m --password 3) create account testy without uid ipa user-add testy --first=p --last=m --password 4) upgrade to newest version podman run --rm -p 10.58.0.45:53:53/udp -p 10.58.0.45:53:53 -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p 464:464 -p 88:88/udp -p 464:464/udp -p 123:123/udp --name ipa01 -ti -h ipa01.dev.example.com -v /srv/ipa01-data/:/data:Z -e freeipa/freeipa-server:fedora-38-4.10.3 user testx cannot login, user testy is able to login

2 1

admin password changes when joing new replica
by Schweiss, Chip 22 Mar '24

22 Mar '24

I'm building out a multisite installation. For unknown reasons, the 'admin' user password needs to be reset each time I join a new FreeIPA replica. It seems to happen a minute or two after the ipa-replica-install completes. Attempts to kinit immediately afterward usually works. Here's my ipa-replica install command I'm using: ipa-replica-install -n {domain} -r {realm} -d \ --server={existing_ipa_server} \ --setup-adtrust --add-agents --mkhomedir \ --ntp-pool={my_ntp_pool} \ -p $otp How do I track down the cause of this? -Chip

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users March 2024