IdM with trust relationship with Samba AD DC - User accounts with passwords expired
by Mateo Duffour
Hi,
We currently have an IdM installation with a trust relationship with a Samba AD DC. Our user accounts reside on Samba AD DC, we dont have user accounts on IdM.
We are having a problem with Samba user acounts that have its passwords expired.
When we try to login with an ubuntu IdM client with one of those accounts, it fails and asks again for password.
The behaviour we are expecting is that Ubuntu should ask for a password change.
Thanks, best regards.
Lic. Mateo Duffour
Unidad Informática
2901.40.91
[ http://maps.apple.com/?q=18%20de%20julio%20985%20-%20Piso%204,Montevideo,... | 18 de julio 985 - Piso 3, Montevideo, Uruguay ]
[ http://www.fnr.gub.uy/ | ]
No me imprimas si no es necesario. Protejamos el medio ambiente. Este mensaje y la información adjunta al mismo está dirigido exclusivamente a su destinatario. Puede contener información confidencial, privilegiada o de uso restringido, protegida por las normas. Si Ud. recibió este e-mail por error, por favor, sírvase notificarle a quien se lo envió y borrar el original. Cualquier otro uso del e-mail por Ud. está prohibido.
1 week
Broken ipa replica
by Giulio Casella
Hi everyone,
I'm stuck with a broken replica. I had a setup with two ipa server in
replica (ipa-server-4.6.4 on CentOS 7.6), let's say "idc01" and "idc02".
Due to heavy load idc01 crashed many times, and was not working anymore.
So I tried to redo the replica again. At first I tried to
"ipa-replica-manage re-initialize", with no success.
Now I'm trying to redo from scratch the replica setup: on idc02 I
removed the segments (ipa topologysegment-del, for both ca and domain
suffix), on idc01 I removed everything (ipa-server-install --uninstall),
then I joined domain (ipa-client-install), and everything is working so far.
When doing "ipa-replica-install" on idc01 I get:
[...]
[28/41]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 22 seconds elapsed
[ldap://idc02.my.dom.ain:389] reports: Update failed! Status: [Error
(-11) connection error: Unknown connection error (-11) - Total update
aborted]
And on idc02 (the working server), in
/var/log/dirsrv/slapd-MY-DOM-AIN/errors I find lines stating:
[20/Mar/2019:09:28:06.545187923 +0100] - INFO - NSMMReplicationPlugin -
repl5_tot_run - Beginning total update of replica
"agmt="cn=meToidc01.my.dom.ain" (idc01:389)".
[20/Mar/2019:09:28:26.528046160 +0100] - ERR - NSMMReplicationPlugin -
perform_operation - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Failed
to send extended operation: LDAP error -1 (Can't contact LDAP server)
[20/Mar/2019:09:28:26.530763939 +0100] - ERR - NSMMReplicationPlugin -
repl5_tot_log_operation_failure - agmt="cn=meToidc01.my.dom.ain"
(idc01:389): Received error -1 (Can't contact LDAP server): for total
update operation
[20/Mar/2019:09:28:26.532678072 +0100] - ERR - NSMMReplicationPlugin -
release_replica - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Unable to
send endReplication extended operation (Can't contact LDAP server)
[20/Mar/2019:09:28:26.534307539 +0100] - ERR - NSMMReplicationPlugin -
repl5_tot_run - Total update failed for replica
"agmt="cn=meToidc01.my.dom.ain" (idc01:389)", error (-11)
[20/Mar/2019:09:28:26.561763168 +0100] - INFO - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meToidc01.my.dom.ain" (idc01:389):
Replication bind with GSSAPI auth resumed
[20/Mar/2019:09:28:26.582389258 +0100] - WARN - NSMMReplicationPlugin -
repl5_inc_run - agmt="cn=meToidc01.my.dom.ain" (idc01:389): The remote
replica has a different database generation ID than the local database.
You may have to reinitialize the remote replica, or the local replica.
It seems that idc02 remembers something about the old replica.
Any hint?
Thank you in advance,
Giulio
2 weeks, 2 days
error: PAM: User account has expired for <user>
by Ben Aveling
We're having users unable to login on some hosts.
The error message in /var/log/secure is:
sshd[29399]: error: PAM: User account has expired for <<username>> from <<ip address>>
The same users can login fine to other hosts, suggesting it's a config or other issue with these specific hosts.
Has anyone seen anything similar?
3 weeks, 1 day
Unable to Login to Windows Server With IPA user
by Damola Azeez
I'm Unable to login with the IPA users i created and mapped to the windows server. Whenever i attempt to login, I'm greeted with a message saying the user has no right to login because it is not in the Remote desktop group. I can confirm that the users are in the remote desktop group on windows server.
Link to the image that describes the situation
(https://www.linkpicture.com/q/Screenshot_1_257.png)
Version/Release/Distribution
=======================
ipa-server-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.x86_64
ipa-client-4.9.6-10.0.1.module+el8.5.0+20451+6c55862e.x86_64
389-ds-base-1.4.3.23-14.module+el8.5.0+20517+748852bc.x86_64
pki-ca-10.11.2-4.0.1.module+el8.5.0+20486+8c04dafa.noarch
krb5-server-1.18.2-14.el8.x86_64
3 weeks, 4 days
Trouble with IPA tools
by Victoria Fierce
Howdy.
I've been a long-time user of freeipa and have had a small instance running at home via fedora packages for the past 5 years or so. Its actually hard to know just how long I've had it running, but that's besides the point; for what feels like ages I've never had to really mess with it and it kept on ticking. Until recently.
I'm no longer able to use the ipa command line tool or the webui. The webui correctly rejects any invalid passwords with an invalid password message, but any /correct/ credentials simply says "Your session has expired. Please log in again.". All of my clients are using the same NTP server as the server, nothing it out of sync, and caches have been cleared multiple times. I know this isn't a browser issue, because of the next point:
I can't use the ipa command on my server anymore. Here's a brief sample of one such attempt:
[root@io kdc]# kinit admin
Password for admin(a)MALLOC.HACKERBOTS.NET:
[root@io kdc]# ipa -d
ipa: DEBUG: Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
ipa: DEBUG: Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
ipa: DEBUG: Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin(a)MALLOC.HACKERBOTS.NET'
ipa: DEBUG: trying https://io.malloc.hackerbots.net/ipa/json
ipa: DEBUG: Created connection context.rpcclient_139701656917472
ipa: DEBUG: [try 1]: Forwarding 'schema' to json server 'https://io.malloc.hackerbots.net/ipa/json'
ipa: DEBUG: New HTTP connection (io.malloc.hackerbots.net)
ipa: DEBUG: received Set-Cookie (<class 'list'>)'['ipa_session=MagBearerToken=lflo9aPGmula4dSW7i8LbiI7ZNH%2bSycMGOGpqZiZkD0bydWnWfzv7bSuTIzsvdQGPas3BatwwBmREuVlVM0iT0%2by2tto74XdZXXYrv4MhOFT7q3vECladuGsQgqInfrIeLG4a8LMQ0CqE8exLdtttJtt%2fydt1lHzsbHCTigV7TS8CF%2bnZ7558549uo5rJtG%2f6YXG7p0zzhQ4hUYOPwjR%2byux%2bIQhK5PeVu3TKnofFZk%3d;path=/ipa;httponly;secure;']'
ipa: DEBUG: storing cookie 'ipa_session=MagBearerToken=lflo9aPGmula4dSW7i8LbiI7ZNH%2bSycMGOGpqZiZkD0bydWnWfzv7bSuTIzsvdQGPas3BatwwBmREuVlVM0iT0%2by2tto74XdZXXYrv4MhOFT7q3vECladuGsQgqInfrIeLG4a8LMQ0CqE8exLdtttJtt%2fydt1lHzsbHCTigV7TS8CF%2bnZ7558549uo5rJtG%2f6YXG7p0zzhQ4hUYOPwjR%2byux%2bIQhK5PeVu3TKnofFZk%3d;' for principal admin(a)MALLOC.HACKERBOTS.NET
ipa: DEBUG: Destroyed connection context.rpcclient_139701656917472
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
Wish I could say how long its been like this or what I did to break it, but again, its been running for so long that I've never really had to check in on it! This is a Fedora 32 server that has gone through several distro upgrades over the years and through each one, freeipa kept running without issue. I'm certain that at some point in the last year I've upgraded a package that broke this, but there is no way to check. Kerberos continues to work fine; I can login to other services and change passwords and whatnot. ldapsearch returns results and I can bind to it, and other services that utilize ldap for authentication still work great. Except for, of course, the freeipa web app. It looks like freeipa hasn't seen a new release in quite some time, so I'm prepared to do a bunch of debugging myself if anyone could point me in the right directions.
Additionally, here's the apache error_log with debug=true in /etc/ipa/server.conf:
[Mon Apr 18 10:57:31.776194 2022] [ssl:info] [pid 1989623:tid 1989819] [client 127.0.0.1:42826] AH01964: Connection to child 8 established (server io.malloc.hackerbots.net:443)
[Mon Apr 18 10:57:31.776376 2022] [ssl:debug] [pid 1989623:tid 1989819] ssl_engine_kernel.c(2374): [client 127.0.0.1:42826] AH02043: SSL virtual host for servername io.malloc.hackerbots.net found
[Mon Apr 18 10:57:31.779851 2022] [ssl:debug] [pid 1989623:tid 1989819] ssl_engine_kernel.c(2254): [client 127.0.0.1:42826] AH02041: Protocol: TLSv1.3, Cipher: TLS_AES_256_GCM_SHA384 (256/256 bits)
[Mon Apr 18 10:57:31.779966 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(493): AH00831: socache_shmcb_store (0x4a -> subcache 10)
[Mon Apr 18 10:57:31.779974 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(847): AH00847: insert happened at idx=2, data=(378:410)
[Mon Apr 18 10:57:31.779977 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(850): AH00848: finished insert, subcache: idx_pos/idx_used=0/3, data_pos/data_used=0/595
[Mon Apr 18 10:57:31.779981 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(515): AH00834: leaving socache_shmcb_store successfully
[Mon Apr 18 10:57:31.780083 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(493): AH00831: socache_shmcb_store (0xde -> subcache 30)
[Mon Apr 18 10:57:31.780088 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(847): AH00847: insert happened at idx=1, data=(217:249)
[Mon Apr 18 10:57:31.780091 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(850): AH00848: finished insert, subcache: idx_pos/idx_used=0/2, data_pos/data_used=0/434
[Mon Apr 18 10:57:31.780094 2022] [socache_shmcb:debug] [pid 1989623:tid 1989819] mod_socache_shmcb.c(515): AH00834: leaving socache_shmcb_store successfully
[Mon Apr 18 10:57:31.780181 2022] [ssl:debug] [pid 1989623:tid 1989819] ssl_engine_kernel.c(415): [client 127.0.0.1:42826] AH02034: Initial (No.1) HTTPS request received for child 8 (server io.malloc.hackerbots.net:443), referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780373 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780384 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780395 2022] [auth_gssapi:debug] [pid 1989623:tid 1989819] mod_auth_gssapi.c(893): [client 127.0.0.1:42826] URI: /ipa/session/json, no main, no prev, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780450 2022] [auth_gssapi:debug] [pid 1989623:tid 1989819] mod_auth_gssapi.c(983): [client 127.0.0.1:42826] Already established context found!, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780482 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of Require valid-user : granted, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780486 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of <RequireAny>: granted, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780544 2022] [lookup_identity:debug] [pid 1989623:tid 1989819] mod_lookup_identity.c(445): [client 127.0.0.1:42826] invoked for user admin(a)MALLOC.HACKERBOTS.NET, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780635 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of Require all granted: granted, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780641 2022] [authz_core:debug] [pid 1989623:tid 1989819] mod_authz_core.c(815): [client 127.0.0.1:42826] AH01626: authorization result of <RequireAny>: granted, referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.780648 2022] [auth_gssapi:debug] [pid 1989623:tid 1989819] mod_auth_gssapi.c(726): [client 127.0.0.1:42826] GSSapiImpersonate not On, skipping impersonation., referer: https://io.malloc.hackerbots.net/ipa/xml
[Mon Apr 18 10:57:31.781246 2022] [wsgi:error] [pid 1989622:tid 1989934] [remote 127.0.0.1:42826] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Mon Apr 18 10:57:31.781331 2022] [wsgi:error] [pid 1989622:tid 1989934] [remote 127.0.0.1:42826] ipa: DEBUG: WSGI jsonserver_session.__call__:
[Mon Apr 18 10:57:31.836341 2022] [wsgi:error] [pid 1989622:tid 1989934] [remote 127.0.0.1:42826] ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
3 weeks, 4 days
Migrating IPA CA to new hosts
by Adam Bishop
We're in the process of decomissioning our oldest IPA servers (built in 2014). We've migrated the roles successfully and are making sure everything is ready to switch over to the new set, and just wanted to check a few observations/inconsistencies.
* On some of our newer clients /etc/ipa/ca.crt contains the root and the server certificate of the enrolment server instead of just the root - did the behaviour of ipa-client-install change at some point?
* Our root contains the OCSP URI of one of the servers to be decomissioned in the Authority Information Access field. My understanding is that a client would never do an OCSP lookup on a root certificate so do we need to re-sign or add a CNAME prior to switching off?
* When enroling a client, ipa-client-install pulls down an expired RA certificate - however /var/lib/ipa/ra-agent.pem on all servers is current. Where might the expired cert be stored? Doesn't appear to cause an issue in any case.
Adam
3 weeks, 5 days
IPA API can't talk to PKI
by Sam Morris
Hi folks. PKI-related commands have started to fail on my setup:
$ ipa cert-find
ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (403)
$ ipa vaultconfig-show
ipa: ERROR: an internal error has occurred
In /var/log/httpd/error_log I can see, respectively (stripping out the
dates, pids, ip addresses etc):
ipa: ERROR: ra.find(): Unable to communicate with CMS (403)
ipa: INFO: [jsonserver_session] admin(a)IPA.EXAMPLE.COM: cert_find/1(None, version='2.245'): CertificateOperationError
and:
ipa: ERROR: non-public: HTTPError: 403 Client Error: 403 for url: https://ipa3.ipa.example.com:443/kra/rest/config/cert/transport
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 437, in handler
json = exc_val.response.json()
File "/usr/lib/python3.6/site-packages/requests/models.py", line 897, in json
return complexjson.loads(self.text, **kwargs)
File "/usr/lib64/python3.6/json/__init__.py", line 354, in loads
return _default_decoder.decode(s)
File "/usr/lib64/python3.6/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib64/python3.6/json/decoder.py", line 357, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/ipaserver/rpcserver.py", line 407, in wsgi_execute
result = command(*args, **options)
File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 471, in __call__
return self.__do_call(*args, **options)
File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 499, in __do_call
ret = self.run(*args, **options)
File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 821, in run
return self.execute(*args, **options)
File "/usr/lib/python3.6/site-packages/ipaserver/plugins/vault.py", line 1003, in execute
transport_cert = kra_client.system_certs.get_transport_cert()
File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 442, in handler
six.reraise(exc_type, exc_val, exc_tb)
File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
File "/usr/lib/python3.6/site-packages/pki/__init__.py", line 431, in handler
return fn_call(inst, *args, **kwargs)
File "/usr/lib/python3.6/site-packages/pki/systemcert.py", line 62, in get_transport_cert
response = self.connection.get(url, self.headers)
File "/usr/lib/python3.6/site-packages/pki/client.py", line 55, in wrapper
return func(self, *args, **kwargs)
File "/usr/lib/python3.6/site-packages/pki/client.py", line 261, in get
r.raise_for_status()
File "/usr/lib/python3.6/site-packages/requests/models.py", line 940, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 403 Client Error: 403 for url: https://ipa3.example.com:443/kra/rest/config/cert/transport
ipa: INFO: [jsonserver_session] admin(a)IPA.EXAMPLE.COM: vaultconfig_show/1(version='2.245'): InternalError
The only messages I can find on the PKI server side are in
</var/log/pki/pki-tomcat/localhost_access_log.2022-04-27.txt>:
2001:db8::1 - - [27/Apr/2022:11:59:14 +0000] "POST /ca/rest/certs/search?size=2147483647 HTTP/1.1" 403 618
2001:db8::1 - - [27/Apr/2022:11:59:17 +0000] "GET /kra/rest/config/cert/transport HTTP/1.1" 403 618
So I'm guessing that whatever certificate the IPA API uses to
communicate with the PKI server has expired.
ipa-healthcheck has been telling me about certificates with mismatches
between their NSS databases and their copies within CS.cfg for a while.
I reported these at <https://github.com/dogtagpki/pki/issues/3877> in
the hope that it would lead somewhere, before the warning actually
started causing problems. And then forgot all about it, naturally. :)
Here are the failed checks from ipa-healtcheck, followed by certmonger's
status for each tracking request, and the details of the certificate in
the NSS database and its copy within CS.cfg:
{
"source": "pki.server.healthcheck.meta.csconfig",
"check": "KRADogtagCertsConfigCheck",
"result": "ERROR",
"uuid": "38ada44b-ded5-4ae9-9365-6d171bc5b0fa",
"when": "20220427040032Z",
"duration": "0.193909",
"kw": {
"key": "kra_transport",
"nickname": "transportCert cert-pki-kra",
"directive": "kra.transport.cert",
"configfile": "/var/lib/pki/pki-tomcat/kra/conf/CS.cfg",
"msg": "Certificate 'transportCert cert-pki-kra' does not match the value of kra.transport.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg"
}
}
{
"source": "ipahealthcheck.dogtag.ca",
"check": "DogtagCertsConfigCheck",
"result": "ERROR",
"uuid": "24b190a9-e445-47d8-9664-742ec413f18e",
"when": "20220427040033Z",
"duration": "0.471634",
"kw": {
"key": "transportCert cert-pki-kra",
"directive": "ca.connector.KRA.transportCert",
"configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg",
"msg": "Certificate 'transportCert cert-pki-kra' does not match the value of ca.connector.KRA.transportCert in /var/lib/pki/pki-tomcat/conf/ca/CS.cfg"
}
}
# getcert list -d /etc/pki/pki-tomcat/alias -n 'transportCert cert-pki-kra'
Number of certificates and requests being tracked: 12.
Request ID '20210518174640':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='transportCert cert-pki-kra',token='NSS Certificate DB',pin set
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='transportCert cert-pki-kra',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
subject: CN=KRA Transport Certificate,O=IPA.EXAMPLE.COM
expires: 2023-03-31 21:42:06 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-clientAuth
profile: caTransportCert
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "transportCert cert-pki-kra"
track: yes
auto-renew: yes
# certutil -d /etc/pki/pki-tomcat/alias -L -n 'transportCert cert-pki-kra' -a | openssl x509 -noout -issuer -serial -subject -dates
issuer=O = IPA.EXAMPLE.COM, CN = Certificate Authority
serial=2FFF000B
subject=O = IPA.EXAMPLE.COM, CN = KRA Transport Certificate
notBefore=Apr 10 21:42:06 2021 GMT
notAfter=Mar 31 21:42:06 2023 GMT
# crudini --get /etc/pki/pki-tomcat/kra/CS.cfg '' kra.transport.cert | base64 -d | openssl x509 -inform der -noout -issuer -serial -subject -dates
issuer=O = IPA.EXAMPLE.COM, CN = Certificate Authority
serial=0B
subject=O = IPA.EXAMPLE.COM, CN = KRA Transport Certificate
notBefore=Mar 18 00:15:01 2019 GMT
notAfter=Mar 7 00:15:01 2021 GMT
# crudini --get /var/lib/pki/pki-tomcat/conf/ca/CS.cfg '' ca.connector.KRA.transportCert | base64 -d | openssl x509 -inform der -noout -issuer -serial -subject -dates
issuer=O = IPA.EXAMPLE.COM, CN = Certificate Authority
serial=0B
subject=O = IPA.EXAMPLE.COM, CN = KRA Transport Certificate
notBefore=Mar 18 00:15:01 2019 GMT
notAfter=Mar 7 00:15:01 2021 GMT
{
"source": "pki.server.healthcheck.meta.csconfig",
"check": "KRADogtagCertsConfigCheck",
"result": "ERROR",
"uuid": "c90d8174-bf9d-4efe-a24c-4e4ece90d7f9",
"when": "20220427040032Z",
"duration": "0.256320",
"kw": {
"key": "kra_storage",
"nickname": "storageCert cert-pki-kra",
"directive": "kra.storage.cert",
"configfile": "/var/lib/pki/pki-tomcat/kra/conf/CS.cfg",
"msg": "Certificate 'storageCert cert-pki-kra' does not match the value of kra.storage.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg"
}
}
# getcert list -d /etc/pki/pki-tomcat/alias -n 'storageCert cert-pki-kra'
Number of certificates and requests being tracked: 12.
Request ID '20210518174641':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert cert-pki-kra',token='NSS Certificate DB',pin set
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert cert-pki-kra',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
subject: CN=KRA Storage Certificate,O=IPA.EXAMPLE.COM
expires: 2023-03-31 21:42:23 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-clientAuth
profile: caStorageCert
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "storageCert cert-pki-kra"
track: yes
auto-renew: yes
# certutil -d /etc/pki/pki-tomcat/alias -L -n 'storageCert cert-pki-kra' -a | openssl x509 -noout -issuer -serial -subject -dates
issuer=O = IPA.EXAMPLE.COM, CN = Certificate Authority
serial=2FFF000D
subject=O = IPA.EXAMPLE.COM, CN = KRA Storage Certificate
notBefore=Apr 10 21:42:23 2021 GMT
notAfter=Mar 31 21:42:23 2023 GMT
# crudini --get /etc/pki/pki-tomcat/kra/CS.cfg '' kra.storage.cert | base64 -d | openssl x509 -inform der -noout -issuer -serial -subject -dates
issuer=O = IPA.EXAMPLE.COM, CN = Certificate Authority
serial=0C
subject=O = IPA.EXAMPLE.COM, CN = KRA Storage Certificate
notBefore=Mar 18 00:15:01 2019 GMT
notAfter=Mar 7 00:15:01 2021 GMT
{
"source": "pki.server.healthcheck.meta.csconfig",
"check": "KRADogtagCertsConfigCheck",
"result": "ERROR",
"uuid": "95187b54-782d-455f-8dae-39d6eaee71e5",
"when": "20220427040033Z",
"duration": "0.319186",
"kw": {
"key": "kra_audit_signing",
"nickname": "auditSigningCert cert-pki-kra",
"directive": "kra.audit_signing.cert",
"configfile": "/var/lib/pki/pki-tomcat/kra/conf/CS.cfg",
"msg": "Certificate 'auditSigningCert cert-pki-kra' does not match the value of kra.audit_signing.cert in /var/lib/pki/pki-tomcat/kra/conf/CS.cfg"
}
}
# getcert list -d /etc/pki/pki-tomcat/alias -n 'auditSigningCert cert-pki-kra'
Number of certificates and requests being tracked: 12.
Request ID '20210518174639':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-kra',token='NSS Certificate DB',pin set
certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-kra',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
subject: CN=KRA Audit,O=IPA.EXAMPLE.COM
expires: 2023-03-31 21:42:08 UTC
key usage: digitalSignature,nonRepudiation
profile: caAuditSigningCert
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-kra"
track: yes
auto-renew: yes
# certutil -d /etc/pki/pki-tomcat/alias -L -n 'auditSigningCert cert-pki-kra' -a | openssl x509 -noout -issuer -serial -subject -dates
issuer=O = IPA.EXAMPLE.COM, CN = Certificate Authority
serial=2FFF000C
subject=O = IPA.EXAMPLE.COM, CN = KRA Audit
notBefore=Apr 10 21:42:08 2021 GMT
notAfter=Mar 31 21:42:08 2023 GMT
# crudini --get /etc/pki/pki-tomcat/kra/CS.cfg '' kra.audit_signing.cert | base64 -d | openssl x509 -inform der -noout -issuer -serial -subject -dates
issuer=O = IPA.EXAMPLE.COM, CN = Certificate Authority
serial=0D
subject=O = IPA.EXAMPLE.COM, CN = KRA Audit
notBefore=Mar 18 00:15:02 2019 GMT
notAfter=Mar 7 00:15:02 2021 GMT
I'm really not clear exactly what is supposed to be taking the
certificates from the NSS database and updating CS.cfg. At first I
thought it was the renew_ca_cert script, but looking into the code, it
only seems to update CS.cfg for 'caSigningCert cert-pki-ca'.
(Regarding that, there's maybe another issue to solve here. The CA's
CS.cfg file has subsystem.select=Clone; it looks like that will cause
renew_ca_cert to not update CS.cfg when the CA certificate renews in the
distant future. Should I edit CS.cfg by hand, or maybe promote another
server to be the CA renewal master, and see if subsystem.select is set
properly on that server once it's promoted?)
Anyway. The funny thing about all this is that all these certificates
expired last year. And I am pretty sure I used the ipa vault commands a
couple of weeks ago. So perhaps the problem is actually elsewhere, and
I don't know how to debug the PKI server any further, so...
1. Are the expired certs in CS.cfg causing the problem?
2. Which bit of FreeIPA updates the certificate copies in CS.cfg?
3. Where do I look to debug the PKI server further?
As always, I'm grateful for any assistance, thanks :)
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
3 weeks, 6 days
Re: Strategy to renew TGT - any thoughts?
by Eric Ashley
Hi Francis,
I think with a minor change of logic this issue is rather simple with a
bit of scripting and some user training. Rather than getting a new
ticket after the old one expires, look for a ticket that expires within
X minutes where your other renewal criteria are still met. While that
original ticket is active, issue a 'kinit -R' for the user principal.
Obviously if your ticket is approaching the end of it's renewable life,
you have your original problem again which is where the user training
comes into play. To address that I'd ensure that a) the renewal lifetime
is long enough to run your longest running long job plus one day (or 3
if some long jobs are started on a Friday with no operators available
for the weekend) and b) you have users who execute these kinds of jobs
get a new ticket the next work day even if, but especially if, a job is
still running). That should cover almost all cases. If you can tell the
difference between one of these long jobs and regular interactive
activity, you can notify the use (or just flat execute kinit for them)
since there are at the computer to answer any prompts for renewal.
After adjusting the renewal lifetimes for user tickets, I'd create a
script that does this renewal then executes all the remaining user
parameters. In the script if the 'kinit -R' fails execute a regular
kinit for the principal in use. Train your uses to always start their
jobs with this script rather an directly invoking the jobs and they'll
always be running the job in an environment where they have enough time
to execute the job under a valid ticket that the user has just renewed
or they'll be back to the computer before the current one expires to get
a new one of the job run takes days. That should handle all the cases
except one like the user starting a long job and leaving for long
holiday. If you still use a system script to renew almost expired
tickets with jobs running, you would even handle that case.
To everyone else, thanks for all the great effort on FreeIPA. It has
been a fantastic addition to my little network.
Best regards,
Eric
4 weeks
AD Trust with multiple replicas
by Cyrus
Hello!,
I'm looking to deploy a multisite setup of FreeIPA, it would be 4
sites and 2 nodes per site. Alongside FreeIPA, there will also be:
- a pair of Samba4 controllers per site that I would like to setup trust with
- sites 5 & 6 from a third party running Windows 2019 AD (single
domain, DR setup), with which I also need to setup an AD trust.
Is it required that my 8 replicas establish trust with all Samba4 and
Windows 2019 servers?
Regards,
CI.-
4 weeks