Woes with FreeIPA and SIDs

As cool as FreeIPA is – I'm using it for over 10 years at home – sometimes I fell it breaks just by being looked at.

TLDR: If you have accounts or groups with UID or GID not falling in any defined range ID ranges, fix that by any of: 1) changing the UID/GID; 2) extending defined ID range; 3) creating a new ID range covering those UIDs/GIDs.

Then generate new SIDs with ipa config-mod --enable-sid --add-sids.

Few months ago my FreeIPA installation stopped allowing users to login. It was mostly a nuisance for me, nothing critical:

• on most important computers I have local accounts

• services authenticating with plain LDAP continued to work

• so what didn't work? Login into FreeIPA's web interface. But admin accounted worked, so…

When I eventually started to debug, I found following logs in krb5kdc.log:

krb5kdc[3123](info): AS_REQ : handle_authdata (2)
krb5kdc[3123](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26),
camellia128-cts-cmac(25)}) 192.168.x.x: HANDLE_AUTHDATA: zdzichu@PIPEBREAKER.PL for krbtgt/PIPEBREAKER.PL@PIPEBREAKER.PL, No such file or directory

Some searching the web later, I've concluded No such file or directory refers to SID, a Security Identifier. SIDs are some Microsoft's Active Directory properties. I see no reason to have them on Linux-only FreeIPA installs.

The Upgrade section in the documentation is wrong:

The upgrade does not turn on the feature. If the admin wants to enable SID generation, he needs to update the packages and run the new command

It's not true, admin desires don't matter. As Alexander Bokovoy wrote on the mailing list:

FreeIPA generates SIDs by default since FreeIPA 4.9.8. It is configured to do so on new installations even when integration with AD is not considered, due to tightened requirements to process constrained delegation in Kerberos.

So SIDs are really required in FreeIPA now. I don't want them, but whatever. There is a command which is supposed to generate missing data:

ipa config-mod --enable-sid --add-sids

It finished without errors, but login still didn't work.

More searching. The commands fires up a job (in LDAP server?) so let look into dirsvr's errors.log:

[12/Jan/2024:14:07:51.524937136 +0100] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ...
[12/Jan/2024:14:07:51.566941696 +0100] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [135] into an unused SID.
[12/Jan/2024:14:07:51.585948214 +0100] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry.
[12/Jan/2024:14:07:51.597088076 +0100] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32].

OK, we're getting somewhere. I had some an obsolete group defined with GID 135. Let's remove it and re-run the command.

[12/Jan/2024:14:24:29.879953617 +0100] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 521]: Cannot convert Posix ID [1037] into an unused SID

I know this UID, this is one of the users I've migrated to FreeIPA. Obviously I cannot remove it.

Turns out, FreeIPA has something called ID ranges. If you have accounts or groups with UID or GID not falling in any defined range, sidgen script just fails.

I had to go to IPA Server -> ID Ranges -> Add in web console and make changes. I did not want to mess with already defined ranges, so I created a new one. An “unix” range. Base 1000, size 1000, had to guess some numbers for RID ranges before it was accepted.

Not that I'm so smart to figure it out. There's Knowledgebase solution 394763 for exactly this problem.

And just like that, kerberized login to FreeIPA started working again.

Knowing what was wrong, I've started noticing (and understanding) other people have the same kind of issues.

One problem down, two to go. Replication between my replicas is not working. Again with unhelpful message:

[12/Jan/2024:14:33:32.812986996 +0100] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=kaitain.pipebreaker.pl-to-okda.pipebreaker.pl" (okda:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.

I did all the steps from KB 2988311 but it didn't help.

Second problem, ACME on FreeIPA ceased to work for me.

I hadn't had willpower to debug these two, yet.