Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: detect ID range / DNA range mismatches #187

Open
rcritten opened this issue Feb 22, 2021 · 0 comments
Open

RFE: detect ID range / DNA range mismatches #187

rcritten opened this issue Feb 22, 2021 · 0 comments

Comments

@rcritten
Copy link
Collaborator

cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1745138

When FreeIPA replica is installed a DNA range is not allocated to it.
The range is only cut from the master's DNA range when a replica really needs to get the IDs allocated e.g. when a user or a group is being created.

When this new DNA range appears on replica side, we ideally need to allocate ID range with the same parameters to be able to issue SIDs for the objects which received IDs from DNA plugin. But that is not happening, so admins need to allocate ID ranges manually.

When such situation arises, it is good to see what DNA ranges aren't mapped to ID ranges yet and which objects are there in additional ID ranges already.

https://gist.github.com/abbra/33f5ac59c5cae750ecdb3974978d9cec

Per later discussion:

The user has no idea it should also create ID range.

'ipa-replica-manage dnarange-set | dnanextrange-set' commands tell nothing about 'ipa idrange-add' at all, neither they call 'ipa idrange-add' equivalent.

According to DS documentation, having on-deck range (dnanextrange) set is a normal operation.

This whole bug came out of a real customer case where replicas were deployed and somehow DNA ranges weren't carved out of the primary master's range. I think this happened because the users were migrated from external LDAP, their UID/GID values were set to the original ones and then DNA ranges were modified to follow them. However, we do not allow to modify local ID range once it was created.

For example, they had three replicas:

ipa-replica-manage dnarange-show

idm034.ipa.example.com: 959150570-959199999
idm0392.ipa.example.com: 959100544-959150499
idm033.ipa.example.com: 959076070-959100499

ipa-replica-manage dnanextrange-show

idm034.ipa.example.com: 959050564-959075999
idm0392.ipa.example.com: No on-deck range set
idm033.ipa.example.com: No on-deck range set

while the primary ID range was
Range name: IPA.EXAMPLE.COM_id_range
First Posix ID of the range: 1198600000
Number of IDs in the range: 200000
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100000000
Range type: local domain range

and no additional ranges corresponding to DNA ranges there caused sidgen plugin to fail:

[21/Aug/2019:15:19:48.444222170 +0200] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [959150569] into an unused SID.

So

What healthcheck will do is ensure that there is a DNA range within all IPA ranges and the reverse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant