unpack_nt_owners fails with owner S-1-5-32-544

[tridge at samba.org]

Volker,

 > One problem here: The role as perceived by Samba can change.
 > A user SID that we get as such in the token can show up in
 > the groups list via the sidHistory feature later on. This is
 > a different problem, but I just wanted to note that "once we
 > know which type the SID is" is not as fixed as you might
 > wish.

I probably don't understand sidHistory then :-)

I'm guessing you mean that we get this at some stage in a token:

  user_sid: S-aa-bb-cc-dd 

and that this sid is a real user (verifiable with samr queries).

Then later after sidHistory kicks in we get a token like this:

  user_sid: S-ff-gg-hh-ii
  sids[0]:  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.

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"
scheme.

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? :-)

Cheers, Tridge