On Tue, 16 May 2023, Andreas Binapfl via FreeIPA-users wrote: This one is a bit weird. Can you please show ipa idrange-show --all --raw DOMAIN.LOCAL_new_range ? The error message is quite clear -- there is some range that overlaps in its parameters with existing range. It comes from this code in the range check plugin: /* For ipa-local or ipa-ad-trust range types primary RID ranges should * not overlap */ if (strcasecmp(r1->id_range_type, AD_TRUST_RANGE_TYPE) == 0 || strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0) { /* Check if primary rid range overlaps with existing primary rid range */ if ((r1->base_rid_set && r2->base_rid_set) && intervals_overlap(r1->base_rid, r2->base_rid, r1->id_range_size, r2->id_range_size)) return RANGE_CHECK_PRIMARY_PRIMARY_RID_OVERLAP; } -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

On Wed, 17 May 2023, Andreas Binapfl via FreeIPA-users wrote: Ok, it does not have RIDs at all, so it cannot be used to assign SIDs to the objects with POSIX IDs in the range 1600..3600. It is, however, is treated by the range check plugin as having a RID range 0...2000 which overlaps with the primary (DOMAIN.LOCAL_id_range) range because it has starting base RID at 1000. A solution would be to modify this range to put a base range somewhere outside the main one: ipa idrange-mod DOMAIN.LOCAL_new_range --rid-base=500000 --secondary-rid-base=503000 You probably need to play with parameters to the bases so that they don't overlap with the other ranges. This is how that is detected: /** * connected ranges must not overlap: * existing range: base rid sec_rid * | | \ / | * | | \/ | * | | /\ | * | | / \ | * new range: base rid sec_rid **/ #define IN_RANGE(x,base,size) ( (x) >= (base) && ((x) - (base) < (size)) ) static bool intervals_overlap(uint32_t x, uint32_t base, uint32_t x_size, uint32_t base_size) { if (IN_RANGE(x, base, base_size) || IN_RANGE((x + x_size - 1), base, base_size) || IN_RANGE(base, x, x_size) || IN_RANGE((base + base_size - 1), x, x_size)) { return true; } return false; } -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

On Wed, 17 May 2023, Andreas Binapfl via FreeIPA-users wrote: You can change 'ipabaserid' and 'ipasecondarybaserid' via ldapmodify. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

On Mon, 22 May 2023, Andreas Binapfl via FreeIPA-users wrote: You can modify first POSIX ID via ldapmodify. IPA tools prevent you doing so because it might affect ID mapping configuration on multiple systems. Alternatively, you can add another range to cover those IDs. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

On Mon, 22 May 2023, Andreas Binapfl via FreeIPA-users wrote: Something like that. You will get diagnostic from IPA CLI when you'd be adding a range in case your parameters make this range overlapping with the existing ones. I would not recommend using POSIX IDs below 1000 in that range, though. Are you really needed to cover POSIX IDs like that at Kerberos level? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

Think i found a way to change it. For documentation purpose if someone else has this problem: In /etc/ipa/default.conf i found our ldap_uri Then issued this commands: #verify correct dn ldapsearch -b 'cn=DOMAIN.LOCAL_new_range,cn=ranges,cn=etc,dc=domain,dc=local' ldapmodify -H ldapi://%2Frun%2Fslapd-DOMAIN-LOCAL.socket dn: cn=DOMAIN.LOCAL_new_range,cn=ranges,cn=etc,dc=domain,dc=local changetype: modify add: ipabaserid ipabaserid:500000 commit with enter on an empty line. Did the same for add: ipasecondarybaserid ipasecondarybaserid:503000 Now "ipa config-mod --enable-sid --add-sids" did run successful. Let's hope the auth problems are fixed too =) Thanks for your time and help!