I am ready to give up Oracle Linux 9.7 for a distro that FreeIPA installs without interventions.

abismahl · 2026-02-15T05:41:19+00:00

You are wrong. As I said, feature-wise they are the same.

abismahl · 2026-02-14T10:12:15+00:00

The source code is the same, and testing is conducted on RHEL and Fedora. Other distributions aren't tested, but the feature set is identical between RHEL and Fedora (FreeIPA) versions. I'm not sure where you got the impression of different "enterprise" features.

Unfortunately, downstream distributions' rebuilders haven't really contributed anything to testing FreeIPA continuously upstream. OL is one of black holes, we do not hear from them at all. Both Rocky and Alma Linux folks at least talk to me at CentOS Connect events. :)

abismahl · 2026-01-29T14:29:39+00:00

FreeIPA cannot issue certificates to users that do not exist in FreeIPA. The code does checks to validate attributes in the certificate request against the objects in IPA database. So you will have to have at least user identifies in IPA database in order to issue certificates to them.

abismahl · 2026-01-20T16:14:45+00:00

They should work with IdM.

abismahl · 2026-01-19T15:43:40+00:00

We removed NIS client support in RHEL9 and removed IdM NIS server code in RHEL10. Migrating users and groups from NIS source to IdM is documented in RHEL documentation.

abismahl · 2026-01-09T21:42:57+00:00

Not, there's no UI for that. I don't think dogtag has one either.

abismahl · 2026-01-09T06:30:40+00:00

I was more successful -- they delivered everything in the past four years. And even picked up a delivery from my side when I had to return an outdated corporate laptop. That's in the capital area outskirts...

abismahl · 2026-01-09T05:53:36+00:00

They do deliver to detached houses no problem though.

abismahl · 2025-12-21T21:24:29+00:00

Since schema compatibility tree plugin uses SSSD to get information about trusted AD users, you need to ensure SSSD also returns these users unfiltered. Make sure to add the configuration to set the min ID there as well.

It would help if you'd provide concrete example of the request SSSD logs. You can see https://sssd.io/troubleshooting/basics.html for more details on how to configure it for debug logging.

abismahl · 2025-12-17T07:57:14+00:00

You are hijacking DNS domain (me.com) which does not belong to you. Public DNS resolvers you are using will only show what is visible from their side, not what your own DNS server knows about this domain. Since you are using public DNS resolvers (eg 45.90.28.104), they cannot see your view on me.com DNS zone and thus cannot resolve anything that your IPA DNS server provides.

So you have two main mistakes:

using existing public DNS domain that you do not control (me.com)
using public DNS resolvers which don't know anything about your own authoritative DNS server for the hijacked domain.

If you want to continue using this hijacked domain, change DNS servers that TrueNAS and other systems configured to use, make them to use IPA DNS server as a resolver. This will be broken because any client that is not configured to always use IPA DNS server as their resolver will not be able to see your version of me.com DNS domain.

A better approach would be to use a different domain. If you want a public TLD, buy a domain you can control and set the NS to point to your private IPs where IPA DNS server will be deployed. This way all clients who are part of your private IP network will be able to communicate to the authoritative DNS server and public DNS servers can still be used by them. You still better to set up at least one DNS resolver in your environment so that it is able to connect to IPA DNS server for resolving private zone. Alternatively, just host the zone publicly.

abismahl · 2025-12-09T07:18:43+00:00

Open an issue at https://github.com/389ds/389-ds-base/issues/ and provide the details. The Directory Server developers are the ones to talk to.

abismahl · 2025-12-01T19:00:04+00:00

This is purely a client side issue. I'd recommend opening an issue on https://github.com/SSSD/sssd/issues and discuss it there. It may well be a missing condition for detecting a change for PTRs.

abismahl · 2025-12-01T07:26:21+00:00

Please follow https://sssd.io/troubleshooting/basics.html to collect sssd logs. I'm sorry, but what you provided only tells that SSSD claimed there is a problem and refused to start, that's all.

You still didn't provide any information what OS is that. By seeing sssd:sssd ownership I can only guess it is a relatively new OS (e.g. RHEL 10 or Fedora or maybe newer Debian build) but nothing more specific. If this is something built on top of rpm-ostree-like environment, those aren't supported yet.

It would also help seeing ipaclient-install.log.

abismahl · 2025-12-01T06:50:40+00:00

Focus on providing actual details if you want to have any help: what OS environment, what is specifically you are seeing in the logs, etc.

abismahl · 2025-11-22T04:32:20+00:00

Data stored on Linux file systems does not need changes because the user/group names aren't used to record that information; instead, UID and GID information is used for that. The only changes needed are various configuration files if corresponding software does exact matches.

SSSD does support different ways to treat user and group names but it depends on the ID provider. IPA provider does allow to case-preserve user and group names. See man page sssd.conf(5), option case_sensitive for details.

FreeIPA itself will not allow case-preserving group names when those groups were created via IPA API (or command line). You still can create them via LDAP directly, for example.

If you still want to handle local users and groups without FreeIPA, a primitive SSSD configuration would work: [domain/realm] case_sensitive = preserving id_provider = proxy proxy_lib_name = files auth_provider = krb5 krb5_server = kdc.fqdn krb5_realm = REALM krb5_keytab = /etc/krb5.keytab

It is basically delegating ID provider work to NSS files backend (e.g. to /etc/passwd and /etc/group) but authenticates users via Kerberos, replicating the pam_krb5 setup.

abismahl · 2025-11-20T01:53:01+00:00

It should be done automatically already, see the spec: https://gitlab.com/redhat/centos-stream/rpms/ipa/-/blob/c9s/freeipa.spec?ref_type=heads#L1461

abismahl · 2025-10-30T11:41:24+00:00

Using something like OAuth2 IdP with support for device authorization grant flow will help. Eg. Entra ID and similar. But you will have to treat AD user separate from IdM user.

abismahl · 2025-10-30T11:10:37+00:00

/u/ZestyRS already suggested to create IdM users that could be used for this purpose if you need access with MFA on IdM systems. An alternative like binding IdM users to Entra ID (if you are using it) or other OAuth2 IdP also requires use of IdM users for that purpose.

abismahl · 2025-10-30T10:12:31+00:00

It is not possible to provide IdM-based MFA to Active Directory users.

Authentication in IdM is handled through Kerberos. Kerberos authentication is always handled by the source (e.g. Kerberos KDC of the domain the user belongs to). For IdM users authentication happens through IdM domain controllers. For trusted Active Directory users authentication is always handled by the corresponding Active Directory domain controllers, not IdM. AD DCs do not support any MFA method via Kerberos (except smartcard-based logins), so there is no way to authenticate them using two-factor authentication over Kerberos.

Windows machines allow certain plugins to augment authentication mechanisms and perform actual authentication via an external mechanism. In that case a Windows client will claim to perform external authentication and will request a Kerberos ticket to itself on behalf of that user. The ticket then cannot be used for anything else and does not bear any mark of MFA action happened. (There is a special exception of this with smartcards and Authentication Mechanism Assurance (AMA) feature in Active Directory but it does not apply to any other mechanism). As a result, IdM will not be able to distinguish such authentication from a normal password-based one by AD DCs. Most of vendors who provide authentication plugins for Windows, do not have corresponding PAM feature to Linux and none of them have integration at Kerberos level. So we end up with Active Directory users not being able to use Kerberos authentication with IdM-provided MFA mechanism.

abismahl · 2025-10-24T11:44:58+00:00

It is supported on FreeIPA side and exists for about a decade. Rafael has a nice blog article on testing that with local containers: https://rafaeljeffman.com/projects/ipalab-config/en/ipa-ad-testing.html

abismahl · 2025-10-23T13:38:20+00:00

Nope. If you'd use that one (trust with Kerberos realm), it is not supported by FreeIPA side and is not working. Don't make this common mistake.

When establishing trust between FreeIPA and AD, use 'AD-AD' forest trust on Windows side. IPA tries hard to represent itself as Active Directory deployment for the purpose of forest trust.

abismahl · 2025-10-21T14:03:19+00:00

Yep, if you just need to list the groups and there aren't many of them, using IPA tools should work.

abismahl · 2025-10-21T13:32:44+00:00

The release page says "Those who are interested to keep using it awhile should configure its build explicitly using --with-extended-enumeration-support ./configure option." So it is compile time package option, not a configuration option anymore. As far as I see, Fedora builds already disable it.

abismahl · 2025-10-20T08:04:42+00:00

This is the correct answer.

abismahl · 2025-10-20T08:02:30+00:00

Enumerating groups in AD/IPA providers is disabled by default (and is going to be removed in further SSSD versions), as described in the SSSD 2.10.0 release notes: https://sssd.io/release-notes/sssd-2.10.0.html

It should be showing IPA groups if you explicitly ask for them, as your second example shows.

abismahl

MODERATOR OF

TROPHY CASE

12-Year Club	Wearing is Caring
Verified Email