----- 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 
- 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 
- 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 

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.


Freeipa-devel mailing list

Reply via email to