Problem description

Currently, IPA allows the creation of users and groups in a flexible way, not validating if the user will actually end up in the ipa-local ID range. We also don’t have a mechanism to set RID bases to existing ID ranges, if they are not a default one (or if there is more than one ipa-local ID range).

Since IPA now enforces PAC verification for authentication, users have to have SIDs before they can authenticate, so all the users outside of ipa-local ID range, or inside ipa-local range with no RID bases set, will not be able to get new kerberos tickets. Additionally, as it is now, the SIDgen task fails on the first failed ID, which means that users in valid ranges can still not get the SIDs if the task fails before getting to them.

Request for enhancement

As an admin, since after upgrading to IPA 4.10.2-5+ we can face a situation where no users can login, I need a tool to quickly detect and remediate any possible ID range issues before running a SIDgen task, to be sure the task succeeds and all the users get SIDs, and the authentication becomes operational again.

Acceptance criteria:

Since it’s possible that at the moment of running of the tool admin user(s) don’t have SIDs and are not able to authenticate, the tool should be run at IPA server as root, and not require kerberos ticket;

The tool should be able to detect:

• ID ranges with no RID bases;
• ID ranges overlaps;
• Users (including preserved) and groups outside of ipa-local ID ranges;
• Users (including preserved) and groups with IDs under 1000 (in order to avoid overlapping with local system and service users and groups);

After the detection, the tool should be able to propose:

• New RID bases for ranges that miss one or both bases, meeting requirements:
  • New RID ‘ranges’ don’t overlap with existing ones;
  • User can offset the new RID ranges from existing ones by a tunable number of IDs, in order to preserve the possibility of expanding existing ranges;
• New ID ranges for users and groups out of ipa-local ID ranges, meeting requirements:
  • New ID ranges don’t overlap with existing and proposed ones, and their proposed RID ranges meet the new RID ranges requirements;
  • User can tune the proposed ranges parameters, including:
    • How big of a gap between existing IDs is considered as a start of another range;
    • How small ID range can be, i.e. minimal amount of IDs in a range;
    • Allow proposed range rounding up to the power of 10 the size of the range to outer margins (purely aesthetic requirement);
    • Allow treating users with IDs under 1000 as usual ones, and propose ranges for them too;
  • If some existing IDs are not meeting the criteria for a range to be proposed for them, they all should be explicitly listed with a reason why.

After the changes are proposed and accepted, the tool should be able to apply the changes (including unattended mode for testing purposes);

The tool should create a dedicated log file to track the analysis and changes it performed.