You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: