Using ipa-ca-install on a replica
by Ian Kumlien
Hi,
So i have spent quite some time trying to get out of the swamp that is
centos stream 8 and back to something with a actual upgrade path,
fedora =)
Everything works except the ipa-ca-install on the replica - mostly
fails at the same step
At some point the conncheck failed, dropping me in to a prompt asking
for the password of a admin-<machine> account
Anyway, I do know about the issue with - vs _ and validated on master,
changed on replica as detailed here:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...
But it still fails..
Oh and btw, none of the machines are running any firewalls =)
Anyone that has a clue of what to test next?
Btw, it's 4.9 to 4.11 if there is other issues with interoperability
ipa-ca-install --skip-conncheck
Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
[1/28]: creating certificate server db
[2/28]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 7 seconds elapsed
Update succeeded
[3/28]: creating ACIs for admin
[4/28]: creating installation admin user
ipaserver.install.dogtaginstance: ERROR Unable to log in as
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
ldap://freeipa-1.xerces.lan:389
[error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
did not replicate to ldap://freeipa-1.xerces.lan:389
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Unexpected error - see /var/log/ipareplica-ca-install.log for details:
NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
replicate to ldap://freeipa-1.xerces.lan:389
And the log says:
2024-03-11T15:00:24Z DEBUG [4/28]: creating installation admin user
2024-03-11T15:00:24Z DEBUG Waiting 300 seconds for
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca to appear on
ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z ERROR Unable to log in as
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z INFO [hint] tune with replication_wait_timeout
2024-03-11T15:05:24Z DEBUG Traceback (most recent call last):
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py",
line 686, in start_creation
run_step(full_msg, method)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py",
line 672, in run_step
method()
File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py",
line 789, in setup_admin
raise errors.NotFound(
ipalib.errors.NotFound:
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to
ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z DEBUG [error] NotFound:
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not replicate to
ldap://freeipa-1.xerces.lan:389
2024-03-11T15:05:24Z DEBUG Removing /root/.dogtag/pki-tomcat/ca
2024-03-11T15:05:24Z DEBUG File
"/usr/lib/python3.12/site-packages/ipaserver/install/installutils.py",
line 781, in run_script
return_value = main_function()
^^^^^^^^^^^^^^^
File "/usr/sbin/ipa-ca-install", line 320, in main
install(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 286, in install
install_replica(safe_options, options)
File "/usr/sbin/ipa-ca-install", line 214, in install_replica
ca.install(True, config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py",
line 354, in install
install_step_0(standalone, replica_config, options, custodia=custodia)
File "/usr/lib/python3.12/site-packages/ipaserver/install/ca.py",
line 422, in install_step_0
ca.configure_instance(
File "/usr/lib/python3.12/site-packages/ipaserver/install/cainstance.py",
line 505, in configure_instance
self.start_creation(runtime=runtime)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py",
line 686, in start_creation
run_step(full_msg, method)
File "/usr/lib/python3.12/site-packages/ipaserver/install/service.py",
line 672, in run_step
method()
File "/usr/lib/python3.12/site-packages/ipaserver/install/dogtaginstance.py",
line 789, in setup_admin
raise errors.NotFound(
2024-03-11T15:05:24Z DEBUG The ipa-ca-install command failed,
exception: NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
did not replicate to ldap://freeipa-1.xerces.lan:389
2 months, 2 weeks
Support for Azure AD authentication with on-prem AD forest-trust identities
by Jonathan Calmels
We have several deployments of RHEL IdM consisting of a cross-forest trust with on-prem MS Active Directory.
Users are able to login to the IdM resources with their Corporate AD credentials (i.e. password or existing AD ticket).
Users identities (including Posix attributes) are fetched from AD along with all their group information.
Recently we've had the need to support Azure AD authentication motivated by several factors such as cloud-joined clients and FIDO2 requirements.
In our case, Azure AD is partially synced with the on-prem AD through Azure AD connect.
Given our current deployments how can we achieve this?
Namely, how can we support AAD authentication on top of our current authentication with our user identities sourced from on-prem AD?
The first thing that comes to mind is the external IdP integration in IPA, however given the nature of its implementation, this requires that IdP identities are managed through IdM.
So what we need is effectively a way to link an IdM user (referenced by the IdP association) to an external trust user, which doesn't seem possible today.
We've tried several things, and glancing at the various software pieces of the IdM stack, this doesn't look supported. We might have missed something obvious though.
Nonetheless, the main ideas we had were:
1. Add a reference to the AD trust user in the IdM user through the use of Kerberos enterprise principals.
Here the idea is to define the IdM user (for IdP) with a canonical principal name set to the fully qualified trust user (i.e. ipa user-add idm_user --principal ad_user\\@ad_domain --idp-user-id aad_user@aad_domain)
This way SSSD could theoretically detect and use the trust user instead of the IdM one during authentication.
We've personally tried this but hit a few roadblocks (and this list is probably non-exhaustive):
- KDB returns KRB5KDC_ERR_WRONG_REALM on enterprise principals consisting of a trusted domain
- krb5_child responder would need to return the new user translation (i.e. aname_to_lname of ad_user\@ad_domain@IDM_REALM -> ad_user@ad_domain)
- To support the above, sssd_krb5_localauth_plugin would need to be aware of this specific case, or be disabled to simply strip IDM_REALM as opposed to returning the IdM user back (i.e. ad_user\@ad_domain@IDM_REALM -> idm_user)
- pam_sss would need to set PAM_USER to the result of this translation and use the resulting name for subsequent queries (similar to user hints in certificates)
- getAccountInfo would probably need tweaking too (not exactly sure)
2. Modify the trust IDView to include the IdP association and signal the fact that IdP authentication should be done through IdM and not the trusted KDC.
From there, I'm not sure how this would work on the IdM KDC side since there wouldn't be any existing principal to authenticate against (maybe matching enterprise principals could be created dynamically similar to 1.)
Hopefully there exists a simple solution for this use-case already, if not, I hope that the ask was clear enough.
Finally, note that this is somewhat related to the recent talks at FOSDEM, specifically https://fosdem.org/2024/schedule/event/fosdem-2024-2587-posix-identities-....
Also, another way around this could be to support WHfB / Cloud Kerberos trust on Linux, but this is somewhat orthogonal to the above.
2 months, 2 weeks
Re: Cannot enroll a 4.9 client to 4.10 server fails with PrincipalName not found
by Rob Crittenden
Kroon PC, Peter via FreeIPA-users wrote:
> Hi all!
>
> I'm working on updating my freeipa server from rocky 8 to 9. I'm playing around with a virtual machines as playground server and client, since I'd rather not break my everything right away. As part of this, I first installed ipa-server version 4.10.2-8.el9_3 on the server. Then I did an ipa-restore with a backup from my production ipa server (rocky 8, 4.9.12-11.module+el8.9.0+1652+4ee71f6a), followed by an ipa-server-upgrade. All is well so far (I think).
I don't know how you achieved this. ipa-restore attempts to prevent
using restore as a backdoor upgrade mechanism.
> The client is running Debian bookworm with backports, where the latest ipa-client version is 4.9.11-1. Then, I went with the usual ipa-client-install --no-ntp, which fails with "Joining realm failed: Failed to parse result: PrincipalName not found." after retrieving the CA cert.
> The logs don't tell me much more, but the --debug flag does. It negotiates a JSON-RPC response, in which it says '{... "principal": "admin(a)EXAMPLE.COM", ...}'. I note that principal != PrincipalName. Also note, that on the server, the host /is/ added.
>
> So I guess my question is: how much version skew between server and client is supported?
Plenty. There isn't much to client enrollment and the API hasn't changed
significantly in a long time.
rob
2 months, 2 weeks
Cannot enroll a 4.9 client to 4.10 server fails with PrincipalName not found
by Kroon PC, Peter
Hi all!
I'm working on updating my freeipa server from rocky 8 to 9. I'm playing around with a virtual machines as playground server and client, since I'd rather not break my everything right away. As part of this, I first installed ipa-server version 4.10.2-8.el9_3 on the server. Then I did an ipa-restore with a backup from my production ipa server (rocky 8, 4.9.12-11.module+el8.9.0+1652+4ee71f6a), followed by an ipa-server-upgrade. All is well so far (I think).
The client is running Debian bookworm with backports, where the latest ipa-client version is 4.9.11-1. Then, I went with the usual ipa-client-install --no-ntp, which fails with "Joining realm failed: Failed to parse result: PrincipalName not found." after retrieving the CA cert.
The logs don't tell me much more, but the --debug flag does. It negotiates a JSON-RPC response, in which it says '{... "principal": "admin(a)EXAMPLE.COM", ...}'. I note that principal != PrincipalName. Also note, that on the server, the host /is/ added.
So I guess my question is: how much version skew between server and client is supported?
Kind regards, and many thanks for the excellent software and support,
Peter Kroon
2 months, 2 weeks
Failed FreeIPA replica installation
by D S
Hello, I've encountered several issues while installing freeipa replica.
I have freeipa 4.6.8 master and the replica I tried installing is 4.9.12.
During the replica install it seems that the replica is unable to get a CA cert from my master:
DEBUG Configuring Kerberos KDC (krb5kdc)
DEBUG [1/1]: installing X509 Certificate for PKINIT
DEBUG flushing ldapi://%2Frun%2Fslapd-[REDACTED].socket from SchemaCache
DEBUG retrieving schema for SchemaCache url=ldapi://%2Frun%2Fslapd-[REDACTED].socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f6ac1b7d6d8>
DEBUG certmonger request is in state 'NEWLY_ADDED_READING_KEYINFO'
DEBUG certmonger request is in state 'SUBMITTING'
DEBUG certmonger request is in state 'CA_UNREACHABLE'
DEBUG Cert request 20240312144851 failed: CA_UNREACHABLE (Server at https://[REDACTED]/ipa/json failed request, will retry: 903 (an internal error has occurred).)
DEBUG Giving up on cert request 20240312144851
WARNING PKINIT certificate request failed: Certificate issuance failed (CA_UNREACHABLE: Server at https://[REDACTED]/ipa/json failed request, will retry: 903 (an internal error has occurred).)
WARNING Failed to configure PKINIT
DEBUG Full PKINIT configuration did not succeed
DEBUG The setup will only install bits essential to the server functionality
DEBUG You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
DEBUG certmonger request is in state 'GENERATING_CSR'
DEBUG certmonger request is in state 'MONITORING'
DEBUG Cert request 20240312144853 was successful
DEBUG step duration: krb5kdc setup_pkinit 2.72 sec
DEBUG Done configuring Kerberos KDC (krb5kdc).
(However the the installation succeeds with INFO The ipa-replica-install command was successful)
On master in /var/log/httpd/error_log:
ipa: ERROR: non-public: AttributeError: 'ldap2' object has no attribute 'Object'
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 369, in wsgi_execute
result = command(*args, **options)
File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 450, in __call__
return self.__do_call(*args, **options)
File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in __do_call
ret = self.run(*args, **options)
File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run
return self.execute(*args, **options)
File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 863, in execute
ca_kdc_check(ldap, alt_principal.hostname)
File "/usr/lib/python2.7/site-packages/ipaserver/plugins/cert.py", line 301, in ca_kdc_check
master_dn = api_instance.Object.server.get_dn(unicode(hostname))
AttributeError: 'ldap2' object has no attribute 'Object'
ipa: INFO: [jsonserver_kerb] host/ipa-replica01.[REDACTED]@[REDACTED]: cert_request(u'MIID3DCCAsQCAQAwQjEZMBcGA1UECgwQRkxPUkEuTFRGUy5UT09MUzElMCMGA1UEAxMcaXBhLXNsYXZlMDEuZmxvcmEubHRmcy50b29sczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANhiTu7x/3sRCBq0spuBM1M2dkAzfMFEtJRx/BUcDi7PrRhJBa+w2o+XfOjtP9YFYpnOYbqV6eNlslGuYbHYIZX5D4lawvcT+IfqBaeWAz3ZRyK+nFVotMm+BRHNeUFse3OUL2kGPLRgXZQ1wdzE+V17rTRtPHDV9cs0ERjTjMyntM24zYxWicrdsoFfwF/BJQRXVO+GZDdhJcmNvCcxywaUD8C/y9TYYLwhFdIRYFmOHvTHJwabPt5/QM8EkrAfkpCHypwf6oz7xvyiqnRFyx5okWexHqE1xXHbvMS+pjd2eNBl4n38H+hbdb83wJFS64M9zerlhU/u5h4cbY0WdIJtOz2dP7A3NvQL0X5oF10ivWYw5+Rbar8h6nCr07ApVku6m5kXePp6rK3c0f+IORxflJFEdRGBG7zBbE1Dt4Kf5Q+uTwiEjN2wEre1s6CFg8oTipncOwHkyettAplFisitfdxs4HlEZpsN3kxh6NQDFAhx4JE1WNGMPVZNKuBz6tHhMwgpDDXS16UjIXZqYllUDnBaf5GdawCgWr2wbXEaUflgOWje/QyvZkYVsHZzUFw9Bqh8B7jxw7h/4KAM43XBDWN9P6J2+gqp2M3SQ=', profile_id=u'KDCs_PKINIT_Certs', principal=u'krbtgt/[REDACTED]@[REDACTED]', add=True): InternalError
That's the issue number one. Number two is that I can't login into web UI of my replica - it gives me "Login failed due to an unknown reason" error. From /var/log/httpd/error_log:
[auth_gssapi:error] GSS ERROR gss_acquire_cred[_from]() failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ( SPNEGO cannot find mechanisms to negotiate)]
[wsgi:error] ipa: INFO: 401 Unauthorized: No session cookie found
Finally, my third issue is that I can't remove replica from my master. ipa-replica-manage del --force --cleanup fails with:
Traceback (most recent call last):
File "/usr/sbin/ipa-replica-manage", line 1624, in <module>
main(options, args)
File "/usr/sbin/ipa-replica-manage", line 1524, in main
api.finalize()
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 740, in finalize
self.__do_if_not_done('load_plugins')
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 431, in __do_if_not_done
getattr(self, name)()
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 620, in load_plugins
self.add_package(package)
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 658, in add_package
self.add_module(module)
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 675, in add_module
self.add_plugin(**kwargs)
File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 711, in add_plugin
plugin=plugin,
PluginOverrideError: unexpected override of BaseCertObject.certreq with <class 'ipaserver.plugins.cert.certreq'>
Unexpected error: unexpected override of BaseCertObject.certreq with <class 'ipaserver.plugins.cert.certreq'>
2 months, 2 weeks
Re: ipa-setup-ca
by Pagan, Omar
Not sure if they did use the external CA. How can I check?
//omar
Omar Pagan, CISSP
AAP Sr. DevOps/SysAdmin
[cid:image001.png@01DA76C3.BAE28A80]
2 months, 2 weeks
ipa: ERROR: No valid Negotiate header - from/in container replica
by lejeczek
Hi guys.
This is my first trial/test of replicas in container - here
I added a replica to already existing, bare-metal IPA
domain, which otherwise works a okey - so numerous issues
are possible.
In container, only in this replica, I get:
bash-5.1# ipa dnszone-find
ipa: ERROR: No valid Negotiate header in server response
What that is, might be, a symptom of? Where to go with
troubleshooting?
All thoughts share are much appreciated.
many thanks, L.
2 months, 2 weeks
"Internal server error 'Link'" from ClonesConnectivyAndDataCheck health check on RHEL 8 when talking to RHEL 9 server
by Sam Morris
I tracked down the source of the myserious "Internal server error
'Link'" message when running this health check. It's caused by having a
mixture of both RHEL 8 and RHEL 9 servers.
The error message in context:
# ipa-healthcheck --source=pki.server.healthcheck.clones.connectivity_and_data --check=ClonesConnectivyAndDataCheck --output-type=json --debug
[...]
stderr=
Calling check <pki.server.healthcheck.clones.connectivity_and_data.ClonesConnectivyAndDataCheck object at 0x7f8c87e8cf60>
[...]
About to check the subsystem clones
Starting new HTTPS connection (1): ipa3.example.com:443
https://ipa3.example.com:443 "POST /ca/rest/certs/search?size=3 HTTP/1.1" 200 431
Cert data successfully obtained from clone.
Starting new HTTPS connection (1): ipa5.example.com:443
https://ipa5.example.com:443 "POST /ca/rest/certs/search?size=3 HTTP/1.1" 200 431
Cert data successfully obtained from clone.
Starting new HTTPS connection (1): ipa6.example.com:443
https://ipa6.example.com:443 "POST /ca/rest/certs/search?size=3 HTTP/1.1" 200 317
Internal server error 'Link'
[...]
[
{
"source": "pki.server.healthcheck.clones.connectivity_and_data",
"check": "ClonesConnectivyAndDataCheck",
"result": "ERROR",
"uuid": "f672f185-6251-47e9-a772-8f9796a34986",
"when": "20240312021736Z",
"duration": "0.521790",
"kw": {
"status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: ipa6.example.com Port: 443"
}
}
]
I edited ClonesConnectivyAndDataCheck.check_ca_clones to call
logger.exception in its BaseException handler instead of just
logger.error. This logs the traceback of the original exception:
Internal server error 'Link'
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/pki/server/healthcheck/clones/connectivity_and_data.py", line 35, in check_ca_clones
certs = cert_client.list_certs(size=3)
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/cert.py", line 674, in list_certs
return CertDataInfoCollection.from_json(response.json())
File "/usr/lib/python3.6/site-packages/pki/cert.py", line 179, in from_json
links = json_value['Link']
KeyError: 'Link'
I guess the newer version of Dogtag in RHEL 9 doesn't include this
"Link" attribute, but pki.cert:CertDataInfoCollection.from_json in RHEL
8 expects it to be present.
--
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
2 months, 2 weeks
ipa-getcert request results in CA_REJECTED, on an enrolled host
by Bo Lind
I'm having a weird one. This has worked well on a number of other, identical hosts, but one is repeatedly giving me trouble:
root@naughtyhost:~# ipa-getcert request -f /etc/pki/tls/certs/xrdp.pem -k /etc/pki/tls/private/xrdp.key -r -w -v
New signing request "20240312125107" added.
State NEWLY_ADDED_READING_KEYINFO, stuck: no.
State SUBMITTING, stuck: no.
State CA_REJECTED, stuck: yes.
root@naughtyhost:~# ipa-getcert list
Number of certificates and requests being tracked: 1.
Request ID '20240312125107':
status: CA_REJECTED
ca-error: Server at https://idm0.example.local/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 empty)).
stuck: yes
key pair storage: type=FILE,location='/etc/pki/tls/private/xrdp.key'
certificate: type=FILE,location='/etc/pki/tls/certs/xrdp.pem'
CA: IPA
issuer:
subject:
issued: unknown
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
I've tried looking in the logfiles on idm0, but couldn't really find anything useful.
2 months, 2 weeks