On Thu, Oct 26, 2006 at 09:27:12AM +1000, tridge@xxxxxxxxx wrote:
> user_sid: S-ff-gg-hh-ii
> sids: S-aa-bb-cc-dd
> so we have a 'new' user now, but with a SID showing up in the list of
> supplementary SIDs in the token which matches the previous user_sid.
> Is that right? (I have very little experience with sidHistory, sorry)
> I would have thought that from the NT point of view, that
> S-aa-bb-cc-dd is still a 'user'. I don't think there is anything in
> particular about the supplementary SIDs list in a NT token which
> restricts these SIDs to being groups.
Right. The usual case however will be that S-aa-bb-cc-dd
will not be mappable anymore because those DCs have been
> The restriction comes when we try to map it to posix. The
> supplementary group list for a process in posix is indeed restricted
> to being a list of groups. So for us to be able to call setgroups()
> and get something sensible we have to map that SID to a group.
> Probably the simplest way to do this is indeed to allocate a posix gid
> when this happens, or use a gid previously allocated in the "dual-ACE"
> Anyway, I think this means I'm agreeing with you, I just wanted to
> make sure we are using the terminology in the same way. Is there
> anything that really indicates that S-aa-bb-cc-dd is really a group in
> the above scenario apart from it showing up in the supplementary SIDs
> list in a token? Is there some RPC call or ldap call we can do that
> shows its type as being a group? Can it have members? :-)
No, I don't think it really converted to a group in the
sense that it can have members. I did not test it, but I
think it is just an arbitrary SID hanging on the user AD
object that is added to the token, without further info
about that around. I would be surprised if lsa_lookupsids
picked this up.
BTW, nasty as it is, this _is_ relevant. I've come across
this at quite a number of sites already.