Hello dear FreeIPA experts,
I am currently in the process of trying to migrate a system consisting of two ipa masters ipa1,ipa2 (no ca, no dns, no pkinit) running on CentOS7 to two new systems running on Alma Linux 9 (RHEL 9 based).
At least some of the user-IDs and GIDs in the system are very old, however, since before IPA there was an openldap based system and the user config data traveled over when the switch to IPA was initially made.
I managed to setup new system ipa3, did a test ipa server install with some (solvable) problems, looks OK. But I needed a replica of course, so rollback and try ipa-replica-install instead of server-install.
This eventually worked somewhat. During the replication/setup process I got told I have user accounts without SID and if I want to convert them/add the SIDs. I went with the default option of "no" since I didn't really know if I needed that and was not sure it wouldn't damage the function of the old master servers.
The result was: kinit and login to web interface only worked for the admin user. WIth ipa-user find or in the web interface it seemed that other than that the data has traveled over. Modifications we hat in the 99user.ldif also traveled over.
Of course, the problem with kinit and web login is due to the missing SIDs.
I found out you can redo the conversion I skipped during the replica install by using "ipa config-mod –enable-sid –add-sids"
However, this didn't change anything, and from looking at the dirsrv error log I learned the script did not work because some of my uid/gid is outside the idrange configured for IPA.
At this point I decided to do a rollback to do more research on how to handle those issues, so I'm back to two masters on CentOS7.
My existing IPA installation only has this one idrange:
[root@charon ~]# LANG=C ipa idrange-find --------------- 1 range matched --------------- Range name: NET.IDA_id_range First Posix ID of the range: 531600000 Number of IDs in the range: 200000 Range type: local domain range ---------------------------- Number of entries returned 1 ----------------------------
Note there is no primary or secondary RID base set for this range.
I do have users with UID starting at 999 and GID starting at 100 that were probably created before IPA.
Now I understand I have to do something like
"ipa idrange-add NET.IDA_low_id_range --base-id=1 --range-size=20000 --rid-base=200000000 --secondary-rid-base=300000000"
and then maybe the ipa config-mod with "--add-sids" should work.
But I do have questions before I try that:
First: Since my existing range has no RID set, how do I know the rid base ranges won't conflict?
And then: On which point and where during the replicate-to-new-system process do I have to do what?
- I guess I could even add the idranges on the old servers before creating a replica? Would it work? Is it a good idea?
- what about the "ipa config-mod –enable-sid –add-sid" : - is this available on the old CentOS 7 too and should I try to enable it there before creating a replica? - or is it only possible/necessary on the new replica, but then, what will be the state of my ipa master server cluster then? Most importantly, will the old ipa servers continue to work while I test the new replica with single clients, create a second new replica etc pp?
In short: At what point and where do I need to run the "ipa addrange", and at what point and where do I need to run the "ipa config mod –enable-sid –add-sid".
Many thanks for any help.
Kind regards,
Thomas
Hi,
On Wed, Jul 31, 2024 at 12:20 PM Thomas Boroske via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello dear FreeIPA experts,
I am currently in the process of trying to migrate a system consisting of two ipa masters ipa1,ipa2 (no ca, no dns, no pkinit) running on CentOS7 to two new systems running on Alma Linux 9 (RHEL 9 based).
At least some of the user-IDs and GIDs in the system are very old, however, since before IPA there was an openldap based system and the user config data traveled over when the switch to IPA was initially made.
I managed to setup new system ipa3, did a test ipa server install with some (solvable) problems, looks OK. But I needed a replica of course, so rollback and try ipa-replica-install instead of server-install.
This eventually worked somewhat. During the replication/setup process I got told I have user accounts without SID and if I want to convert them/add the SIDs. I went with the default option of "no" since I didn't really know if I needed that and was not sure it wouldn't damage the function of the old master servers.
The result was: kinit and login to web interface only worked for the admin user. WIth ipa-user find or in the web interface it seemed that other than that the data has traveled over. Modifications we hat in the 99user.ldif also traveled over.
Of course, the problem with kinit and web login is due to the missing SIDs.
I found out you can redo the conversion I skipped during the replica install by using "ipa config-mod –enable-sid –add-sids"
However, this didn't change anything, and from looking at the dirsrv error log I learned the script did not work because some of my uid/gid is outside the idrange configured for IPA.
At this point I decided to do a rollback to do more research on how to handle those issues, so I'm back to two masters on CentOS7.
My existing IPA installation only has this one idrange:
[root@charon ~]# LANG=C ipa idrange-find
1 range matched
Range name: NET.IDA_id_range First Posix ID of the range: 531600000 Number of IDs in the range: 200000 Range type: local domain range
Number of entries returned 1
Note there is no primary or secondary RID base set for this range.
I do have users with UID starting at 999 and GID starting at 100 that were probably created before IPA.
Now I understand I have to do something like
"ipa idrange-add NET.IDA_low_id_range --base-id=1 --range-size=20000 --rid-base=200000000 --secondary-rid-base=300000000"
and then maybe the ipa config-mod with "--add-sids" should work.
But I do have questions before I try that:
First: Since my existing range has no RID set, how do I know the rid base ranges won't conflict?
The user and group entries have a POSIX id, from which a mapping algorithm derives a RID in order to create ipaNTSecurityIdentifier (or SID) with the format $DOMAINSID-RID. For instance,
- my local domain has a SID S-1-5-21-1166032515-3431855665-2561613534, visible with # ipa trustconfig-show Domain: ipa.test Security Identifier: S-1-5-21-1166032515-3431855665-2561613534 NetBIOS name: IPA Domain GUID: 8358294d-1b2a-4b83-af23-7529b29b8fdd Fallback primary group: Default SMB Group IPA AD trust agents: server.ipa.test IPA AD trust controllers: server.ipa.test
- my user testuser123 has a posix id 205400113 # ipa user-show testuser123 User login: testuser123 First name: test Last name: user123 Home directory: /home/testuser123 Login shell: /bin/sh Principal name: testuser123@IPA.TEST Principal alias: testuser123@IPA.TEST Email address: testuser123@ipa.test UID: 205400113 GID: 205400113 Account disabled: False Password: False Member of groups: ipausers Kerberos keys available: False
- my range for this posix id is: Range name: IPA.TEST_id_range First Posix ID of the range: *205400000* 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
This means that a posix id *205400000* is translated into RID *1000* 205400001 -> 1001 205400002 -> 1002 ... 205400113 -> 1113 ... 205600000 -> 201000
The RIDs can have values between 1000 and 200999. Same gymnastics for secondary RIDS: 100'000'000 to 100'199'999.
The SID for my user has the format $DOMAINSID-$RID: S-1-5-21-1166032515-3431855665-2561613534-1113
The RID must be unique, but if you only have one range you can pick any base value as long as the primary and secondary RIDs don't overlap. In my case the RIDS can be inside 1000-200999 and 100'000'000-100'199'999.
If you want all the details, you can read https://pagure.io/freeipa/blob/master/f/doc/designs/id-mapping.md
And then: On which point and where during the replicate-to-new-system process do I have to do what?
- I guess I could even add the idranges on the old servers before
creating a replica? Would it work? Is it a good idea?
The ID range object is replicated. If you create it on the master, the same object is available on the replica.
- what about the "ipa config-mod –enable-sid –add-sid" :
- is this available on the old CentOS 7 too and should I try to enable
it there before creating a replica?
- or is it only possible/necessary on the new replica, but then, what
will be the state of my ipa master server cluster then? Most importantly, will the old ipa servers continue to work while I test the new replica with single clients, create a second new replica etc pp?
The operation adds SIDs to the user entries which are replicated, so the old CentOS 7 master will also see the SIDs.
In short: At what point and where do I need to run the "ipa addrange", and at what point and where do I need to run the "ipa config mod –enable-sid –add-sid".
Please refer to https://access.redhat.com/solutions/7014959
flo
Many thanks for any help.
Kind regards,
Thomas
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi flo,
thanks for your help!
I do understand the reason for rid and second rid and read up on the calculation. However, my currently running system has no rid base and secondary rid base defined, probably because trust was never set up:
-bash-4.2$ LANG=C ipa trustconfig-show ipa: ERROR: : trust configuration not found
The reason I am asking about making sure to not overlap the ranges is that I already know I have to manually add a second posix range to make the "--add-sids" function work on the new replica.
But by now I have come to assume I could try running "--enable-sid" (without --add-sid) on the replica (if it's not done during the replica install anyway) and see if it automatically creates the rid ranges for the single existing local domain (I did not check if that was the case before rolling back the vm running the replica. But I guess it should, it could not work otherwise).
Then I could manually create a second range to cover my old uids with rid bases not overlapping the other one's rid bases..
There is also an "ipa idrange-mod" command, however, documentation seems to suggest it cannot be used on "local domain" type ranges.
My problem is similar to this one:
https://enotty.pipebreaker.pl/posts/2024/01/woes-with-freeipa-and-sids/
Except for me it shows up when trying to make a replica on a newer system (as part of a migration process) so I have to consider how config changes will coexist with the old system too.
The ID range object is replicated. If you create it on the master, the same object is available on the replica.
OK, that makes sense.
But note that the two old master systems are running without "--enable-sid" so far. Will login/kinit on/these still continue to work (without pac), and login on the new replica will be with pac?
Don't get me wrong, I have no intention of keeping the old systems running once I have two stable and working new replicas, but I will need several days for testing before I switch over.
Please refer to https://access.redhat.com/solutions/7014959
I could actually access that article after "Activating subsciptions" in my free redhat account, nice!
The article has good background info on why the changes are needed.
Also points to https://access.redhat.com/solutions/394763 regarding my "old uid outside existing range" problem.
I will be away from office for a while, but my plan for when I return now is
1. redo the replica-install 2. see if the existing id range now has rid and secondary rid (It should I guess) 3. as per the last article, use ipa idrange-add to create a second range covering the old uid and gid 4. run the config mod with --add-sid again, checking the error log
Login on the replica should then work.
Then, check if anything exploded on the old servers :-)
Kind regards,
Thomas
freeipa-users@lists.fedorahosted.org
-
Florence Blanc-Renaud -
Thomas Boroske