Hi, I see the same problem on my IPA installations for around one or two weeks now. All affected machines run FreeIPA 4.9.13-20. * one machine is a RHEL 8.10 standalone deployment * two machines are AlmaLinux 8.10 sync between each other * All instances have the full capability, DNS, Certificate Authority and acme. These installations are not related and in different companys. On the first RHEL machine, users are listed, groups are not, some other object types are missing, you can find objects by searching for the name, same with ipa find-user. Fresh created users/group/hosts work fine and show up in Web interface and ipa find-user. On the second pair (running AlmaLinux), its a bit different, no users, groups, hosts, sudo rules etc. are shown, only fresh created objects show up by using the Web interface or using ipa command. DNS is a bit different, on IPA1, all DNS zones are visible, on IPA2, no zones are visible, except i create a new zone. Luckly i still can see all zones on IPA1. Searching for DNS zones on IPA2 does not work, but i can reach the zone by changing the url to “/ipa/ui/#/e/dnszone/records/mydomain.com” on IPA2, so they are there and accessible. I tried to edit existing objects to see if they pop up, but no luck. I ran ipa-server-upgrade to see if some migration is missing, but it finish without issue and the problem persist. No issues with DNS lookups, getting certs or provide authentication, just searching/showing objects is broken I have no clue how to fix that, i can see no “useful” information in my slapd logs or i dont know what to lock for.
Sven Jansen via FreeIPA-users wrote:
Hi,
I see the same problem on my IPA installations for around one or two weeks now. All affected machines run FreeIPA 4.9.13-20.
- one machine is a RHEL 8.10 standalone deployment
- two machines are AlmaLinux 8.10 sync between each other
- All instances have the full capability, DNS, Certificate Authority and acme.
These installations are not related and in different companys. On the first RHEL machine, users are listed, groups are not, some other object types are missing, you can find objects by searching for the name, same with ipa find-user. Fresh created users/group/hosts work fine and show up in Web interface and ipa find-user.
Can you be more precise? Users are listed where? Through SSSD/nss? Via the command-line/UI tools? Are they in LDAP?
In what context is this happening? Did it start out of the blue or after something was done? It may even be something that seems benign.
On the second pair (running AlmaLinux), its a bit different, no users, groups, hosts, sudo rules etc. are shown, only fresh created objects show up by using the Web interface or using ipa command. DNS is a bit different, on IPA1, all DNS zones are visible, on IPA2, no zones are visible, except i create a new zone. Luckly i still can see all zones on IPA1. Searching for DNS zones on IPA2 does not work, but i can reach the zone by changing the url to “/ipa/ui/#/e/dnszone/records/mydomain.com” on IPA2, so they are there and accessible.
I tried to edit existing objects to see if they pop up, but no luck. I ran ipa-server-upgrade to see if some migration is missing, but it finish without issue and the problem persist.
No issues with DNS lookups, getting certs or provide authentication, just searching/showing objects is broken I have no clue how to fix that, i can see no “useful” information in my slapd logs or i dont know what to lock for.
How are you authenticating? If no users exist then its quite surprising that you can authenticate. Do you see them in LDAP?
rob
Hi Rob, okay that not easy to explain… this affects mulitple installations. the objects are in ldap and they work. When i log into FreeIPA UI, Users, Group, Hosts, Sudo, Hostgroup and some other object types are total empty. Same if i use ipa command, if i use “ipa user-find” without entering a search term, i get nothing. If i do a specific search for an object, i find it, except DNS, there is no way to get dns zones except you know what you have to hack into the url to get into the zone (/ipa/#/e/dnszone/records/zonename…), search show no zones. Lets give you an example, this is a server with around 20-30 Users, 10-15 DNS zones, handful groups, sudo rules, host groups, etc., ipa1 + ipa2 sync with each other, both authenticate users, deliver dns and certificates, so this servers do their job until you want to find/browse something. Lets do a simple query without a term [root@ipa1 /]# ipa user-find --------------- 0 users matched --------------- ---------------------------- Number of entries returned 0 ---------------------------- I get nothing, but users should be visible. Same behaviour in the Web UI, nothing, all above mentions areas are empty. Now lets do a search with a term to find something specific i know [root@ipa1 /]# ipa user-find testuser -------------- 1 user matched -------------- User login: testuser First name: XXX Last name: XXX Home directory: /home/testuser Login shell: /usr/bin/zsh Principal name: testuser@XXX Principal alias: testuser@XXX Email address: testuser@XXX UID: 357400030 GID: 357400030 Account disabled: True ---------------------------- Number of entries returned 1 ---------------------------- [root@ipa1 /]# id testuser uid=357400030(testuser) gid=357400030(testuser) … Now we get something, same behaveiour in the Web GUI, search for a existing object and you find it. Lets create a fresh object, like a user, could also be a group or dns zone, doesnt matter, outcome is the same [root@ipa1 /]# ipa user-add First name: demo Last name: user User login [duser]: duser ------------------ Added user "duser" ------------------ User login: duser First name: demo Last name: user Full name: demo user Display name: demo user Initials: du Home directory: /home/duser GECOS: demo user Login shell: /usr/bin/zsh Principal name: duser@XXX Principal alias: duser@XXX Email address: duser@XXX UID: 357400068 GID: 357400068 Password: False Member of groups: ipausers Kerberos keys available: False Now again search with no search term [root@ipa1 /]# ipa user-find -------------- 1 user matched -------------- User login: duser First name: demo Last name: user Home directory: /home/duser Login shell: /usr/bin/zsh Principal name: duser@xxx Principal alias: duser@xxx Email address: duser@xxx UID: 357400068 GID: 357400068 Account disabled: False ---------------------------- Number of entries returned 1 ---------------------------- Now we see a result without searching for something specific and this also works in the Web UI, it just show this new user in the users tab, not the other ~30 or the testuser i search for above. Conclusion: no data in LDAP is missing, the api (used by Web UI and ipa command) is unable to show existing “old” objects until i search specificly for an known object, all new generated objects are always visible/listed. This is of course really bad, if you dont know what to search for, you cant find anything this way. This is not just this installation, another standalone installation on a customer site behave like this, and just now, i found this also affects my private system. So three installation in total. All Installation are based on RHEL 8.10 or AlmaLinux 8.10. IPA on all systems is 4.9.13-20. This issue first appeared ~1 weeks ago and like the OP, the impact is visible after a reboot. Sven
Am Montag, Januar 19, 2026 19:12 CET, schrieb Rob Crittenden rcritten@redhat.com:
Sven Jansen via FreeIPA-users wrote:
Hi, I see the same problem on my IPA installations for around one or two weeks now. All affected machines run FreeIPA 4.9.13-20.
- one machine is a RHEL 8.10 standalone deployment
- two machines are AlmaLinux 8.10 sync between each other
- All instances have the full capability, DNS, Certificate Authority
and acme. These installations are not related and in different companys. On the first RHEL machine, users are listed, groups are not, some other object types are missing, you can find objects by searching for the name, same with ipa find-user. Fresh created users/group/hosts work fine and show up in Web interface and ipa find-user.
Can you be more precise? Users are listed where? Through SSSD/nss? Via the command-line/UI tools? Are they in LDAP?
In what context is this happening? Did it start out of the blue or after something was done? It may even be something that seems benign.
On the second pair (running AlmaLinux), its a bit different, no users, groups, hosts, sudo rules etc. are shown, only fresh created objects show up by using the Web interface or using ipa command. DNS is a bit different, on IPA1, all DNS zones are visible, on IPA2, no zones are visible, except i create a new zone. Luckly i still can see all zones on IPA1. Searching for DNS zones on IPA2 does not work, but i can reach the zone by changing the url to “/ipa/ui/#/e/dnszone/records/mydomain.com” on IPA2, so they are there and accessible. I tried to edit existing objects to see if they pop up, but no luck. I ran ipa-server-upgrade to see if some migration is missing, but it finish without issue and the problem persist. No issues with DNS lookups, getting certs or provide authentication, just searching/showing objects is broken I have no clue how to fix that, i can see no “useful” information in my slapd logs or i dont know what to lock for.
How are you authenticating? If no users exist then its quite surprising that you can authenticate. Do you see them in LDAP?
rob
See https://github.com/389ds/389-ds-base/issues/7193 and the referenced issues. It is regression in 389-ds update.
Hi Alexander, thank you for the reference. Do you have any idea how to fix affected installations? is this something that can be resolved in a future ipa version or do we have to apply some sort of fix to 389ds content? It looks like that affected 389ds package arrived last month, doing a alsmost one month rollback is not an option. Yesterday i tried to move away from rhel8 by spinning up a rhel10 based replica, i hoped this may fix the issue with a “broken ipa” in rhel8, at that point, i didnt know this was a 389ds issue. That didnt work so well, setup script failed due to missing data in the source directory, looks like this is also affected by the 389ds issue. Sven
Am Dienstag, Januar 20, 2026 02:11 CET, schrieb Alexander Bokovoy abokovoy@redhat.com:
See https://github.com/389ds/389-ds-base/issues/7193 and the referenced issues. It is regression in 389-ds update. -- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity Management EngineeringRed Hat Limited, Finland
On Tue, 20 Jan 2026, 0.12 Sven Jansen via FreeIPA-users, freeipa-users@lists.fedorahosted.org wrote: Hi Rob, okay that not easy to explain… this affects mulitple installations. the objects are in ldap and they work. When i log into FreeIPA UI, Users, Group, Hosts, Sudo, Hostgroup and some other object types are total empty. Same if i use ipa command, if i use “ipa user-find” without entering a search term, i get nothing. If i do a specific search for an object, i find it, except DNS, there is no way to get dns zones except you know what you have to hack into the url to get into the zone (/ipa/#/e/dnszone/records/zonename…), search show no zones. Lets give you an example, this is a server with around 20-30 Users, 10-15 DNS zones, handful groups, sudo rules, host groups, etc., ipa1 + ipa2 sync with each other, both authenticate users, deliver dns and certificates, so this servers do their job until you want to find/browse something. Lets do a simple query without a term [root@ipa1 /]# ipa user-find --------------- 0 users matched --------------- ---------------------------- Number of entries returned 0 ---------------------------- I get nothing, but users should be visible. Same behaviour in the Web UI, nothing, all above mentions areas are empty. Now lets do a search with a term to find something specific i know [root@ipa1 /]# ipa user-find testuser -------------- 1 user matched -------------- User login: testuser First name: XXX Last name: XXX Home directory: /home/testuser Login shell: /usr/bin/zsh Principal name: testuser@XXX Principal alias: testuser@XXX Email address: testuser@XXX UID: 357400030 GID: 357400030 Account disabled: True ---------------------------- Number of entries returned 1 ---------------------------- [root@ipa1 /]# id testuser uid=357400030(testuser) gid=357400030(testuser) … Now we get something, same behaveiour in the Web GUI, search for a existing object and you find it. Lets create a fresh object, like a user, could also be a group or dns zone, doesnt matter, outcome is the same [root@ipa1 /]# ipa user-add First name: demo Last name: user User login [duser]: duser ------------------ Added user "duser" ------------------ User login: duser First name: demo Last name: user Full name: demo user Display name: demo user Initials: du Home directory: /home/duser GECOS: demo user Login shell: /usr/bin/zsh Principal name: duser@XXX Principal alias: duser@XXX Email address: duser@XXX UID: 357400068 GID: 357400068 Password: False Member of groups: ipausers Kerberos keys available: False Now again search with no search term [root@ipa1 /]# ipa user-find -------------- 1 user matched -------------- User login: duser First name: demo Last name: user Home directory: /home/duser Login shell: /usr/bin/zsh Principal name: duser@xxx Principal alias: duser@xxx Email address: duser@xxx UID: 357400068 GID: 357400068 Account disabled: False ---------------------------- Number of entries returned 1 ---------------------------- Now we see a result without searching for something specific and this also works in the Web UI, it just show this new user in the users tab, not the other ~30 or the testuser i search for above. Conclusion: no data in LDAP is missing, the api (used by Web UI and ipa command) is unable to show existing “old” objects until i search specificly for an known object, all new generated objects are always visible/listed. This is of course really bad, if you dont know what to search for, you cant find anything this way. This is not just this installation, another standalone installation on a customer site behave like this, and just now, i found this also affects my private system. So three installation in total. All Installation are based on RHEL 8.10 or AlmaLinux 8.10. IPA on all systems is 4.9.13-20. This issue first appeared ~1 weeks ago and like the OP, the impact is visible after a reboot. Sven
Am Montag, Januar 19, 2026 19:12 CET, schrieb Rob Crittenden rcritten@redhat.com:
Sven Jansen via FreeIPA-users wrote:
Hi, I see the same problem on my IPA installations for around one or two weeks now. All affected machines run FreeIPA 4.9.13-20.
- one machine is a RHEL 8.10 standalone deployment
- two machines are AlmaLinux 8.10 sync between each other
- All instances have the full capability, DNS, Certificate Authority
and acme. These installations are not related and in different companys. On the first RHEL machine, users are listed, groups are not, some other object types are missing, you can find objects by searching for the name, same with ipa find-user. Fresh created users/group/hosts work fine and show up in Web interface and ipa find-user.
Can you be more precise? Users are listed where? Through SSSD/nss? Via the command-line/UI tools? Are they in LDAP?
In what context is this happening? Did it start out of the blue or after something was done? It may even be something that seems benign.
On the second pair (running AlmaLinux), its a bit different, no users, groups, hosts, sudo rules etc. are shown, only fresh created objects show up by using the Web interface or using ipa command. DNS is a bit different, on IPA1, all DNS zones are visible, on IPA2, no zones are visible, except i create a new zone. Luckly i still can see all zones on IPA1. Searching for DNS zones on IPA2 does not work, but i can reach the zone by changing the url to “/ipa/ui/#/e/dnszone/records/mydomain.com” on IPA2, so they are there and accessible. I tried to edit existing objects to see if they pop up, but no luck. I ran ipa-server-upgrade to see if some migration is missing, but it finish without issue and the problem persist. No issues with DNS lookups, getting certs or provide authentication, just searching/showing objects is broken I have no clue how to fix that, i can see no “useful” information in my slapd logs or i dont know what to lock for.
How are you authenticating? If no users exist then its quite surprising that you can authenticate. Do you see them in LDAP?
rob
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Аўт, 20 сту 2026, Sven Jansen wrote:
Hi Alexander, thank you for the reference. Do you have any idea how to fix affected installations? is this something that can be resolved in a future ipa version or do we have to apply some sort of fix to 389ds content? It looks like that affected 389ds package arrived last month, doing a alsmost one month rollback is not an option. Yesterday i tried to move away from rhel8 by spinning up a rhel10 based replica, i hoped this may fix the issue with a “broken ipa” in rhel8, at that point, i didnt know this was a 389ds issue. That didnt work so well, setup script failed due to missing data in the source directory, looks like this is also affected by the 389ds issue.
Yes, it is an incomplete fix of https://github.com/389ds/389-ds-base/issues/6928 which, in turn, caused a lot of problems for FreeIPA as soon as it got deployed in Fedora, RHEL, and downstreams, as you can see in https://github.com/389ds/389-ds-base/issues/7172 (which, in turn, was detected by https://github.com/freeipa/freeipa-container/issues/709 and https://github.com/freeipa/freeipa-container/issues/710)
The RHEL 8 issue https://issues.redhat.com/browse/RHEL-140086 is now Closed Done-Errata, with https://access.redhat.com/errata/RHBA-2026:0834 released today. The NVR is 389-ds-base-1.4.3.39-20.module+el8.10.0+23856+6590d6ad.
Downstreams of RHEL will probably handle it at some point.
Sven
Am Dienstag, Januar 20, 2026 02:11 CET, schrieb Alexander Bokovoy abokovoy@redhat.com:
See https://github.com/389ds/389-ds-base/issues/7193 and the referenced issues. It is regression in 389-ds update. -- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity Management EngineeringRed Hat Limited, Finland
On Tue, 20 Jan 2026, 0.12 Sven Jansen via FreeIPA-users, freeipa-users@lists.fedorahosted.org wrote: Hi Rob, okay that not easy to explain… this affects mulitple installations. the objects are in ldap and they work. When i log into FreeIPA UI, Users, Group, Hosts, Sudo, Hostgroup and some other object types are total empty. Same if i use ipa command, if i use “ipa user-find” without entering a search term, i get nothing. If i do a specific search for an object, i find it, except DNS, there is no way to get dns zones except you know what you have to hack into the url to get into the zone (/ipa/#/e/dnszone/records/zonename…), search show no zones. Lets give you an example, this is a server with around 20-30 Users, 10-15 DNS zones, handful groups, sudo rules, host groups, etc., ipa1 + ipa2 sync with each other, both authenticate users, deliver dns and certificates, so this servers do their job until you want to find/browse something. Lets do a simple query without a term [root@ipa1 /]# ipa user-find
0 users matched
Number of entries returned 0
I get nothing, but users should be visible. Same behaviour in the Web UI, nothing, all above mentions areas are empty. Now lets do a search with a term to find something specific i know [root@ipa1 /]# ipa user-find testuser
1 user matched
User login: testuser First name: XXX Last name: XXX Home directory: /home/testuser Login shell: /usr/bin/zsh Principal name: testuser@XXX Principal alias: testuser@XXX Email address: testuser@XXX UID: 357400030 GID: 357400030 Account disabled: True
Number of entries returned 1
[root@ipa1 /]# id testuser uid=357400030(testuser) gid=357400030(testuser) … Now we get something, same behaveiour in the Web GUI, search for a existing object and you find it. Lets create a fresh object, like a user, could also be a group or dns zone, doesnt matter, outcome is the same [root@ipa1 /]# ipa user-add First name: demo Last name: user User login [duser]: duser
Added user "duser"
User login: duser First name: demo Last name: user Full name: demo user Display name: demo user Initials: du Home directory: /home/duser GECOS: demo user Login shell: /usr/bin/zsh Principal name: duser@XXX Principal alias: duser@XXX Email address: duser@XXX UID: 357400068 GID: 357400068 Password: False Member of groups: ipausers Kerberos keys available: False Now again search with no search term [root@ipa1 /]# ipa user-find
1 user matched
User login: duser First name: demo Last name: user Home directory: /home/duser Login shell: /usr/bin/zsh Principal name: duser@xxx Principal alias: duser@xxx Email address: duser@xxx UID: 357400068 GID: 357400068 Account disabled: False
Number of entries returned 1
Now we see a result without searching for something specific and this also works in the Web UI, it just show this new user in the users tab, not the other ~30 or the testuser i search for above. Conclusion: no data in LDAP is missing, the api (used by Web UI and ipa command) is unable to show existing “old” objects until i search specificly for an known object, all new generated objects are always visible/listed. This is of course really bad, if you dont know what to search for, you cant find anything this way. This is not just this installation, another standalone installation on a customer site behave like this, and just now, i found this also affects my private system. So three installation in total. All Installation are based on RHEL 8.10 or AlmaLinux 8.10. IPA on all systems is 4.9.13-20. This issue first appeared ~1 weeks ago and like the OP, the impact is visible after a reboot. Sven
Am Montag, Januar 19, 2026 19:12 CET, schrieb Rob Crittenden rcritten@redhat.com:
Sven Jansen via FreeIPA-users wrote:
Hi, I see the same problem on my IPA installations for around one or two weeks now. All affected machines run FreeIPA 4.9.13-20.
- one machine is a RHEL 8.10 standalone deployment
- two machines are AlmaLinux 8.10 sync between each other
- All instances have the full capability, DNS, Certificate Authority
and acme. These installations are not related and in different companys. On the first RHEL machine, users are listed, groups are not, some other object types are missing, you can find objects by searching for the name, same with ipa find-user. Fresh created users/group/hosts work fine and show up in Web interface and ipa find-user.
Can you be more precise? Users are listed where? Through SSSD/nss? Via the command-line/UI tools? Are they in LDAP?
In what context is this happening? Did it start out of the blue or after something was done? It may even be something that seems benign.
On the second pair (running AlmaLinux), its a bit different, no users, groups, hosts, sudo rules etc. are shown, only fresh created objects show up by using the Web interface or using ipa command. DNS is a bit different, on IPA1, all DNS zones are visible, on IPA2, no zones are visible, except i create a new zone. Luckly i still can see all zones on IPA1. Searching for DNS zones on IPA2 does not work, but i can reach the zone by changing the url to “/ipa/ui/#/e/dnszone/records/mydomain.com” on IPA2, so they are there and accessible. I tried to edit existing objects to see if they pop up, but no luck. I ran ipa-server-upgrade to see if some migration is missing, but it finish without issue and the problem persist. No issues with DNS lookups, getting certs or provide authentication, just searching/showing objects is broken I have no clue how to fix that, i can see no “useful” information in my slapd logs or i dont know what to lock for.
How are you authenticating? If no users exist then its quite surprising that you can authenticate. Do you see them in LDAP?
rob
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hallo Alexander, thank you for your help, i just updated one of my system with 1.4.3.39-20 and i can confirm it “almost” work. objects created before 1.4.3.39-19 is visible again objects created with the bugged version 1.4.3.39-19 is now hidden and can only by found by using search objectes created with 1.4.3.39-20 is also visible Best regards, Sven
Am Dienstag, Januar 20, 2026 11:17 CET, schrieb Alexander Bokovoy abokovoy@redhat.com:
On Аўт, 20 сту 2026, Sven Jansen wrote:
Hi Alexander, thank you for the reference. Do you have any idea how to fix affected installations? is this something that can be resolved in a future ipa version or do we have to apply some sort of fix to 389ds content? It looks like that affected 389ds package arrived last month, doing a alsmost one month rollback is not an option. Yesterday i tried to move away from rhel8 by spinning up a rhel10 based replica, i hoped this may fix the issue with a “broken ipa” in rhel8, at that point, i didnt know this was a 389ds issue. That didnt work so well, setup script failed due to missing data in the source directory, looks like this is also affected by the 389ds issue.
Yes, it is an incomplete fix of https://github.com/389ds/389-ds-base/issues/6928 which, in turn, caused a lot of problems for FreeIPA as soon as it got deployed in Fedora, RHEL, and downstreams, as you can see in https://github.com/389ds/389-ds-base/issues/7172 (which, in turn, was detected by https://github.com/freeipa/freeipa-container/issues/709 and https://github.com/freeipa/freeipa-container/issues/710)
The RHEL 8 issue https://issues.redhat.com/browse/RHEL-140086 is now Closed Done-Errata, with https://access.redhat.com/errata/RHBA-2026:0834 released today. The NVR is 389-ds-base-1.4.3.39-20.module+el8.10.0+23856+6590d6ad.
Downstreams of RHEL will probably handle it at some point.
Sven
Am Dienstag, Januar 20, 2026 02:11 CET, schrieb Alexander Bokovoy abokovoy@redhat.com:
See https://github.com/389ds/389-ds-base/issues/7193 and the referenced issues. It is regression in 389-ds update. -- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity Management EngineeringRed Hat Limited, Finland
On Tue, 20 Jan 2026, 0.12 Sven Jansen via FreeIPA-users, freeipa-users@lists.fedorahosted.org wrote: Hi Rob, okay that not easy to explain… this affects mulitple installations. the objects are in ldap and they work. When i log into FreeIPA UI, Users, Group, Hosts, Sudo, Hostgroup and some other object types are total empty. Same if i use ipa command, if i use “ipa user-find” without entering a search term, i get nothing. If i do a specific search for an object, i find it, except DNS, there is no way to get dns zones except you know what you have to hack into the url to get into the zone (/ipa/#/e/dnszone/records/zonename…), search show no zones. Lets give you an example, this is a server with around 20-30 Users, 10-15 DNS zones, handful groups, sudo rules, host groups, etc., ipa1 + ipa2 sync with each other, both authenticate users, deliver dns and certificates, so this servers do their job until you want to find/browse something. Lets do a simple query without a term [root@ipa1 /]# ipa user-find
0 users matched
Number of entries returned 0
I get nothing, but users should be visible. Same behaviour in the Web UI, nothing, all above mentions areas are empty. Now lets do a search with a term to find something specific i know [root@ipa1 /]# ipa user-find testuser
1 user matched
User login: testuser First name: XXX Last name: XXX Home directory: /home/testuser Login shell: /usr/bin/zsh Principal name: testuser@XXX Principal alias: testuser@XXX Email address: testuser@XXX UID: 357400030 GID: 357400030 Account disabled: True
Number of entries returned 1
[root@ipa1 /]# id testuser uid=357400030(testuser) gid=357400030(testuser) … Now we get something, same behaveiour in the Web GUI, search for a existing object and you find it. Lets create a fresh object, like a user, could also be a group or dns zone, doesnt matter, outcome is the same [root@ipa1 /]# ipa user-add First name: demo Last name: user User login [duser]: duser
Added user "duser"
User login: duser First name: demo Last name: user Full name: demo user Display name: demo user Initials: du Home directory: /home/duser GECOS: demo user Login shell: /usr/bin/zsh Principal name: duser@XXX Principal alias: duser@XXX Email address: duser@XXX UID: 357400068 GID: 357400068 Password: False Member of groups: ipausers Kerberos keys available: False Now again search with no search term [root@ipa1 /]# ipa user-find
1 user matched
User login: duser First name: demo Last name: user Home directory: /home/duser Login shell: /usr/bin/zsh Principal name: duser@xxx Principal alias: duser@xxx Email address: duser@xxx UID: 357400068 GID: 357400068 Account disabled: False
Number of entries returned 1
Now we see a result without searching for something specific and this also works in the Web UI, it just show this new user in the users tab, not the other ~30 or the testuser i search for above. Conclusion: no data in LDAP is missing, the api (used by Web UI and ipa command) is unable to show existing “old” objects until i search specificly for an known object, all new generated objects are always visible/listed. This is of course really bad, if you dont know what to search for, you cant find anything this way. This is not just this installation, another standalone installation on a customer site behave like this, and just now, i found this also affects my private system. So three installation in total. All Installation are based on RHEL 8.10 or AlmaLinux 8.10. IPA on all systems is 4.9.13-20. This issue first appeared ~1 weeks ago and like the OP, the impact is visible after a reboot. Sven
Am Montag, Januar 19, 2026 19:12 CET, schrieb Rob Crittenden rcritten@redhat.com:
Sven Jansen via FreeIPA-users wrote:
Hi, I see the same problem on my IPA installations for around one or two weeks now. All affected machines run FreeIPA 4.9.13-20.
- one machine is a RHEL 8.10 standalone deployment
- two machines are AlmaLinux 8.10 sync between each other
- All instances have the full capability, DNS, Certificate Authority
and acme. These installations are not related and in different companys. On the first RHEL machine, users are listed, groups are not, some other object types are missing, you can find objects by searching for the name, same with ipa find-user. Fresh created users/group/hosts work fine and show up in Web interface and ipa find-user.
Can you be more precise? Users are listed where? Through SSSD/nss? Via the command-line/UI tools? Are they in LDAP?
In what context is this happening? Did it start out of the blue or after something was done? It may even be something that seems benign.
On the second pair (running AlmaLinux), its a bit different, no users, groups, hosts, sudo rules etc. are shown, only fresh created objects show up by using the Web interface or using ipa command. DNS is a bit different, on IPA1, all DNS zones are visible, on IPA2, no zones are visible, except i create a new zone. Luckly i still can see all zones on IPA1. Searching for DNS zones on IPA2 does not work, but i can reach the zone by changing the url to “/ipa/ui/#/e/dnszone/records/mydomain.com” on IPA2, so they are there and accessible. I tried to edit existing objects to see if they pop up, but no luck. I ran ipa-server-upgrade to see if some migration is missing, but it finish without issue and the problem persist. No issues with DNS lookups, getting certs or provide authentication, just searching/showing objects is broken I have no clue how to fix that, i can see no “useful” information in my slapd logs or i dont know what to lock for.
How are you authenticating? If no users exist then its quite surprising that you can authenticate. Do you see them in LDAP?
rob
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste... 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
On 1/20/26 11:17 AM, Alexander Bokovoy via FreeIPA-users wrote:
On Аўт, 20 сту 2026, Sven Jansen wrote:
Hi Alexander, thank you for the reference. Do you have any idea how to fix affected installations? is this something that can be resolved in a future ipa version or do we have to apply some sort of fix to 389ds content? It looks like that affected 389ds package arrived last month, doing a alsmost one month rollback is not an option. Yesterday i tried to move away from rhel8 by spinning up a rhel10 based replica, i hoped this may fix the issue with a “broken ipa” in rhel8, at that point, i didnt know this was a 389ds issue. That didnt work so well, setup script failed due to missing data in the source directory, looks like this is also affected by the 389ds issue.
Yes, it is an incomplete fix of https://github.com/389ds/389-ds-base/issues/6928 which, in turn, caused a lot of problems for FreeIPA as soon as it got deployed in Fedora, RHEL, and downstreams, as you can see in https://github.com/389ds/389-ds-base/issues/7172 (which, in turn, was detected by https://github.com/freeipa/freeipa-container/issues/709 and https://github.com/freeipa/freeipa-container/issues/710)
The RHEL 8 issue https://issues.redhat.com/browse/RHEL-140086 is now Closed Done-Errata, with https://access.redhat.com/errata/RHBA-2026:0834 released today. The NVR is 389-ds-base-1.4.3.39-20.module+el8.10.0+23856+6590d6ad.
Downstreams of RHEL will probably handle it at some point.
If you run DS healthcheck (dsctl instance healthcheck) it should detail the operations to recover the indexes.
In short, for each backend, you should add integer matching rule to parentid/ancestorid and limit the size of idl they produce. then Reindex
|dsconf instance_name backend index set backend_name --attr parentid --add-mr integerOrderingMatch dsconf instance_name backend index set ||backend_name||--attr parentid --add-scanlimit limit=5000 dsconf instance_name backend index add ||backend_name||--attr ancestorid --index-type eq --matching-rule integerOrderingMatch ||dsconf instance_name backend index reindex backend_name --attr ancestorid ||dsconf instance_name backend index reindex backend_name --attr parentid The reindex is CPU intensive it is recommended to run it during a calm period. regards thierry |
Sven
Am Dienstag, Januar 20, 2026 02:11 CET, schrieb Alexander Bokovoy abokovoy@redhat.com:
See https://github.com/389ds/389-ds-base/issues/7193 and the referenced issues. It is regression in 389-ds update. -- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity Management EngineeringRed Hat Limited, Finland
On Tue, 20 Jan 2026, 0.12 Sven Jansen via FreeIPA-users, freeipa-users@lists.fedorahosted.org wrote:
Hi Rob, okay that not easy to explain… this affects mulitple installations. the objects are in ldap and they work. When i log into FreeIPA UI, Users, Group, Hosts, Sudo, Hostgroup and some other object types are total empty. Same if i use ipa command, if i use “ipa user-find” without entering a search term, i get nothing. If i do a specific search for an object, i find it, except DNS, there is no way to get dns zones except you know what you have to hack into the url to get into the zone (/ipa/#/e/dnszone/records/zonename…), search show no zones. Lets give you an example, this is a server with around 20-30 Users, 10-15 DNS zones, handful groups, sudo rules, host groups, etc., ipa1
- ipa2 sync with each other, both authenticate users, deliver dns and
certificates, so this servers do their job until you want to find/browse something.
Lets do a simple query without a term [root@ipa1 /]# ipa user-find
0 users matched
Number of entries returned 0
I get nothing, but users should be visible. Same behaviour in the Web UI, nothing, all above mentions areas are empty.
Now lets do a search with a term to find something specific i know [root@ipa1 /]# ipa user-find testuser
1 user matched
User login: testuser First name: XXX Last name: XXX Home directory: /home/testuser Login shell: /usr/bin/zsh Principal name: testuser@XXX Principal alias: testuser@XXX Email address: testuser@XXX UID: 357400030 GID: 357400030 Account disabled: True
Number of entries returned 1
[root@ipa1 /]# id testuser uid=357400030(testuser) gid=357400030(testuser) … Now we get something, same behaveiour in the Web GUI, search for a existing object and you find it.
Lets create a fresh object, like a user, could also be a group or dns zone, doesnt matter, outcome is the same [root@ipa1 /]# ipa user-add First name: demo Last name: user User login [duser]: duser
Added user "duser"
User login: duser First name: demo Last name: user Full name: demo user Display name: demo user Initials: du Home directory: /home/duser GECOS: demo user Login shell: /usr/bin/zsh Principal name: duser@XXX Principal alias: duser@XXX Email address: duser@XXX UID: 357400068 GID: 357400068 Password: False Member of groups: ipausers Kerberos keys available: False Now again search with no search term [root@ipa1 /]# ipa user-find
1 user matched
User login: duser First name: demo Last name: user Home directory: /home/duser Login shell: /usr/bin/zsh Principal name: duser@xxx Principal alias: duser@xxx Email address: duser@xxx UID: 357400068 GID: 357400068 Account disabled: False
Number of entries returned 1
Now we see a result without searching for something specific and this also works in the Web UI, it just show this new user in the users tab, not the other ~30 or the testuser i search for above.
Conclusion: no data in LDAP is missing, the api (used by Web UI and ipa command) is unable to show existing “old” objects until i search specificly for an known object, all new generated objects are always visible/listed. This is of course really bad, if you dont know what to search for, you cant find anything this way. This is not just this installation, another standalone installation on a customer site behave like this, and just now, i found this also affects my private system. So three installation in total. All Installation are based on RHEL 8.10 or AlmaLinux 8.10. IPA on all systems is 4.9.13-20. This issue first appeared ~1 weeks ago and like the OP, the impact is visible after a reboot.
Sven
Am Montag, Januar 19, 2026 19:12 CET, schrieb Rob Crittenden rcritten@redhat.com:
Sven Jansen via FreeIPA-users wrote:
Hi,
I see the same problem on my IPA installations for around one or two weeks now. All affected machines run FreeIPA 4.9.13-20.
- one machine is a RHEL 8.10 standalone deployment
- two machines are AlmaLinux 8.10 sync between each other
- All instances have the full capability, DNS, Certificate Authority
and acme.
These installations are not related and in different companys. On the first RHEL machine, users are listed, groups are not, some other object types are missing, you can find objects by searching for the name, same with ipa find-user. Fresh created users/group/hosts work fine and show up in Web interface and ipa find-user.
Can you be more precise? Users are listed where? Through SSSD/nss? Via the command-line/UI tools? Are they in LDAP?
In what context is this happening? Did it start out of the blue or after something was done? It may even be something that seems benign.
On the second pair (running AlmaLinux), its a bit different, no users, groups, hosts, sudo rules etc. are shown, only fresh created objects show up by using the Web interface or using ipa command. DNS is a bit different, on IPA1, all DNS zones are visible, on IPA2, no zones are visible, except i create a new zone. Luckly i still can see all zones on IPA1. Searching for DNS zones on IPA2 does not work, but i can reach the zone by changing the url to “/ipa/ui/#/e/dnszone/records/mydomain.com” on IPA2, so they are there and accessible.
I tried to edit existing objects to see if they pop up, but no luck. I ran ipa-server-upgrade to see if some migration is missing, but it finish without issue and the problem persist.
No issues with DNS lookups, getting certs or provide authentication, just searching/showing objects is broken I have no clue how to fix that, i can see no “useful” information in my slapd logs or i dont know what to lock for.
How are you authenticating? If no users exist then its quite surprising that you can authenticate. Do you see them in LDAP?
rob
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to 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.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Rob Crittenden -
Sven Jansen -
Thierry Bordaz