FreeIPA-users September 2026

freeipa-users@lists.fedorahosted.org

7 participants
5 discussions

OID management
by Olivier G 07 Sep '26

07 Sep '26

Hi everybody, I have read the documentation and some answers of this mailing list but things are stil unclear. Can you confirm (or not) my understanding of FreeIPA OIDs management: * FreeIPA does not allow to add a specific PEN number to its own root CA. * FreeIPA (as rootCA) allows to add PEN number to its SubCA thanks to certprofile (which are propagated to the final certificate). * FreeIPA used as SubCA keeps and manage specific PEN number 'given' by the root CA. Thanks in advance for reading, Olivier

2 3

FreeIPA 4.13.4
by Antonio Torres 07 Sep '26

07 Sep '26

The FreeIPA team would like to announce the FreeIPA 4.13.4 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora distributions will be available from the official repository soon. Full release notes are available at: https://www.freeipa.org/release-notes/4-13-4.html

1 0

ns-slapd uses 100% CPU, replications crash source servers, everything is terrible, send help
by Nerd Invert 06 Sep '26

06 Sep '26

I hardly know where to start describing this. I'm having tons of trouble adding a simple fourth replica to my setup, something I've done effortlessly in the past. The setup: Rocky Linux 8.10 all around, FreeIPA 4.9.13. Three servers: idm0, idm1 and idm2. I wish to add idm3. Very small database, maybe 50 users and 200 hosts. Has been going for 7-8 years so many hosts have a couple of expired certificates, but again, very small. I did an "ipa backup" recently and the resulting file was 80MB. I also checked one of my old logs, and then the replication took literally 10 seconds. Problem 1: replication doesn't work. It takes forever (hours) then either crashes or crashes the source server with an OOM killer fault. It should be noted that some of the source servers had very little memory, 4GB and the same for swap, but I have since upgraded. My install procedure for idm3 is: Turn off firewall on idm3 completely, to take that out of the equation. ipa-client-install --principal admin --no-ntp --no-nisdomain --force-join ipa-replica-install --debug --principal admin --setup-ca --setup-dns --forwarder=8.8.8.8 --forwarder=8.8.4.4 It makes it to step 26 where it's "replicating" and sits there forever. Problem 2: ns-slapd consumes 100% CPU for days on end, on some of the existing servers. The pattern of this behavior escapes me. It should be noted that I might have created an "idm3" host and tried to promote it to replica years ago. I deleted the host, but perhaps some replication agreements are lingering? Input on which log files I should follow and what I should try greatly appreciated.

2 1

change in behavior of pam passthrough
by Charles Hedrick 03 Sep '26

03 Sep '26

We use the ds389 pam passthrough, so that applications can authenticate with our ldap server and external radius authentication will work. (Almost all of our users have passwords stored on the University's active directory system. We run a radius proxy that does LDAP authentication to Active Directory.) There seems to be a change in behavior of the plugin between redhat 9 and 10. Our configuration is dsconf CS-RUTGERS-EDU plugin pam-pass-through-auth config default set --fallback TRUE --secure FALSE --filter "(ipatokenradiusconfiglink=*)" --id-attr ipatokenradiususername --id_map_method ENTRY That causes ds389 to use PAM when users are set to external radius authentication. PAM is set to use pam_radius to talk to our proxy. My understanding is that the filter is intended to cause the entry to apply only to users with ipatokenradiudconfiglink set. In fact it appears to apply to everyone, but to fail for users without ipatokenradiusconfiglink set. In the previous version fallback was false. In this release fallback has to be true. For everyone without ipatokenradiusconfiglink set we get a log message ERR - pam_passthru-plugin - do_one_pam_auth - Bind DN [uid=lXXX,cn=users,cn=accounts,dc=cs,dc=rutgers,dc=edu] is invalid or not found Watching network traffic, radius is only consulted for users with ipatokenradiusconfiglink, which of course is correct. So the only symptom is the log messages. In principle, however, it could cause logins to accept an old password where a user has changed from a local password to external radius. ds389 is 3.2.0-9.el10_2

3 4

Trust between FreeIPA and Keycloak
by Francis Augusto Medeiros-Logeay 03 Sep '26

03 Sep '26

Hi, I developed a Keycloak extension (Keycloak PSSO extension) so that users of managed macOS machines get SSO. The framework used - Platform Single Sign-on - also allows returning kerberos tickets. But I'm not sure how Keycloak could programmatically return kerberos tickets for a user without the password. Some of the pPlatform SSO flows do not involve using passwords. The idea I had first was to use my extension with some keytab with permissions to request kerberos tickets on behalf of other users. But has FreeIPA support for OAuth2 tokens, so that I could simply exchange an OAuth2 token to a kerberos tickets? This would be easier since I already control token issuing on the keycloak side. Best, Francis -- Francis Augusto Medeiros-Logeay Oslo, Norway

2 9

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users September 2026