January 2024 - FreeIPA-users - Fedora mailing-lists

Re: issues ssh'ing as AD user to freeipa client
by Sumit Bose 01 Feb '24

01 Feb '24

Am Wed, Dec 13, 2023 at 11:49:00PM +0000 schrieb Ostrom, Erik via FreeIPA-users: > Hi, > > I'm having some issues ssh'ing as an AD user to a freeipa client, but I can successfully ssh as the same user to the IPA master. > Our IPA domain, ipa.subdomain.contoso.com, is set up with a one-way trust with ad.contoso.com (IPA trusts ADs users). I have the standard "allow all" HBAC rule in place on FreeIPA for testing purposes. ad.contoso.com is a relatively huge AD, with over 400,000 user accounts. > > ssh erik-ipa(a)freeipa1.ipa.subdomain.contoso.com --- (IPA user to FreeIPA master), works > ssh erik-ad@ad.contso.com@freeipa1.ipa.subdomain.contoso.com --- (AD user to FreeIPA master), works > ssh erik-ipa(a)rl9-ipa-client1.in.subdomain.contoso.com --- (IPA user to FreeIPA client), works > ssh erik-ad@ad.contoso.com@rl9-ipa-client1.in.subdomain.contoso.com --- (AD user to FreeIPA client), doesn't work > > I'm not sure what to look at in the SSSD logs to see what's going wrong here. I have uploaded sanitized SSSD logs from rl9-ipa-client1.in.subdomain.contoso.com for a failed login attempt (listed above as not working) at the following link:https://privatebin.net/?55e82c73463ae145#A59jSajU1ZwEwr3nEKhPqsT8Um4QX… Hi, according to the logs, the IPA server needs too much time to prepare the data of the AD user which the client requested. (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_get_acct_info_send] (0x0400): [RID#229] Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust user [erik-ad] to IPA server (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x0400): [RID#229] Executing extended operation (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x2000): [RID#229] ldap_extended_operation sent, msgid = 41 (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): [RID#229] New operation 41 timeout 6 (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: sh[0x55e456f262f0], connected[1], ops[0x55e456efac80], ldap[0x55e455ed5310] (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (2023-12-12 16:31:19): [be[ipa.subdomain.contoso.com]] [sdap_op_timeout] (0x1000): [RID#229] Issuing timeout [ldap_opt_timeout] for message id 41 Typically this means that the server has to refresh some or all cached data of the user, which in this case will include all group-memberships and for some technical reasons this means refreshing all related expired groups and their members. At least for the group members this can be speed up by setting ignore_group_members = True subdomain_inherit = ignore_group_members in the [domain/...] section on IPA servers and clients. Another option is to set refresh_expired_interval = 4000 in the [domain/...] sections on the IPA servers to make sure that SSSD will try every 4000s to refresh cached entries which are about to expire. As a result the IPA servers should be able to always reply to request form IPA client with cached data without the need to refresh it. HTH bye, Sumit > > If anyone can tell what my issue is here, or if other logs would be helpful let me know. I appreciate the help! > > Thanks, > Erik > -- > _______________________________________________ > 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

XRDP certificates via FreeIPA fails with an SELinux error
by Bo Lind 31 Jan '24

31 Jan '24

I'm rolling out some servers providing a graphical desktop, and everything is fine except this: our desktop software of choice is XRDP which needs a certificate. It ships with a self-signed one, but that gives warnings on the clients, so I'd much rather go with a FreeIPA managed one. So after installing XRDP, I issue the command: ipa-getcert request -f /etc/xrdp/cert.pem -k /etc/xrdp/key.pem -r -w Problem is, this fails with SELinux enabled, because ipa-getcert is not permitted to write to /etc/xrdp. Proposed solution 1: Use a better dir, the certificate and key are configured in /etc/xrdp/xrdp.conf so I'm guessing certs can reside anywhere. What's a good default one? Somewhere in /etc/pki? Proposed solution 2: Make and install a SELinux policy that allows ipa-getcert to access that directory. Searching a bit, I can see that the issue comes up on occasion, with other software packages such as Puppet etc.

2 1

FreeIPA -Airtight- No access to Internet - How to update/upgrade package installation.
by Marcelo Carvalho 30 Jan '24

30 Jan '24

I have an FreeIPA host that has to be out of reach of Internet. I can update the host OS and packages by syncing RHEL repo to my LocalRepo. No issues there for every package installed, but I am not able to update FreeIPA. From https://www.freeipa.org/page/Upgrade we have instruction on upgrades: FreeIPA 3.3.0 or newer # yum update freeipa-server I have not tried because the purpose is to bring "freeipa-server" package to the LocalRepo for host access. I cannot find the repository for "freeipa-server." Please advise on how to identify FreeIPA repo for RHEL-9, or how to proceed with offline FreeIPA upgrade. Many thanks. Marcelo Carvalho IT Senior System Administrator Astranis Space Technologies Corp. mcarvalho(a)astranis.com https://www.astranis.com/ P.S. Will "# yum update freeipa-server" work? I do not see it as output of the repository when the development host is available to them. The host is running on AWS and using a Linux RHEL-9 from AWS.

3 4

Cannot login to FreeIPA as 'admin' user...
by Tom Spettigue 26 Jan '24

26 Jan '24

Hey all - I'm having an odd bug when I try to login to the web interface as the FreeIPA 'admin' user. I get the following error message: Login failed due to an unknown reason. Not sure where that's coming from, but per this post (https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost…) I went ahead and checked the validity period of the `/var/kerberos/krb5kdc/kdc.crt` with the `openssl x509 -text -in /var/kerberos/krb5kdc/kdc.crt` command. Sure as shoot, that certificate expired on the 22nd of January at about 7:00 AM GMT - and I'm stuck unable to login and manage my domain. :( Now according to the end of that thread, the problem just up and fixed itself but I'm up against a wall here in that I... definitely need to to be able to get in pretty soon, as I have a new host I need to provision. Is there any way to manually jumpstart this process?

1 2

Permission / privilege to unlock accounts
by Russell Long 25 Jan '24

25 Jan '24

I'm trying to create a set of limited users who have the ability to unlock all other user accounts and change their passwords. I've got the password portion figured out, however when a user with the limited permissions tries to run the `unlock` operation they get the following message: Insufficient access: Insufficient 'write' privilege to the 'krbLoginFailedCount' attribute of entry... I have attempted to create a permission granting this access, but it does not appear to work. I'll attach an image of the existing permission, not sure how the list will handle the image. --Russ

3 2

Is there even one freeipa dev that knows everything about upgrading across major OS releases?
by Harry G Coin 25 Jan '24

25 Jan '24

Hi! This is meant for the good future of freeipa, a package I've appreciated for some years, so across the user cultures and languages please understand it as supportive and not a complaint! For all freeipa's 'master-master' replica technology, there remain 'some instances more primary than others' even if the topology diagrams claim equivalence. Lose 'that one that's even more primary' and (absent high-learning-curve, on-site capability, and intervention that calls for high-bar mastery of seldom used subsystems) -- you're on a track to breakage. Why? Because it's when, not if, that 'primary' system will need a major OS point release (8 to 9 in the present situation). In that case, there is as yet no 'just works' upgrade path. With 'not the super special 'even more master than other' master replicas, it's easy and 'it just works'... but 'for that one...' freeipa is not ready for 'prime time'. For example, should site admins 'just know' whether there is a current kasp.db maintained in more than one place? How many know about ipa-crlgen-manage, or whether /etc/pki/pki-tomcat/ca/CS.cfg should or shouldn't have ca.certStatusUpdateInterval=0, or have the command ipa config-mod --ca-renewal-master-server at the top of their mind? SID range assignments? Fundamentally, the fair question is: Which freeipa subsystems that I don't happen to have studied in dev-level detail have similar 'deep gotchas that are obvious to the one who specializes in that, but opaque to everyone else'? Not even the freeipa devs who write the docs collect all the steps in one place. While there are 'characterizations of worries' those come without steps, the advice doesn't say what steps will work, just what won't. ('don't leapp upgrade'). The way forward I think is fairly doable. First is to have each 'dev that's an expert in their thing' (dns, kra, etc. etc.) make sure all 'master' level replicas have, updated, whatever 'special files' might be necessary, even if they aren't 'the extra special primary replica', and may never get used. Second is an 'orchestration' command, to be run on a master-replica that is 'the latest os', that will, 'all in one', do all the magic to become 'the extra special primary master' and take those options off 'the old primary', even if it means installing trust/dns/etc subsystems extant on the 'old master' but missing from the 'soon to be new primary master'. An orchestration command that manages everything from moving which fqdn is authoritative in SOA records, to magic tiny entries in CA.cfg files. When that command is done, the 'old primary' becomes 'just another master replica that happens to be using an older os'. Then the 'old primary' can be discarded and replaced with the latest os and a fresh install as a master replica. At that point, it's optional whether to move the 'special primary' status 'back' to the 'now new OS master system'. The admin pain involved at present 'for that one system that's the extra special primary' at os major release upgrade time -- it sets too high an education bar, obviously higher than even one freeipa-dev has, as the docs prove-- and as such needs a team approach to address,, before OS 9 to 10 please! Thanks for all you've done so far! Harry Coin

2 5

cannot login on FreeIPA web GUI: Your session has expired. Please log in again.
by Harald Dunkel 24 Jan '24

24 Jan '24

Hi folks, after the upgrade from ipa-server.x86_64 4.9.12-9 to version 4.9.12-11 my FreeIPA servers' web interfaces became inaccessible. At login time there is a message Your session has expired. Please log in again. I found some other threads about similar problems in this ML. However, the suggested fix to create SIDs [root@ipa0 log]# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid --netbios-name EXAMPLE --add-sids Configuring SID generation [1/8]: creating samba domain object Samba domain object already exists [2/8]: adding admin(group) SIDs Admin SID already set, nothing to do Admin group SID already set, nothing to do [3/8]: adding RID bases RID bases already set, nothing to do [4/8]: updating Kerberos config 'dns_lookup_kdc' already set to 'true', nothing to do. [5/8]: activating sidgen task Sidgen task plugin already configured, nothing to do [6/8]: restarting Directory Server to take MS PAC and LDAP plugins changes into account [7/8]: adding fallback group Fallback group already set, nothing to do [8/8]: adding SIDs to existing users and groups This step may take considerable amount of time, please wait.. Done. The ipa-enable-sid command was successful [root@ipa0 log]# echo $? 0 did not help. I still cannot login on the web interface. (Looking at the output it didn't had to do anything, anyway. AFAIR this SID thingy was already done during migration from CentOS 7 to 8, AFAIR). [root@ipa0 ~]# ipa idrange-find --raw ---------------- 3 ranges matched ---------------- cn: EXAMPLE.DE_id_range ipabaseid: 379400000 ipaidrangesize: 200000 ipabaserid: 379400000 ipasecondarybaserid: 379600000 iparangetype: ipa-local cn: EXAMPLE.DE_posix ipabaseid: 1000 ipaidrangesize: 99000 ipabaserid: 1000 ipasecondarybaserid: 100000 iparangetype: ipa-local cn: EXAMPLE.DE_subid_range ipabaseid: 2147483648 ipaidrangesize: 2147352576 ipabaserid: 2147283648 ipanttrusteddomainsid: S-1-5-21-738065-838566-194929194 iparangetype: ipa-ad-trust ---------------------------- Number of entries returned 3 ---------------------------- /var/log/messages shows Jan 23 13:50:28 ipa0 [6654]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) Jan 23 13:50:28 ipa0 [6653]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) Jan 23 13:50:31 ipa0 [6654]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) Jan 23 13:50:31 ipa0 [6653]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) /var/log/krb5kdc.log Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1706012763, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa0.example.de(a)EXAMPLE.DE for ldap/ipa0.example.de(a)EXAMPLE.DE, KDC policy rejects request Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): ... CONSTRAINED-DELEGATION s4u-client=<unknown> Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): closing down fd 4 Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1706012763, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa0.example.de(a)EXAMPLE.DE for ldap/ipa0.example.de(a)EXAMPLE.DE, KDC policy rejects request Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): ... CONSTRAINED-DELEGATION s4u-client=<unknown> Jan 23 13:50:28 ipa0.example.de krb5kdc[6611](info): closing down fd 4 Jan 23 13:50:30 ipa0.example.de krb5kdc[6611](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: NEEDED_PREAUTH: WELLKNOWN/ANONYMOUS(a)EXAMPLE.DE for krbtgt/EXAMPLE.DE(a)EXAMPLE.DE, Additional pre-authentication required Jan 23 13:50:30 ipa0.example.de krb5kdc[6611](info): closing down fd 4 Jan 23 13:50:31 ipa0.example.de krb5kdc[6587](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: ISSUE: authtime 1706014231, etypes {rep=aes256-cts-hmac-sha384-192(20), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, WELLKNOWN/ANONYMOUS(a)EXAMPLE.DE for krbtgt/EXAMPLE.DE(a)EXAMPLE.DE Jan 23 13:50:31 ipa0.example.de krb5kdc[6587](info): closing down fd 4 Jan 23 13:50:31 ipa0.example.de krb5kdc[6611](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: NEEDED_PREAUTH: hdunkel(a)EXAMPLE.DE for krbtgt/EXAMPLE.DE(a)EXAMPLE.DE, Additional pre-authentication required Jan 23 13:50:31 ipa0.example.de krb5kdc[6611](info): closing down fd 4 Jan 23 13:50:31 ipa0.example.de krb5kdc[6592](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: ISSUE: authtime 1706014231, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, hdunkel(a)EXAMPLE.DE for krbtgt/EXAMPLE.DE(a)EXAMPLE.DE Jan 23 13:50:31 ipa0.example.de krb5kdc[6592](info): closing down fd 4 Jan 23 13:50:31 ipa0.example.de krb5kdc[6588](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: ISSUE: authtime 1706014231, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, hdunkel(a)EXAMPLE.DE for HTTP/ipa0.example.de(a)EXAMPLE.DE Jan 23 13:50:31 ipa0.example.de krb5kdc[6588](info): closing down fd 4 Jan 23 13:50:31 ipa0.example.de krb5kdc[6587](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1706014231, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa0.example.de(a)EXAMPLE.DE for ldap/ipa0.example.de(a)EXAMPLE.DE, KDC policy rejects request Jan 23 13:50:31 ipa0.example.de krb5kdc[6587](info): ... CONSTRAINED-DELEGATION s4u-client=<unknown> Jan 23 13:50:31 ipa0.example.de krb5kdc[6587](info): closing down fd 4 Jan 23 13:50:31 ipa0.example.de krb5kdc[6588](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.19.96.2: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1706014231, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa0.example.de(a)EXAMPLE.DE for ldap/ipa0.example.de(a)EXAMPLE.DE, KDC policy rejects request Jan 23 13:50:31 ipa0.example.de krb5kdc[6588](info): ... CONSTRAINED-DELEGATION s4u-client=<unknown> Jan 23 13:50:31 ipa0.example.de krb5kdc[6588](info): closing down fd 4 Every helpful hint is highly appreciated. Harri

4 10

Is it possible to install FreeIPA on different disk than ('/')
by Finn Fysj 24 Jan '24

24 Jan '24

Currently our installation of FreeIPA is done on root ('/'). Is it possible to install FreeIPA on different disk & mount path wihtout causing too much issues?

3 2

Re: FreeIPA or RHEL IdM with Amazon Cognito
by Alexander Bokovoy 24 Jan '24

24 Jan '24

On Срд, 24 сту 2024, Carlos Lopez via FreeIPA-users wrote: >Hi all, > >I need to integrate authentication and role access for a few users >between Amazon Cognito and FreeIPA/IdM. The idea is that the user logs >in with Cognito but the access validation, password changes, roles, >etc. are hosted in FreeIPA. The resources where users login are outside >of Amazon (for example our internal password management app). Is this >possible? Could it be an option to use SAML? IPA can delegate authentication (actually, authorization as in OAuth2 Device Authorization Grant Flow) to an external IdP provider. Amazon Cognito does not have support for OAuth2 Device Authorization Grant flow but one can create a separate flow integrated with Cognito: https://aws.amazon.com/blogs/security/implement-oauth-2-0-device-grant-flow… See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/ht… for RHEL IdM documentation. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

2 1

FreeIPA or RHEL IdM with Amazon Cognito
by Carlos Lopez 24 Jan '24

24 Jan '24

Hi all, I need to integrate authentication and role access for a few users between Amazon Cognito and FreeIPA/IdM. The idea is that the user logs in with Cognito but the access validation, password changes, roles, etc. are hosted in FreeIPA. The resources where users login are outside of Amazon (for example our internal password management app). Is this possible? Could it be an option to use SAML? Thanks. Best regards, C. L. Martinez

1 0

Different ID ranges cannot login to samba
by Rui Gomes 24 Jan '24

24 Jan '24

Hello Everyone, We are experiencing a strange error, where we have 2 ID ranges. The default one always worked well with samba, we have add a second ID range that works perfectly for everything but no user in that range can login to samba. All the users in the default ID range can authenticate with samba, but no user on a lower ID 5000-10000 manage to authenticate, no obvious errors in the logs. Does this ring any bells, we have tried to force samba ID range made no difference. Regards RG

2 1

Can't login to IPA
by Bogdan Stoica 24 Jan '24

24 Jan '24

After upgrading ipa to the latest version, login to webui is no longer working I'm using Rocky Linux 8.9 and these are the IPA installed packages: [root@ipa02 dnssec]# rpm -qa | grep ipa ipa-server-4.9.12-11.module+el8.9.0+1652+4ee71f6a.x86_64 ipa-server-common-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch libipa_hbac-2.9.1-4.el8_9.x86_64 ipa-client-common-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch ipa-client-4.9.12-11.module+el8.9.0+1652+4ee71f6a.x86_64 python3-libipa_hbac-2.9.1-4.el8_9.x86_64 sssd-ipa-2.9.1-4.el8_9.x86_64 ipa-common-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch python3-ipaclient-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch ipa-server-dns-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch rocky-logos-ipa-86.3-1.el8.noarch ipa-healthcheck-0.12-3.module+el8.9.0+1434+912e18bd.noarch python3-ipalib-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch ipa-healthcheck-core-0.12-3.module+el8.9.0+1434+912e18bd.noarch python3-ipaserver-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch ipa-selinux-4.9.12-11.module+el8.9.0+1652+4ee71f6a.noarch When trying to run this command (as some users suggested): ipa config-mod --enable-sid --add-sids I'm getting this: ipa: ERROR: cannot connect to 'https://ipa02.shtar.prod1/ipa/session/json': Exceeded number of tries to forward a request.

2 1

Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
by Alexander Bokovoy 24 Jan '24

24 Jan '24

On Аўт, 23 сту 2024, Dungan, Scott A. via FreeIPA-users wrote: >I found the answer in this thread: > >https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > >Following that, we used ldapmodify to apply the correct values for the >rid-base and secondary-rid-base in the new range. Afterwards, running > >ipa config-mod --enable-sid --add-sids > >completed, and all users have been assigned sids, although the logs >show a few errors about sids already being used: > >Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.671583872 -0800] - ERR - rid_to_sid_with_check - [file ipa_sidgen_common.c, line 384]: SID [S-1-5-21-437482216-426791213-2761072236-101000116] is already used. >Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.672837572 -0800] - ERR - rid_to_sid_with_check - [file ipa_sidgen_common.c, line 384]: SID [S-1-5-21-437482216-426791213-2761072236-101000115] is already used. >Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.683585571 -0800] - ERR - rid_to_sid_with_check - [file ipa_sidgen_common.c, line 384]: SID [S-1-5-21-437482216-426791213-2761072236-101029028] is already used. >Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.703869107 -0800] - ERR - rid_to_sid_with_check - [file ipa_sidgen_common.c, line 384]: SID [S-1-5-21-437482216-426791213-2761072236-101029021] is already used. >Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.743343711 -0800] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [0] > >Not sure if we should be concerned about that or not. Since it doesn't say 'Secondary SID is used as well.', this means a first choice for that SID was not successful and sidgen plugin switched to a RID from the secondary RID base. It should be fine in the end -- a user/group got a unique SID assigned. > >-Scott > >From: Dungan, Scott A. via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> >Sent: Tuesday, January 23, 2024 8:05 AM >To: Florence Blanc-Renaud <flo(a)redhat.com>; FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> >Cc: Dungan, Scott A. <sdungan(a)caltech.edu> >Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working > >Thanks, Flo. > >I believe we now know what the correct values should be for the rid-base and secondary-rid-base, however, we can’t seem to modify the ID range with the missing values we created to cover the legacy NIS users: > >$ ipa idrange-mod ID.EXAMPLE.COM_legacy_range >ipa: ERROR: This command can not be used to change ID allocation for local IPA domain. Run `ipa help idrange` for more information > >Nor can we simply delete the range and try again: > >ipa idrange-del ID.EXAMPLE.COM_legacy_range >ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving objects with ID out of the defined range is not allowed > >It seems that we are in a chicken or the egg bind here. Below is the output of iprange-find for reference. > >---------------- >3 ranges matched >---------------- > Range name: ID.EXAMPLE.COM _id_range > First Posix ID of the range: 866800000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 1000 > First RID of the secondary RID range: 100000000 > Range type: local domain range > > Range name: ID.EXAMPLE.COM _legacy_range > First Posix ID of the range: 1000 > Number of IDs in the range: 98899 > Range type: local domain range > > Range name: ID.EXAMPLE.COM _subid_range > First Posix ID of the range: 2147483648 > Number of IDs in the range: 2147352576 > First RID of the corresponding RID range: 2147283648 > Domain SID of the trusted domain: S-1-5-21-538032-778436-45698521293 > Range type: Active Directory domain range >---------------------------- >Number of entries returned 3 >---------------------------- > >From: Florence Blanc-Renaud <flo(a)redhat.com<mailto:flo@redhat.com>> >Sent: Monday, January 22, 2024 11:50 PM >To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> >Cc: Dungan, Scott A. <sdungan(a)caltech.edu<mailto:sdungan@caltech.edu>> >Subject: Re: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working > >Hi, > >On Tue, Jan 23, 2024 at 1:05 AM Dungan, Scott A. via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> wrote: >Thanks to Paul for all the leg work on this issue. Based on that, I can confirm that we have the same problem after updating to 4.9.12-11 from 4.9.11-7. Running the oddjob command to add SIDs to the user accounts fails after encountering UIDs outside of the default IPA range. It was able to get the admin account working though. We have 294 users with UIDs in the range of 1001 to 99657. These were migrated from an ancient NIS domain when the IPA domain was provisioned. We tried adding a secondary IPA range that covers that scope: > >ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 --range-size=98899 > >And then running the oddjob command again, but we get the sidgen errors still, plus a error about overlapping rid ranges: > >[22/Jan/2024:15:09:50.398460268 -0800] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... >[22/Jan/2024:15:09:50.499604871 -0800] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [29034] into an unused SID. >[22/Jan/2024:15:09:50.499960197 -0800] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. >[22/Jan/2024:15:09:50.503257753 -0800] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. >[22/Jan/2024:15:09:55.035779436 -0800] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=id,dc=example,dc=com >[22/Jan/2024:15:09:55.036238563 -0800] - ERR - schema-compat-plugin - Finished plugin initialization. >[22/Jan/2024:15:47:04.969286883 -0800] - ERR - ipa_range_check_pre_op - [file ipa_range_check.c, line 670]: New primary rid range overlaps with existing primary rid range. > >I suspect that we may not have added the range correctly. We didn't pass the --rid-base= or --secondary-rid-base= flags/values as we were not sure what these values should be. > >These values are important in order to generate the SIDs. Please read The role of security and relative identifiers in IdM ID ranges<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht…> and Security Identifiers<https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html#security-i…> to understand how they are used. You need to pick values that do not conflict with the ones for your initial range. > >flo > >Any help would be much appreciated. > >Scott > >-----Original Message----- >From: Rob Crittenden via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> >Sent: Thursday, January 18, 2024 11:25 AM >To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> >Cc: Paul Nickerson <pgn674(a)gmail.com<mailto:pgn674@gmail.com>>; Rob Crittenden <rcritten(a)redhat.com<mailto:rcritten@redhat.com>> >Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working > >Paul Nickerson via FreeIPA-users wrote: >> I confirmed that users who had an ipaNTSecurityIdentifier attribute could log in to the web UI, and those that did not have the ipaNTSecurityIdentifier attribute could not. >> >> I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like you said: >> [17/Jan/2024:20:28:09.571195828 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... >> [17/Jan/2024:20:28:09.637675948 +0000] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1566000023] into an unused SID. >> [17/Jan/2024:20:28:09.658369523 +0000] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. >> [17/Jan/2024:20:28:09.666726494 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. >> >> I found some nice documentation at >> https://access.redhat.com/solutions/394763 >> >> I used this command to see the ranges that I have configured: >> ipa idrange-find >> >> And these two commands to see the UIDs of the users who had not yet been given SIDs (some were inside the existing range; I think you're correct that the process stops at the first error): >> ldapsearch -H ldap://ipa01.semi.example.net:389/<http://ipa01.semi.example.net:389/> -x -D "cn=Directory >> Manager" -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" >> "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v >> "# requesting: " | sed 's/uidNumber: //' | sort -n ldapsearch -H >> ldap://ipa01.semi.example.net:389/<http://ipa01.semi.example.net:389/> -x -D "cn=Directory Manager" -W -b >> "cn=deleted >> users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" >> "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v >> "# requesting: " | sed 's/uidNumber: //' | sort -n >> >> Here's some documentation on what ID and RID ranges are for: >> https://www.freeipa.org/page/V3/ID_Ranges >> >> After doing a bunch of math and guess and check, I ran this: >> ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=1441400000 >> --range-size=531251000 --rid-base=101000000 >> --secondary-rid-base=633000000 >> >> That gave me an additional range (confirmed with ipa idrange-find). I >> ran ipa config-mod --enable-sid --add-sids again, saw no significant >> errors in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and >> confirmed that there were 0 users left with no >> ipaNTSecurityIdentifier. >> >> All users are all set now. Thank you again. > >Glad to hear it and thank you for your detailed analysis. I think this >will be useful to other users that may run into this. > >rob >-- >_______________________________________________ >FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org> >To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org<mailto:freeipa-users-leave@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<mailto:freeipa-users@lists.fedorahosted.org> >To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org<mailto:freeipa-users-leave@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 -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

1 0

Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
by Dungan, Scott A. 23 Jan '24

23 Jan '24

I found the answer in this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… Following that, we used ldapmodify to apply the correct values for the rid-base and secondary-rid-base in the new range. Afterwards, running ipa config-mod --enable-sid --add-sids completed, and all users have been assigned sids, although the logs show a few errors about sids already being used: Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.671583872 -0800] - ERR - rid_to_sid_with_check - [file ipa_sidgen_common.c, line 384]: SID [S-1-5-21-437482216-426791213-2761072236-101000116] is already used. Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.672837572 -0800] - ERR - rid_to_sid_with_check - [file ipa_sidgen_common.c, line 384]: SID [S-1-5-21-437482216-426791213-2761072236-101000115] is already used. Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.683585571 -0800] - ERR - rid_to_sid_with_check - [file ipa_sidgen_common.c, line 384]: SID [S-1-5-21-437482216-426791213-2761072236-101029028] is already used. Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.703869107 -0800] - ERR - rid_to_sid_with_check - [file ipa_sidgen_common.c, line 384]: SID [S-1-5-21-437482216-426791213-2761072236-101029021] is already used. Jan 23 10:10:47 idm1.example.com ns-slapd[52294]: [23/Jan/2024:10:10:47.743343711 -0800] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [0] Not sure if we should be concerned about that or not. -Scott From: Dungan, Scott A. via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> Sent: Tuesday, January 23, 2024 8:05 AM To: Florence Blanc-Renaud <flo(a)redhat.com>; FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> Cc: Dungan, Scott A. <sdungan(a)caltech.edu> Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working Thanks, Flo. I believe we now know what the correct values should be for the rid-base and secondary-rid-base, however, we can’t seem to modify the ID range with the missing values we created to cover the legacy NIS users: $ ipa idrange-mod ID.EXAMPLE.COM_legacy_range ipa: ERROR: This command can not be used to change ID allocation for local IPA domain. Run `ipa help idrange` for more information Nor can we simply delete the range and try again: ipa idrange-del ID.EXAMPLE.COM_legacy_range ipa: ERROR: invalid 'ipabaseid,ipaidrangesize': range modification leaving objects with ID out of the defined range is not allowed It seems that we are in a chicken or the egg bind here. Below is the output of iprange-find for reference. ---------------- 3 ranges matched ---------------- Range name: ID.EXAMPLE.COM _id_range First Posix ID of the range: 866800000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range Range name: ID.EXAMPLE.COM _legacy_range First Posix ID of the range: 1000 Number of IDs in the range: 98899 Range type: local domain range Range name: ID.EXAMPLE.COM _subid_range First Posix ID of the range: 2147483648 Number of IDs in the range: 2147352576 First RID of the corresponding RID range: 2147283648 Domain SID of the trusted domain: S-1-5-21-538032-778436-45698521293 Range type: Active Directory domain range ---------------------------- Number of entries returned 3 ---------------------------- From: Florence Blanc-Renaud <flo(a)redhat.com<mailto:flo@redhat.com>> Sent: Monday, January 22, 2024 11:50 PM To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> Cc: Dungan, Scott A. <sdungan(a)caltech.edu<mailto:sdungan@caltech.edu>> Subject: Re: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working Hi, On Tue, Jan 23, 2024 at 1:05 AM Dungan, Scott A. via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> wrote: Thanks to Paul for all the leg work on this issue. Based on that, I can confirm that we have the same problem after updating to 4.9.12-11 from 4.9.11-7. Running the oddjob command to add SIDs to the user accounts fails after encountering UIDs outside of the default IPA range. It was able to get the admin account working though. We have 294 users with UIDs in the range of 1001 to 99657. These were migrated from an ancient NIS domain when the IPA domain was provisioned. We tried adding a secondary IPA range that covers that scope: ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 --range-size=98899 And then running the oddjob command again, but we get the sidgen errors still, plus a error about overlapping rid ranges: [22/Jan/2024:15:09:50.398460268 -0800] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [22/Jan/2024:15:09:50.499604871 -0800] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [29034] into an unused SID. [22/Jan/2024:15:09:50.499960197 -0800] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. [22/Jan/2024:15:09:50.503257753 -0800] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. [22/Jan/2024:15:09:55.035779436 -0800] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=id,dc=example,dc=com [22/Jan/2024:15:09:55.036238563 -0800] - ERR - schema-compat-plugin - Finished plugin initialization. [22/Jan/2024:15:47:04.969286883 -0800] - ERR - ipa_range_check_pre_op - [file ipa_range_check.c, line 670]: New primary rid range overlaps with existing primary rid range. I suspect that we may not have added the range correctly. We didn't pass the --rid-base= or --secondary-rid-base= flags/values as we were not sure what these values should be. These values are important in order to generate the SIDs. Please read The role of security and relative identifiers in IdM ID ranges<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht…> and Security Identifiers<https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html#security-i…> to understand how they are used. You need to pick values that do not conflict with the ones for your initial range. flo Any help would be much appreciated. Scott -----Original Message----- From: Rob Crittenden via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> Sent: Thursday, January 18, 2024 11:25 AM To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>> Cc: Paul Nickerson <pgn674(a)gmail.com<mailto:pgn674@gmail.com>>; Rob Crittenden <rcritten(a)redhat.com<mailto:rcritten@redhat.com>> Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working Paul Nickerson via FreeIPA-users wrote: > I confirmed that users who had an ipaNTSecurityIdentifier attribute could log in to the web UI, and those that did not have the ipaNTSecurityIdentifier attribute could not. > > I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like you said: > [17/Jan/2024:20:28:09.571195828 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... > [17/Jan/2024:20:28:09.637675948 +0000] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1566000023] into an unused SID. > [17/Jan/2024:20:28:09.658369523 +0000] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. > [17/Jan/2024:20:28:09.666726494 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. > > I found some nice documentation at > https://access.redhat.com/solutions/394763 > > I used this command to see the ranges that I have configured: > ipa idrange-find > > And these two commands to see the UIDs of the users who had not yet been given SIDs (some were inside the existing range; I think you're correct that the process stops at the first error): > ldapsearch -H ldap://ipa01.semi.example.net:389/<http://ipa01.semi.example.net:389/> -x -D "cn=Directory > Manager" -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" > "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v > "# requesting: " | sed 's/uidNumber: //' | sort -n ldapsearch -H > ldap://ipa01.semi.example.net:389/<http://ipa01.semi.example.net:389/> -x -D "cn=Directory Manager" -W -b > "cn=deleted > users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" > "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v > "# requesting: " | sed 's/uidNumber: //' | sort -n > > Here's some documentation on what ID and RID ranges are for: > https://www.freeipa.org/page/V3/ID_Ranges > > After doing a bunch of math and guess and check, I ran this: > ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=1441400000 > --range-size=531251000 --rid-base=101000000 > --secondary-rid-base=633000000 > > That gave me an additional range (confirmed with ipa idrange-find). I ran ipa config-mod --enable-sid --add-sids again, saw no significant errors in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and confirmed that there were 0 users left with no ipaNTSecurityIdentifier. > > All users are all set now. Thank you again. Glad to hear it and thank you for your detailed analysis. I think this will be useful to other users that may run into this. rob -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org<mailto:freeipa-users-leave@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<mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org<mailto:freeipa-users-leave@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

Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
by Florence Blanc-Renaud 23 Jan '24

23 Jan '24

Hi, On Tue, Jan 23, 2024 at 1:05 AM Dungan, Scott A. via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org> wrote: > Thanks to Paul for all the leg work on this issue. Based on that, I can > confirm that we have the same problem after updating to 4.9.12-11 from > 4.9.11-7. Running the oddjob command to add SIDs to the user accounts fails > after encountering UIDs outside of the default IPA range. It was able to > get the admin account working though. We have 294 users with UIDs in the > range of 1001 to 99657. These were migrated from an ancient NIS domain when > the IPA domain was provisioned. We tried adding a secondary IPA range that > covers that scope: > > ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 > --range-size=98899 > > And then running the oddjob command again, but we get the sidgen errors > still, plus a error about overlapping rid ranges: > > [22/Jan/2024:15:09:50.398460268 -0800] - ERR - sidgen_task_thread - [file > ipa_sidgen_task.c, line 194]: Sidgen task starts ... > [22/Jan/2024:15:09:50.499604871 -0800] - ERR - find_sid_for_ldap_entry - > [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [29034] into > an unused SID. > [22/Jan/2024:15:09:50.499960197 -0800] - ERR - do_work - [file > ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. > [22/Jan/2024:15:09:50.503257753 -0800] - ERR - sidgen_task_thread - [file > ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. > [22/Jan/2024:15:09:55.035779436 -0800] - ERR - schema-compat-plugin - > warning: no entries set up under cn=computers, > cn=compat,dc=id,dc=example,dc=com > [22/Jan/2024:15:09:55.036238563 -0800] - ERR - schema-compat-plugin - > Finished plugin initialization. > [22/Jan/2024:15:47:04.969286883 -0800] - ERR - ipa_range_check_pre_op - > [file ipa_range_check.c, line 670]: New primary rid range overlaps with > existing primary rid range. > > I suspect that we may not have added the range correctly. We didn't pass > the --rid-base= or --secondary-rid-base= flags/values as we were not sure > what these values should be. > These values are important in order to generate the SIDs. Please read The role of security and relative identifiers in IdM ID ranges <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht…> and Security Identifiers <https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html#security-i…> to understand how they are used. You need to pick values that do not conflict with the ones for your initial range. flo > > Any help would be much appreciated. > > Scott > > -----Original Message----- > From: Rob Crittenden via FreeIPA-users < > freeipa-users(a)lists.fedorahosted.org> > Sent: Thursday, January 18, 2024 11:25 AM > To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > Cc: Paul Nickerson <pgn674(a)gmail.com>; Rob Crittenden <rcritten(a)redhat.com > > > Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused > web UI login and ipa command to stop working > > Paul Nickerson via FreeIPA-users wrote: > > I confirmed that users who had an ipaNTSecurityIdentifier attribute > could log in to the web UI, and those that did not have the > ipaNTSecurityIdentifier attribute could not. > > > > I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like > you said: > > [17/Jan/2024:20:28:09.571195828 +0000] - ERR - sidgen_task_thread - > [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... > > [17/Jan/2024:20:28:09.637675948 +0000] - ERR - find_sid_for_ldap_entry - > [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1566000023] > into an unused SID. > > [17/Jan/2024:20:28:09.658369523 +0000] - ERR - do_work - [file > ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. > > [17/Jan/2024:20:28:09.666726494 +0000] - ERR - sidgen_task_thread - > [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. > > > > I found some nice documentation at > > https://access.redhat.com/solutions/394763 > > > > I used this command to see the ranges that I have configured: > > ipa idrange-find > > > > And these two commands to see the UIDs of the users who had not yet been > given SIDs (some were inside the existing range; I think you're correct > that the process stops at the first error): > > ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory > > Manager" -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" > > "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v > > "# requesting: " | sed 's/uidNumber: //' | sort -n ldapsearch -H > > ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b > > "cn=deleted > > users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" > > "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v > > "# requesting: " | sed 's/uidNumber: //' | sort -n > > > > Here's some documentation on what ID and RID ranges are for: > > https://www.freeipa.org/page/V3/ID_Ranges > > > > After doing a bunch of math and guess and check, I ran this: > > ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=1441400000 > > --range-size=531251000 --rid-base=101000000 > > --secondary-rid-base=633000000 > > > > That gave me an additional range (confirmed with ipa idrange-find). I > ran ipa config-mod --enable-sid --add-sids again, saw no significant errors > in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and confirmed that there > were 0 users left with no ipaNTSecurityIdentifier. > > > > All users are all set now. Thank you again. > > Glad to hear it and thank you for your detailed analysis. I think this > will be useful to other users that may run into this. > > rob > -- > _______________________________________________ > 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

Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
by Paul Nickerson 22 Jan '24

22 Jan '24

I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They started on RHEL 8.0 I believe, and have been upgrading in-place since then. I recently restarted the FreeIPA services, which triggered an ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it errored out on some expired certificates, which I fixed with ipa-cert-fix, and then the ipa-server-upgrade's finished successfully. Now, when I or any of my users try to log on to the web UI, we get the error "Your session has expired. Please log in again." Also, when I try to run any ipa command on the command line, I get the error: ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/session/json, https://ipa02.semi.example.net/ipa/session/json I've traced down lots of errors, and I think this one is the most relevant: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) I see it in /var/log/httpd/error_log, in the body of the HTTP response from https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the output from the command ipa --debug Also, in /var/log/krb5kdc.log, I see: Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](info): TGS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 172.16.121.5: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa01.semi.example.net(a)SEMI.EXAMPLE.NET for ldap/ipa01.semi.example.net(a)SEMI.EXAMPLE.NET, KDC policy rejects request I have krb5 1.18.2 installed. disable_pac is not present in /var/kerberos/krb5kdc/kdc.conf. I think I'm experiencing the same issue seen in the recent thread at https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… (subject line "api authorization stopped working after upgrade to 4.9.12-11 on RHEL8"). I don't think any of my users or groups have an SID (ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL 8.0 (or thereabouts), and the servers have been upgraded in-place since then. We've never integrated with any Active Directory or Microsoft product. This command has no output, showing that even the admin user does not have an SID: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i ipantsecurityidentifier The solution from the other thread, and from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht…, does not work for me, since the ipa command doesn't work, not even for the admin user: [root(a)ipa01.semi.example.net ~] # kinit admin Password for admin(a)SEMI.EXAMPLE.NET: [root(a)ipa01.semi.example.net ~] # ipa config-mod --enable-sid --add-sids ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json I found an alternative method at https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#tro…, but this also does not work for me: [root(a)ipa01.semi.example.net ~] # ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f /tmp/ipa-sidgen-task-run.ldif SASL/GSSAPI authentication started SASL username: admin(a)SEMI.EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config" ldap_add: No such object (32) I think ipa-sidgen-task does not exist in my LDAP directory, but I'm not sure if I understand how this is supposed to work. I don't see ipa-sidgen-task or anything like it from this search: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=config | grep cn=tasks Can anyone help me here? I think if I could get a ipantsecurityidentifier attribute properly set up on my user or on the admin user, then I would be able to use the ipa command to get SID's enabled and created everywhere.

4 8

Re: api authorization stopped working after upgrade to 4.9.12-11 on RHEL8
by Sören Rothe 22 Jan '24

22 Jan '24

I have exactly the same issue after the update. Which logs do you need to check the issue? In kdc.conf there is no option set to ignore PAC.

1 1

FreeIPA 2FA OTP FIPS-140-2 Compliance
by Valentin Stancu 19 Jan '24

19 Jan '24

Hello, I've been searching for information on FIPS 140-2 compliance for OTP token generation in FreeIPA for a while, but I haven't been able to find anything conclusive. Could you tell me if the plugin that generates OTP tokens in FreeIPA is FIPS-140-2 compliant? If so, from which version has it been compliant? Could you also provide guidance on how we can verify the algorithms used by this 2FA component to generate these tokens? (Token generation system) Thank you and Best Regards, Valentin Stancu

2 1

SSSD LDAP provider fails to fetch nested groups (groups member of groups)
by Finn Fysj 19 Jan '24

19 Jan '24

I'm experiencing problems on my RHEL 9 instance when looking up members of group using getent group <GROUP NAME>. I can only get users which has direct access to a group, and no the "user groups" part of the group. My sssd.conf: [domain/<DOMAIN>] id_provider = ldap auth_provider = ldap chpass_provider = ldap sudo_provider = ldap ldap_uri = ldaps:/ipa.example.com ldap_schema = rfc2307bis ldap_search_base = dc=example,dc=com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=com [sssd] services = nss, pam, sudo domains = default [nss] homedir_substring = /home [pam] [sudo]

3 2

Allow users from AD trust to run ipa commands
by Yuriy Halytskyy 19 Jan '24

19 Jan '24

Hi, At first I've just created an external group, added the user, and added that group to a role but that didn't work. Then I stumbled across this while googling: ipa idoverrideuser-add 'Default Trust View' username@DOMAIN And it works, the user can use IPA commands with AD kerberos ticket and roles apply properly. But I cannot for the life of me figure out what that did and are there any other consequences. Documentation talks about using ID views to override user properties but this doesn't specify any properties to override. Also, it says the view is applied to all AD users, but in that case why do I need to run that command? Cheers, Yuriy

2 2

CentOS to Ubuntu migration
by Satish Patel 19 Jan '24

19 Jan '24

Folks, We are running 4 freeIPA servers on CentOS 7.x in master-master replication and life is good. But now it's time to say goodbye to CentOS. What can I do to migrate them to Ubuntu OS? Can I create one Ubuntu instance with freeIPA and join my existing freeIPA cluster and slowly retire old CentOS nodes? Just looking for a better way to migrate everything off the CentOS.

2 1

Seeking an advice on migrating freeipa environment from centos 7 to Almalinux 9
by Polavarapu Manideep Sai 19 Jan '24

19 Jan '24

Hi Team, Seeking an advice on migrating freeipa environment from centos 7 to Almalinux 9 Consider there are 4 servers 1 as IPA master and rest are replicas 1. master.ipa.example.com [centos 7.9 IPA 4.6.8] 2. Replica1.ipa.example.com [centos 7.9 IPA 4.6.8] 3. Replica2.ipa.example.com [centos 7.9 IPA 4.6.8] 4. Replica3.ipa.example.com [centos 7.9 IPA 4.6.8] What is the best approach to migrate it to alma Linux 9 As we all know in place upgrade is not possible Gone through below link, but still looking for an advice, what happens to existing replicas and its ipa clients after promoting Almalinux 8/9 server as IPA master server? does replication work in case of higher version of ipa master[4.10.2, Almalinux] and lower version of ipa replica [4.6.8,Centos 7] ? any impact on functionality of existing replicas servers of [centos 7.9 IPA 4.6.8]? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht… As I tested we can integrate ipa clients of lower version [4.6.8,centso 7] to ipa-server of higher version [4.10.2, Alma linux] As I tested we can't add replica of lower version[4.6.8,centso 7] to ipa-server of higher version[4.10.2, Alma linux] Regards Sai ________________________________ DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto. Thank you - OnMobile Global Limited.

2 1

dirsrv cannot start on new replica server
by Schweiss, Chip 18 Jan '24

18 Jan '24

I'm trying to add a new replica server to an existing FreeIPA domain. It is failing to start dirsrv because there is not enough ramdisk for the db cache. This is still a very small domain with less than one dozen users/hosts. Adding the first replica was not a problem about 5 months ago. This is on Rocky Linux 9.3 with all updates. Jan 18 18:27:00 ipa01.msp01.apld.ai ns-slapd[2033]: [18/Jan/2024:18:27:00.227167031 +0000] - INFO - bdb_config_upgrade_dse_info - create config entry from old config Jan 18 18:27:00 ipa01.msp01.apld.ai ns-slapd[2033]: [18/Jan/2024:18:27:00.229348479 +0000] - NOTICE - bdb_start_autotune - found 16435108k physical memory Jan 18 18:27:00 ipa01.msp01.apld.ai ns-slapd[2033]: [18/Jan/2024:18:27:00.229942914 +0000] - NOTICE - bdb_start_autotune - found 15545732k available Jan 18 18:27:00 ipa01.msp01.apld.ai ns-slapd[2033]: [18/Jan/2024:18:27:00.230458948 +0000] - NOTICE - bdb_start_autotune - cache autosizing: db cache: 1027194k Jan 18 18:27:00 ipa01.msp01.apld.ai ns-slapd[2033]: [18/Jan/2024:18:27:00.230996494 +0000] - NOTICE - bdb_start_autotune - total cache size: 1051846912 B; Jan 18 18:27:00 ipa01.msp01.apld.ai ns-slapd[2033]: [18/Jan/2024:18:27:00.231761490 +0000] - ERR - bdb_no_diskspace - No enough space left on device (/dev/shm/slapd-APLD-AI) (361705472 bytes); at least 1157031603 bytes space is needed for db region files Jan 18 18:27:00 ipa01.msp01.apld.ai ns-slapd[2033]: [18/Jan/2024:18:27:00.232231378 +0000] - ERR - ldbm_back_start - Failed to init database, err=28 Unexpected dbimpl error code The add replica command: # ipa-replica-install -n apld.ai -r APLD.AI -d --setup-dns --server= ipa01.den01.apld.ai --server=ipa02.den01.apld.ai --forwarder=10.53.30.21 --forwarder=10.53.30.22 --setup-ca --setup-adtrust --add-agents --mkhomedir -p {my_otp} I'm guessing something changed between RHEL/Rocky 9.2 and 9.3, and it wants much more RAM for the db here. However, the existing servers have been upgraded to 9.3 and start just fine. I've tried doubling the ram to 16GB, but the problem persists. Any idea what is going on or how to fix this? -Chip

1 0

Re: Create IPA user via LDAP
by Ronald Wimmer 18 Jan '24

18 Jan '24

On 08.01.24 17:58, Alexander Bokovoy wrote: > On Пан, 08 сту 2024, Ronald Wimmer wrote: >> On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote: >>> On 02.01.24 16:27, Rob Crittenden wrote: >>>> Ronald Wimmer via FreeIPA-users wrote: >>>>> >>>>> >>>>> On 14.12.23 14:42, Alexander Bokovoy wrote: >>>>>> On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote: >>>>>>> In our company we do have an IAM tool for user management. We >>>>>>> need to >>>>>>> create IPA users via this particular tool. I am aware of all IPA >>>>>>> commands or API calls to create/modify or delete a user. >>>>>>> >>>>>>> As the tool does not support FreeIPA yet they asked if there is a >>>>>>> way >>>>>>> to manage users by using LDAP only. Could that work? What about >>>>>>> attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber? >>>>>> >>>>>> Learn about lifecycle management. This is your way of integrating >>>>>> with >>>>>> such tools bvy creating staged users: >>>>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/ht… >>>>>> >>>>> >>>>> I followed the instructions from the documentation. >>>>> >>>>> How could I possibly overcome >>>>> >>>>> Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]: >>>>> ipa: ERROR: Constraint violation: pre-hashed passwords are not valid >>>>> >>>>> I need to set passwords from the external system. >>>> >>>> You need to enable migration mode (ipa config-mod --enable-migration >>>> true). >>>> >>>> By default a pre-hashed password can only be set once: during the user >>>> add operation. >>> >>> Ok. So this would not work for a password change. So if we need to >>> set an initial password and change that particular password in some >>> point in time the only feasible way is the IPA API, right? >>> >>> Can the immediate password expiration be overridden? >> >> As we have an upcoming please allow me to ask if I got the point here. >> >> I appreciate your support in this matter! >> > > I was looking over the code. The only way to accept pre-hashed passwords > is when they also have Kerberos keys set. This means you cannot use > external LDAP modify/add for that as you cannot create the Kerberos key > without knowing a Kerberos master key. > > So the only other option is to submit a clear-text password: > > userPassword: {CLEAR}text-password > > That will be accepted and if bind DN that performed this change is > either a cn=Directory Manager or a one from the passsync managers, it > would also not be marked for expiration immediately. > So. Am I right that our options are to use LDAP with a cleartext passwort or use the IPA API?

2 1

web login failed after upgrade
by 彭勇 18 Jan '24

18 Jan '24

when we upgrade ipa-server-4.9.12-9 to ipa-server-4.9.12-11 on RHEL 8, we can't login to web. the web give me message: “Your session has expired. Please log in again.” we check the error_log [Thu Jan 18 21:56:42.535394 2024] [auth_gssapi:error] [pid 11025:tid 139639453087488] [client 118.184.176.67:30891] Failed to unseal session data!, referer: https://id1.netegn.com/ipa/xml [Thu Jan 18 21:56:43.113937 2024] [wsgi:error] [pid 11021:tid 139639621613312] [remote 118.184.176.67:30891] 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) [Thu Jan 18 21:56:43.611962 2024] [wsgi:error] [pid 11023:tid 139639621613312] [remote 118.184.176.67:30893] 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) all three ipa server failed. we can't resolve the problem, we restore the snapshot and it recovery. we install RHEL 9.3 with ipa-server-4.10.2-5，set it as replicator of master ipa server, it has same problem. -- Peng Yong

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users January 2024