----- Original Message ----- > On 12/14/2011 10:58 AM, Simo Sorce wrote: > > ----- 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. > > > With the static IDs you will have an issue with DNA that you will > have > to implement 2 dimensional slicing if ranges. Right now the ranges > are > sliced per replica and traded accordingly. With your proposal the DNA > would have to deal with a concept of group of ranges belonging to > each > domain and make sure that every replica has its slice for the group. > I > seems that it would require changes to the DNA plugin logic, not only > configuration. > Also the point about third parties IMO is just a showstopper. If we > go > with static IDs nobody would deploy us as we are nonexistent in real > deployments while samba and other solutions are already deployed in > multiple places. Poeple will be very frustrated to find out that our > ids > do not match. > > Man ye we should do our own samba id mapping back end that would work > like idmap_rid but factor in configured range and contribute it to > samba. > > But the problem of the collisions already exists with samba when > multiple domains are in play so I really do not understand why we > should > try to solve the problem that is pretty much unsolvable.
I think you are confusing 2 problems here. 1 problem (the one you have in mind) is mapping foreign SIDs from AD domains to uid/gids, this is NOT the problem we are discussing here. What we are discussing here is how to generate the SIDs for our own domain, for consumption by AD clients. Simo. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
