FreeIPA-users September 2026

freeipa-users@lists.fedorahosted.org

12 participants
7 discussions

Configuration between IPA and AD question
by Ty zang 10 Sep '26

10 Sep '26

Hey all, I have been fighting this IPA/AD trust configuration for almost 3 weeks now and I am a bit stumped. Technically, the trust is working but because our AD is so large and complex, I am seeing a lot of latency which (i believe) is breaking authentication to my servers. Here is a little background: AD is layed out: +----------------------------------------+ | ACTIVE DIRECTORY FOREST | | W.NET | | (Forest Root Domain) | +----------------------------------------+ | +-------------------------+--------------------------------------+ | | | | | +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ | S.W.NET | | B.W.NET | | H.W.NET | | R.W.NET | | V.W.NET | | (Users & | | (Users & | | (Ignored/ | | (Ignored/ | | (Ignored/ | | Groups) | | Groups) | | Disabled) | | Disabled) | | Disabled) | +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ I only care about S and B child domains. I am not sure how I can tell SSSD/IPA to ignore the other H, R, and V domains and only look up uses in S or B. The issues that I am seeing are: 1. Running ID on a user in S or B takes ~ 1m+ to return results. I believe its returning a LOT of groups too which might be a problem. I tried making SSSD changes regarding ignore_group_members and it seems to speed things up a bit, but then getent group does not work. 2. AD Users cannot authenticate, getting System Error 4. I suspect its latency or a configuration issues. So I guess my questions are these: 1. Is it possible to establish a trust directly with S and B without trusting the parent (W)? It seems to fail saying I need to trust a forest. 2. Is it possible to "disable" the other domains to maybe speed things up? 3. Anything in krb5 or sssd that I need to add/configure to help with performance? Thanks all!

1 0

WebUI login broken realm-wide ("Login failed due to an unknown reason") — anonymous PKINIT kinit -n fails with Generic error / UNKNOWN_REASON, root cause not found
by adam panayis 10 Sep '26

10 Sep '26

Hi all, We've been chasing a WebUI login failure for several days and have exhausted our own diagnostic options. Posting the full picture in case anyone recognizes this or can point us at something we've missed. Environment: - 3-server multi-master topology (2x RHEL8/Oracle Linux 8 replicas on ipa-server-4.9.13-21.0.1.module+el8.10.0, 1x older replica on ipa-server-4.6.8-5.el7_9.12, since removed from topology — see below) - Realm: FX.LAN Symptom: WebUI login fails on all replicas with "Login failed due to an unknown reason." Root cause traces to ipaserver/rpcserver.py's attempt_kinit/kinit_armor calling kinit -n (anonymous PKINIT armor) as a subprocess, which fails: kinit: Generic error (see e-text) while getting initial credentials krb5kdc.log shows: AS_REQ ... UNKNOWN_REASON: WELLKNOWN/ANONYMOUS(a)FX.LAN for krbtgt/FX.LAN(a)FX.LAN, Generic error (see e-text) Packet capture confirms the KDC rejects the anonymous AS-REQ on the very first round trip, before any PKINIT certificate exchange begins. Real password-based kinit, SSH, and the ipa CLI all work perfectly, on every server, throughout. Only this specific anonymous-armor step (used by both the WebUI's password login form and its Kerberos/SPNEGO SSO login path — we tested both) is affected. What we've ruled out, with evidence: - PKINIT certs/EKUs/subject — a real but unrelated cert-subject bug was found and fixed along the way; confirmed unrelated via the packet capture above. - LDAP data/replication — WELLKNOWN/ANONYMOUS entry unmodified since 2017; every LDAP search for it during actual failures returns err=0 success (confirmed via 389-DS access logs correlated to the exact failure timestamps). - ipa-kdb key-stripping (the class of bug in Pagure #9065) — kadmin.local getprinc WELLKNOWN/ANONYMOUS confirms 2 valid keys present, identical on all servers. - Local 389-DS index corruption (-30993) on one server — real, but confirmed unrelated (wrong day, and other clean-database servers still fail identically). - Topology consistency — ipa topologysuffix-verify domain/ca both clean. - A replica (idmserver-ha) had been left mid-removal (DNS SRV records stripped, server-del never completed) around the time this started — we completed the removal cleanly, no change to the symptom. This rules out what had been our leading hypothesis. - SPAKE preauth config — production kdc.conf correctly configured. One static-analysis lead, unconfirmed: in MIT krb5's do_as_req.c, UNKNOWN_REASON is a generic fallback (if (errcode != 0 && state->status == NULL) state->status = "UNKNOWN_REASON";). The anonymous-request handling block contains one status-less error path: errcode = krb5_copy_principal(context, krb5_anonymous_principal(), &state->request->client); if (errcode) goto errout; This matches the anonymous-only symptom, but it's a pure in-memory copy of a compile-time constant with no external dependency — we can't explain why it would suddenly start failing, and we haven't been able to confirm live whether this is even the actual branch being hit. Where we're stuck: we can't get a live gdb trace to confirm/deny the above — our installed krb5-server-1.18.2-34.0.1.el8_10 has an Oracle-specific patch revision (.0.1) with no matching debuginfo available anywhere we could find (checked Oracle's own debuginfo repo and cross-referenced AlmaLinux, which ships a different build 1.18.2-34.el8_10 without that suffix — not a build-id match). Has anyone seen this exact signature before, or have suggestions for getting further without matching debug symbols? Happy to provide more logs/detail on request. Thanks,

1 0

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

10 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.

5 4

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 5

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

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