May 2023 - FreeIPA-users - Fedora mailing-lists

Re: Authentication failures on a RHEL 9.2 IPA server
by Rob Crittenden 15 May '23

15 May '23

Charles Hedrick via FreeIPA-users wrote: > OK, so I see the answer to my problem is to run > > ipa config-mod --add-sids --enable-sid > > But we have old UIDs that with low numbers. It looks like I need to do > > ipa idrange-add CS.RUTGERS.EDU_low_id_range --base-id=1 > --range-size=200000 --rid-base=200000000 --secondary-rid-base=300000000 > ipa idrange-add CS.RUTGERS.EDU_mid_id_range --base-id=600000 > --range-size=200000 --rid-base=400000000 --secondary-rid-base=500000000 > > In order for ipa user-add for those UIDs to work on any system, > presumably I have to do that on all IPA servers. Is that OK? I'm > assuming new id's where we don't specify a UID will be put in the same > range before, which is different on each server. Ranges are global, not per-server. So assuming your ranges are ok and there are no overlaps for the IDs or RID ranges this is probably ok, but I'm not a PAC expert. I think what you're seeing is the DNA (Distributed Numeric Assignment) plugin at work. On the first installed server, DNA has the full range of id_range values to generate UIDs and GIDs. The first time a replica needs to generate a UID/GID it requests a range and gets half of the allocation. A replica does not automatically get a range on install. The more servers you have AND the more replicas you've added entries on, the smaller the available ranges may be. You can use ipa-replica-manage to display and manipulate the ranges. rob > > > > > > ------------------------------------------------------------------------ > *From:* Sam Morris via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> > *Sent:* Monday, May 15, 2023 8:08 AM > *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > *Cc:* Alexander Bokovoy <abokovoy(a)redhat.com>; Sam Morris > <sam(a)robots.org.uk> > *Subject:* [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA > server > > On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via > FreeIPA-users wrote: >> On su, 14 touko 2023, Sam Morris wrote: >> > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote: >> > > I wonder about the root cause; is this because MIT Kerberos 1.20 always >> > > wants to include a PAC in its issued TGTs, and it gives up if it can't >> > > retrieve a user's SID from the directory? (If so I wonder if setting >> > > disable_pac = true in the realm section of krb5.conf would have worked >> > > around the problem?) >> > >> > This seems to be the case. Specifically I: >> > >> > 1. Removed the ipantsecurityidentifier attribute from a user, and >> > removed ipantuserattrs from the user's objectclass >> > 2. Tried to log in as the user & got the same failures + 'No such file >> > or directory' message in /var/log/krb5kdc.log >> > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' >> > within the realm-specific configuration in the realms section >> > 4. Restarted krb5kdc >> > 5. Tried to log in as the user and it worked! >> > >> > The docs for disable_pac say: >> > >> > If true, the KDC will not issue PACs for this realm, and S4U2Self >> > and S4U2Proxy operations will be disabled. The default is false, >> > which will permit the KDC to issue PACs. New in release 1.20. >> > >> > ... which doesn't explain that if the KDC can't issue a PAC for some >> > reason then the KDC will fail to issue the TGT. But at least I've gotten >> > to the bottom of things now. :) >> >> RHEL IdM documentation has a separate chapter related to it. >> >> RHEL 9: >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/ht… >> >> RHEL 8: >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht… >> >> This documentation is in place since summer 2022. > > Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos > in IdM requires that your IdM objects have SIDs, which are necessary for > security based on Privilege Access Certificate (PAC) information.", but > I had no problems with authentication on my RHEL 8.6/8.7 servers... > >> > > "After upgrading, krb5kdc may fail to issue TGTs to users who have not >> > > had a SID assigned to their accounts ('ipa user-show user --all' will >> > > not include an ipantsecurityidentifier attribute). In this case >> > > krb5kdc.log will log a message "HANDLE_AUTHDATA: user(a)EXAMPLE.COM for >> > > krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, No such file or directory". This can be >> > > fixed by running 'ipa config-mod --enable-sid --add-sids' as an IPA >> > > admin on another IPA server." >> > >> > ... "or on the same server after temporarily setting "disable_pac = >> > true" in kdc.conf, and restarting krb5kdc." >> >> You should not be disabling PAC because you are really setting yourself >> up to an attack with a known exploit out in a wild. > > Absolutely--I just wanted to document what I'd found out, because there > isn't a clear connection documented between the behaviour in RHEL 9.2 > with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't > have SIDs assigned. > > -- > Sam Morris <https://robots.org.uk/> > PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue >

2 1

Re: can't kinit after upgrade to redhat 9.2
by Sam Morris 15 May '23

15 May '23

On 15/05/2023 19:00, Charles Hedrick via FreeIPA-users wrote: > I just upgraded from redhat 9.0 to 9.2 on a set of kerberos servers, > fortunately a test system. I can't kinit as existing users. If I add a > user I can kinit as them. Changing the password doesn't help. krb5kdc says > > > May 15 13:58:30 krb1.cs.rutgers.edu krb5kdc[652884](info): AS_REQ (4 > etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), > aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) > 128.6.157.187: HANDLE_AUTHDATA: clh(a)CS.RUTGERS.EDU for > kadmin/changepw(a)CS.RUTGERS.EDU, No such file or directory > > The only difference I see in ldap attributes between the existing and > new user is that the new user has > ipaNTSecurityIdentifier: S-1-5-21-3719230765-1403434741-3275474567-88461 > and > objectClass: ipantuserattrs > > We are not using anything Windows-related You need to run 'ipa config-mod --enable-sid --add-sids' on one of your servers. See <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/ht…>. -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

1 0

Re: Authentication failures on a RHEL 9.2 IPA server
by Rob Crittenden 15 May '23

15 May '23

Charles Hedrick via FreeIPA-users wrote: > is there a way to do a bulk update of existing users? We have this > issue. I can disable the pac, but that might not be a good long term > solution It's in section 12.2 of the linked RHEL 9 documentation. rob > ------------------------------------------------------------------------ > *From:* Sam Morris via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> > *Sent:* Monday, May 15, 2023 8:08 AM > *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > *Cc:* Alexander Bokovoy <abokovoy(a)redhat.com>; Sam Morris > <sam(a)robots.org.uk> > *Subject:* [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA > server > > On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via > FreeIPA-users wrote: >> On su, 14 touko 2023, Sam Morris wrote: >> > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote: >> > > I wonder about the root cause; is this because MIT Kerberos 1.20 always >> > > wants to include a PAC in its issued TGTs, and it gives up if it can't >> > > retrieve a user's SID from the directory? (If so I wonder if setting >> > > disable_pac = true in the realm section of krb5.conf would have worked >> > > around the problem?) >> > >> > This seems to be the case. Specifically I: >> > >> > 1. Removed the ipantsecurityidentifier attribute from a user, and >> > removed ipantuserattrs from the user's objectclass >> > 2. Tried to log in as the user & got the same failures + 'No such file >> > or directory' message in /var/log/krb5kdc.log >> > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true' >> > within the realm-specific configuration in the realms section >> > 4. Restarted krb5kdc >> > 5. Tried to log in as the user and it worked! >> > >> > The docs for disable_pac say: >> > >> > If true, the KDC will not issue PACs for this realm, and S4U2Self >> > and S4U2Proxy operations will be disabled. The default is false, >> > which will permit the KDC to issue PACs. New in release 1.20. >> > >> > ... which doesn't explain that if the KDC can't issue a PAC for some >> > reason then the KDC will fail to issue the TGT. But at least I've gotten >> > to the bottom of things now. :) >> >> RHEL IdM documentation has a separate chapter related to it. >> >> RHEL 9: >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/ht… >> >> RHEL 8: >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht… >> >> This documentation is in place since summer 2022. > > Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos > in IdM requires that your IdM objects have SIDs, which are necessary for > security based on Privilege Access Certificate (PAC) information.", but > I had no problems with authentication on my RHEL 8.6/8.7 servers... > >> > > "After upgrading, krb5kdc may fail to issue TGTs to users who have not >> > > had a SID assigned to their accounts ('ipa user-show user --all' will >> > > not include an ipantsecurityidentifier attribute). In this case >> > > krb5kdc.log will log a message "HANDLE_AUTHDATA: user(a)EXAMPLE.COM for >> > > krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, No such file or directory". This can be >> > > fixed by running 'ipa config-mod --enable-sid --add-sids' as an IPA >> > > admin on another IPA server." >> > >> > ... "or on the same server after temporarily setting "disable_pac = >> > true" in kdc.conf, and restarting krb5kdc." >> >> You should not be disabling PAC because you are really setting yourself >> up to an attack with a known exploit out in a wild. > > Absolutely--I just wanted to document what I'd found out, because there > isn't a clear connection documented between the behaviour in RHEL 9.2 > with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't > have SIDs assigned. > > -- > Sam Morris <https://robots.org.uk/> > PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9 > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue >

1 0

can't kinit after upgrade to redhat 9.2
by Charles Hedrick 15 May '23

15 May '23

I just upgraded from redhat 9.0 to 9.2 on a set of kerberos servers, fortunately a test system. I can't kinit as existing users. If I add a user I can kinit as them. Changing the password doesn't help. krb5kdc says May 15 13:58:30 krb1.cs.rutgers.edu krb5kdc[652884](info): AS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 128.6.157.187: HANDLE_AUTHDATA: clh(a)CS.RUTGERS.EDU for kadmin/changepw(a)CS.RUTGERS.EDU, No such file or directory The only difference I see in ldap attributes between the existing and new user is that the new user has ipaNTSecurityIdentifier: S-1-5-21-3719230765-1403434741-3275474567-88461 and objectClass: ipantuserattrs We are not using anything Windows-related

1 0

ipa migrate-ds - From EL7 to EL8/9
by Finn Fysj 15 May '23

15 May '23

Planning to migrate users and groups from an old dusty IPA server running Red Hat Enterprise Linux 7 to RHEL9. I'm aware of SID issues from following thread: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahos… Should I ignore the attribute `ipaNTSecurityIdentifier` when migrating from old to new instance?

2 3

When a cert-profile doesn't exist and can't see it but IPA thinks it does - how to correct?
by Nicholas Cross 15 May '23

15 May '23

We found that we have a cert profile that was deleted in the ui and then we attempted to re-create it, but it will not. ipa: ERROR: Request failed with status 409: Non-2xx response from CA REST API: 409. Unable to create profile: Profile already exists The profile does not show in the UI or via the CLI $ ipa certprofile-find controlServersKubeAPIClustertest1 <blank> $ ipa certprofile-show controlServersKubeAPIClustertest1 <blank> But when checking ldap itself we can see it. $ ldapsearch -LLL -o ldif-wrap=no -w $pass -D 'cn=Directory Manager' -b 'o=ipaca' | grep controlServersKubeAPIClustertest1 dn: cn=controlServersKubeAPIClustertest1,ou=certificateProfiles,ou=ca,o=ipaca cn: controlServersKubeAPIClustertest1 extdata-profileid: controlServersKubeAPIClustertest1 metaInfo: profileId:controlServersKubeAPIClustertest1 extdata-profileid: controlServersKubeAPIClustertest1 metaInfo: profileId:controlServersKubeAPIClustertest1 extdata-profileid: controlServersKubeAPIClustertest1 metaInfo: profileId:controlServersKubeAPIClustertest1 extdata-profileid: controlServersKubeAPIClustertest1 metaInfo: profileId:controlServersKubeAPIClustertest1 extdata-profileid: controlServersKubeAPIClustertest1 metaInfo: profileId:controlServersKubeAPIClustertest1 Apart from doing an ldapdelete on that dn: , is there a better way to clean up that "ghost" cert profile? (and the corresponding certs?) thanks, Nick

2 1

Best practices for upgrading when running dockerized FreeIPA
by Sebastiano Pomata 14 May '23

14 May '23

Hi all, I successfully deployed a FreeIPA installation with a master server and two replicas using podman and the container images provided on docker.io (specifically, those based on fedora 36) on RHEL 8. Time has passed (indeed flied) and fedora 36 is now about to reach end of security support and I started thinking about upgrading to either the 4.10 freeipa based on fedora 38 or the one based on RHEL 9. Whatever the final choice, I wonder what's the recommended path to follow? I remember having asked in the past on the freeipa IRC channel and the most common suggestion was to avoid mounting the same ipa-data directory under a new, upgraded container image, but rather creating a new replica directly based on the updated container image. This is very sensible however now I'm faced with a practical issue on the steps to take: assuming I wanted to upgrade the master and two replicas from 4.9 to 4.10 one by one, shall I create a temporary replica under a new hostname (and same IP), delete the old replica from topology and bring its container down, then re-create a new replica with the proper previous hostname? Or just give up on the old hostname and stick with the new one for the upgraded replica? As I manage the installation with SRV records from DNS, ditching the old name for a new one doesn't seem painful, however we have some services that rely on the LDAP hostname of the current IPA servers and would still require manual upgrade. DNS is not managed by FreeIPA but externally on another server, which I fully control. Hope my question is clear and somebody who dealt with upgrades more often can provide some feedback. Thanks Regards

2 5

SSSD Log stops working - Backtrafe dump ends here
by Finn Fysj 12 May '23

12 May '23

I've tried to install and re-install the IPAserver on my node. Even tried to re-provision it. When I look in the SSSD log for my domain I get the following: * (2023-05-04 6:30:59): [be[lab.local]] [sdap_get_generic_ext_step] (0x2000): [RID#16] ldap_search_ext called, msgid = 48 * (2023-05-04 6:30:59): [be[lab.local]] [sdap_op_add] (0x2000): [RID#16] New operation 48 timeout 60 * (2023-05-04 6:30:59): [be[lab.local]] [sdap_process_result] (0x2000): Trace: sh[0x560c8dff6e30], connected[1], ops[0x560c8e064050], ldap[0x560c8e0abcc0] * (2023-05-04 6:30:59): [be[lab.local]] [sdap_process_result] (0x2000): Trace: end of ldap_result list * (2023-05-04 6:30:59): [be[lab.local]] [sdap_process_result] (0x2000): Trace: sh[0x560c8dff6e30], connected[1], ops[0x560c8e064050], ldap[0x560c8e0abcc0] * (2023-05-04 6:30:59): [be[lab.local]] [sdap_process_message] (0x4000): [RID#16] Message type: [LDAP_RES_SEARCH_RESULT] * (2023-05-04 6:30:59): [be[lab.local]] [sdap_get_generic_op_finished] (0x0400): [RID#16] Search result: Success(0), no errmsg set * (2023-05-04 6:30:59): [be[lab.local]] [sdap_get_generic_op_finished] (0x2000): [RID#16] Total count [0] * (2023-05-04 6:30:59): [be[lab.local]] [sdap_op_destructor] (0x2000): [RID#16] Operation 48 finished * (2023-05-04 6:30:59): [be[lab.local]] [ipa_hbac_rule_info_done] (0x0400): [RID#16] No rules apply to this host * (2023-05-04 6:30:59): [be[lab.local]] [sdap_id_op_done] (0x4000): [RID#16] releasing operation connection * (2023-05-04 6:30:59): [be[lab.local]] [ipa_pam_access_handler_done] (0x0020): [RID#16] No HBAC rules found, denying access ********************** BACKTRACE DUMP ENDS HERE ********************************* (2023-05-04 6:39:00): [be[lab.local]] [orderly_shutdown] (0x3f7c0): SIGTERM: killing children (2023-05-04 6:39:00): [be[lab.local]] [orderly_shutdown] (0x3f7c0): Shutting down (status = 0)(2023-05-04 6:39:00): [be[lab.local]] [server_setup] (0x3f7c0): Starting with debug level = 0x0070 (2023-05-04 6:41:04): [be[lab.local]] [orderly_shutdown] (0x3f7c0): SIGTERM: killing children (2023-05-04 6:41:04): [be[lab.local]] [orderly_shutdown] (0x3f7c0): Shutting down (status = 0)(2023-05-04 6:41:04): [be[lab.local]] [server_setup] (0x3f7c0): Starting with debug level = 0x0070 (2023-05-04 6:43:33): [be[lab.local]] [orderly_shutdown] (0x3f7c0): SIGTERM: killing children (2023-05-04 6:43:33): [be[lab.local]] [orderly_shutdown] (0x3f7c0): Shutting down (status = 0)(2023-05-04 6:43:33): [be[lab.local]] [server_setup] (0x3f7c0): Starting with debug level = 0x0070 I tried to turn the debug_level = 8 and 9, without any good results. The look doesn't change when I try to login or run any "privileged" commands.

3 3

Free-IPA to RHEL IPA: ipa-crlgen-manage not present, manual options
by John Burns 10 May '23

10 May '23

Greetings! Can the actions within the two commands below can be done manually (outside the RPM)? ipa-crlgen-manage status ipa-crlgen-manage disable Context: I inherited an old Centos IPA cluster, centered on VMs. Suboptimal, given that the VM datastore itself is NFS-shared. Bare metal hardware is in place, running RHEL IPA. The "ipa-crlgen-manage" is actually not present on the running ipa-server-4.X) but is on a later version. Yes, I could run "yum update" and restart; but this VM can't go down until 1) offloading the last crucial functions to the bare metal 2) removing it from topology. There is limited opportunity to confirm things don't break after that update. Thanks for any leads.

2 2

Yum-based upgrade causes group lookup failures.
by Jeff Goddard 10 May '23

10 May '23

Hello and thank you for providing such a useful product. We recently used yum to update our freeipa infrastructure and everything went off without a hitch with the exception of one of our integrated apps which now cannot determine group membership. We know the lookup is successful as the user can login but we use group-based ACLs from freeipa and when the groups are not populated, the users cannot access the rundeck jobs. Nothing on rundeck was changed, the only actions taken were "yum update" and "yum upgrade" on the freeipa servers. I've reviewed the configurations and done some troubleshooting but can't find an answer so I'm reaching out in hopes someone can give me a clue. Environment details: Server: CentOS Linux release 7.9.2009 (Core) Freeipa version: 4.6.8-5.el7.centos.12 Problematic app: Rundeck Update logs are attached as is the application ladp lookup config and application login error. Any help is greatly appreciated. Jeff -- Jeff Goddard Director of Information Technology SureCost Email: jgoddard@ <jgoddard(a)emerlyn.com>surecost.com Telephone: (603) 447-8571 Toll free: (888) 363-7596 ext. 108 Fax: (603) 356-3346

2 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users May 2023