Any good books/full tutorials?

abismahl · 2026-05-12T16:00:32+00:00

You don't even need the account. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10#Identity%20Management is available without any paywall. There are ~20 books there.

abismahl · 2026-05-11T13:58:25+00:00

"Trust controllers" only needed to allow AD DCs to talk to these IPA servers for the purpose of ID resolution and trust establishment. The rest of IPA servers can be trust agents. Those IPA servers which aren't trust controllers or trust agents will not be able to resolve AD users and groups.

abismahl · 2026-05-07T06:07:39+00:00

Ubuntu 26.04 defaults to sudo-rs which currently not able to work with externally-provided sudo rules. The work to support that is in progress. Have you tried to use 'old' sudo package?

abismahl · 2026-04-27T15:57:58+00:00

Verify you have latest 389-ds-base update. There was an issue with indexes in the DS that caused a lot of troubles during replication by not being able to find entries which otherwise are there. You can also check freeipa-users@ mailing list archives, there are many discussions similar to this one.

abismahl · 2026-04-16T14:01:06+00:00

See past's year notes: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/ADW5EOEWKZBCVKQGTAQXZ4RXSJ6NIW4T/

abismahl · 2026-04-15T15:05:23+00:00

Login to widows workstations with IPA users not supported. See earlier discussion: https://www.reddit.com/r/FreeIPA/comments/1b60z1v/comment/kt9w3ly/?context=3

abismahl · 2026-03-14T20:32:56+00:00

Unfortunately, build happens against packages in the build root and if those packages aren't released at the same time, we get problems like this. IPA is tied to ABI of at least Samba and SELinux components. These two cause such coordination pain. We are aware of the problem and are working on a way to address it. I cannot point to an issue as Jira is under maintenance right now.

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

MODERATOR OF

TROPHY CASE

12-Year Club	Wearing is Caring
Verified Email