----- 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
> uid and gid are the same. What would you suggest? Adding the highest
> for groups? uid*2 for users, (gid*2)+1 for groups? ... ?
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
- Easy to search by SID, does not require guessing what the corresponding
- 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