FreeIPA-users March 2024

freeipa-users@lists.fedorahosted.org

32 participants
52 discussions

Re: Using ipa-ca-install on a replica
by Ian Kumlien 21 Mar '24

21 Mar '24

On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien <ian.kumlien(a)gmail.com> wrote: > > On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud <flo(a)redhat.com> wrote: > > > > Hi, > > > > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien <ian.kumlien(a)gmail.com> wrote: > >> > >> On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien <ian.kumlien(a)gmail.com> wrote: > >> > > >> > So... this one's new: > >> > > >> > Connection to https://freeipa-1.xerces.lan/ipa/json failed with > >> > Insufficient access: SASL(-1): generic failure: GSSAPI Error: > >> > Unspecified GSS failure. Minor code may provide more information > >> > (Credential cache is empty) > > > > > > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore. > > Ah, ok, i did do kdestroy -A but only on the new machine... > > A new issue that appeared, no user from the old machines can > authenticate at all - still looking in to why it doesn't work Disabling MS-PAC fixed this issue, will have to dig in to why it was later =) Any clues? > > flo > >> > >> > --- > >> > > >> > Just haven't seen it before... and it seems like the replica can't > >> > install, unlike the two that worked before... > >> > >> And all of the sudden it just works again... weird... > >>

3 9

ipa-getkeytab fails
by Dmitry Krasov 21 Mar '24

21 Mar '24

Hello. Centos 9 client Trying get new keytab from ipa (ubuntu), by this command (after kinit): ipa-getkeytab -s ipa.dom.loc -p host/clienthost.l3874.ru -k /etc/krb5.keytab Failed to get key table file "update-crypto-policies --set DEFAULT:AD-SUPPORT-LEGACY" doesn't help On ubuntu clients " ipa-getkeytab --permitted-enctypes" shows: AES-256 CTS mode with 96-bit SHA-1 HMAC AES-128 CTS mode with 96-bit SHA-1 HMAC AES-256 CTS mode with 192-bit SHA-384 HMAC AES-128 CTS mode with 128-bit SHA-256 HMAC Triple DES cbc mode with HMAC/sha1 ArcFour with HMAC/md5 Camellia-128 CTS mode with CMAC Camellia-256 CTS mode with CMAC But on Centos 9 are AES types only. How can I add other 4 types?

1 0

Re: Cannot enroll a 4.9 client to 4.10 server fails with PrincipalName not found
by Rob Crittenden 20 Mar '24

20 Mar '24

Kroon PC, Peter via FreeIPA-users wrote: > Thanks for the super fast reply! I'll do my best to reply in-line, but I'm bound to outlook, which doesn't like it too much. > >>> 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. > > It didn't complain /too/ much honestly. It saw the version mismatch between the backup and the installed server, asked for a "yes", and then happily went on its way. Is there a better way to achieve what I want/need? Create a replica and disconnect it from the topology to have a sandbox. >>> 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. > > Ok. Is there any other place I can look for what's going wrong? The server httpd error log should have something about the request as well as the client install log. To get more details on the server side you can create /etc/ipa/server.conf with the contents: [global] debug = True Then restart httpd. Warning, it can be very verbose so I wouldn't leave it like that for long in production. rob

2 1

missing attribute "sambaGroupType" when attempting to create a new group - creating groups worked previously
by Tom Spettigue 19 Mar '24

19 Mar '24

Hey all - I seem to be getting the following error message whenever I try to create a group via the web interface: ``` IPA Error 4205: ObjectclassViolation missing attribute "sambaGroupType" required by object class "sambaGroupMapping" ``` I'm not sure exactly what's happening, except that I know I've created groups numerous times before, and never gotten this error message. Does anyone have any ideas?

1 2

Using ipa-ca-install on a replica
by Ian Kumlien 19 Mar '24

19 Mar '24

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.fedorahos… 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 8

Support for Azure AD authentication with on-prem AD forest-trust identities
by Jonathan Calmels 15 Mar '24

15 Mar '24

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-ou…. Also, another way around this could be to support WHfB / Cloud Kerberos trust on Linux, but this is somewhat orthogonal to the above.

3 9

Re: Cannot enroll a 4.9 client to 4.10 server fails with PrincipalName not found
by Rob Crittenden 15 Mar '24

15 Mar '24

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 1

Cannot enroll a 4.9 client to 4.10 server fails with PrincipalName not found
by Kroon PC, Peter 15 Mar '24

15 Mar '24

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

1 0

Failed FreeIPA replica installation
by D S 15 Mar '24

15 Mar '24

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'>

3 11

Re: ipa-setup-ca
by Pagan, Omar 15 Mar '24

15 Mar '24

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]

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users March 2024