Cannot login to FreeIPA as 'admin' user...
by Tom Spettigue
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.fedoraho...) 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?
3 months, 1 week
Permission / privilege to unlock accounts
by Russell Long
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 months, 2 weeks
Is there even one freeipa dev that knows everything about upgrading across major OS releases?
by Harry G Coin
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
3 months, 2 weeks
cannot login on FreeIPA web GUI: Your session has expired. Please log in again.
by Harald Dunkel
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
3 months, 2 weeks
Re: FreeIPA or RHEL IdM with Amazon Cognito
by Alexander Bokovoy
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-fl...
See
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
for RHEL IdM documentation.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
3 months, 2 weeks
FreeIPA or RHEL IdM with Amazon Cognito
by Carlos Lopez
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
3 months, 2 weeks
Different ID ranges cannot login to samba
by Rui Gomes
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
3 months, 2 weeks
Can't login to IPA
by Bogdan Stoica
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.
3 months, 2 weeks
Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
by Alexander Bokovoy
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.fedoraho...
>
>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/...> and Security Identifiers<https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html#security...> 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.fedoraho...
>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.fedoraho...
>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
3 months, 2 weeks
