----- Original Message ----- > > > > We can also generate the SID algorithmically from the > > > > uidNumber/gidNumber > > > > > > Do you mean the SID of the trusted domain user? > > > > No I meant the SID of users and groups. > > ok, I would very much favor this approach it will make things much > easier. But iirc the idea was rejected some time ago, because we > couldn't agree on a good algorithm which can remove the conflicts > when > uid and gid are the same. What would you suggest? Adding the highest > bit > for groups? uid*2 for users, (gid*2)+1 for groups? ... ?
Good question. So we need to decide whether we want algorithmic mapping or not (or a hybrid). Advantages of fixed NT SIDs: - Full control of users and group SIDs, you can simply remove a SID to make the user or the group unavailable wrt Windows compatibility (reduce PAC size and so on) - Do not change if the admin needs to change uidNumber or gidNumber for whatever reason. - Easy to search by SID, does not require guessing what the corresponding uid/gid are. - SIDs can be applied also to non-user/group objects w/o having to waste a uidNumber - No risk of conflicts if admins decide not to use UPGs and have unrelated groups and user that happen to algorithmically end up with the same SID (or force us to waste space to assure all groups have even RIDs and users odd RIDs) Disadvantages of fixed NT SIDs: - Requires DNA plugin to assign values since first install - Requires manual assignment, or fixup task if feature is activated after a consistent number of users/groups have been created. - third parties that have to do SID -> UID mapping on their own (think a samba server joined to the AD side and that has no knowledge these SIDs belong to an IPA domain) may get different SID -> UID mappings. I think the points above suggest we should indeed stick with the original decision of storing the SID and not go algorithmic (although the last point may be slightly annoying, it could be easily solved by forcing mappings on the other side or giving them read access to the IPA LDAP server for mapping purposes). The main issue is that we cannot assume DNA is configured from first install because an upgrade from v2 to v3 will simply go against it. But a fixup task to handle the situation shouldn't be too bad. The hardest problem will be to insure all servers that create users/groups have the DNA plugin properly configured. And a secondary, very minor, annoyance is that we will have to assign a range for SIDs as well. But this is not too hard we should probably just always assign a 200k IDs starting from 2000 or so. We do not need a random range because SIDs are unique across domains so we do not need to fear any collisions on trust relationships. So this part is easy. We limit initially to 1 Million only to keep RIDs in a very low range, so that mapping SIDs to UID/GID numbers for 3rd parties is not going to be problematic. If we assigne a larger range like 2Billion the as soon as you install a replica and create users there the range will be split in 2 and users create from that other replica will have their RID starting at 1Billion (as the range is split in 2 between the 2 replicas) which will make life difficult if someone want to limit SID ranges for posix mapping purposes. Simo. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
