With the following existing idrange
# ipa idrange-show AD18.IPA18.DEVEL_id_range Range name: AD18.IPA18.DEVEL_id_range First Posix ID of the range: 1670800000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-3090815309-2627318493-3395719201 Range type: Active Directory domain range
I can add the following two idranges
# ipa idrange-add test-range --base-id=123456 --rid-base=0 --range-size=10 --dom-sid=S-1-5-21-3090815309-2627318493-3395719201 --------------------------- Added ID range "test-range" --------------------------- Range name: test-range First Posix ID of the range: 123456 Number of IDs in the range: 10 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-3090815309-2627318493-3395719201 Range type: Active Directory domain range
and
# ipa idrange-add test-range2 --base-id=223456 --rid-base=1 --range-size=10 --dom-sid=S-1-5-21-3090815309-2627318493-3395719201 --type=ipa-ad-trust-posix ---------------------------- Added ID range "test-range2" ---------------------------- Range name: test-range2 First Posix ID of the range: 223456 Number of IDs in the range: 10 First RID of the corresponding RID range: 1 Domain SID of the trusted domain: S-1-5-21-3090815309-2627318493-3395719201 Range type: Active Directory trust range with POSIX attributes
Both should not be possible. In the first case the RID-ranges overlap, since the first RID in the existing idrange is 0 and the size is 200000 the first available RID range can start at 200000.
In the second case (besides the RID issue) an idrange with a different type was added.
Both collisions should be detected and the creation of the new idrange rejected preferable by the DS plugin which detects the other idrange collisions.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1058780
I had a discussion with Alexander, this fix seems too complicated to be added to 3.3.5 stabilization release. So to not break it, I would propose to move it to 3.4 or later.
In 3.3.x versions, user need to be careful about overlaps themselves.
Tomas pointed out that the checks are done by ipa-range-check SLAPI plugin. It might be that instead of fixing Python code we actually need to look into a bug in ipa-range-check plugin code.
Sumit will take the review of this one, eventually.
master:
Regressions found by our CI fixed:
ID Range test extended to cover new functionality:
Additional fix in master, ipa-4-0, ipa-4-1:
Metadata Update from @sbose: - Issue assigned to tbabej - Issue set to the milestone: FreeIPA 4.0 - 2014/03
Login to comment on this ticket.