unpack_nt_owners fails with owner S-1-5-32-544
tridge at samba.org
tridge at samba.org
Wed Oct 25 23:27:12 GMT 2006
> 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
I probably don't understand sidHistory then :-)
I'm guessing you mean that we get this at some stage in a token:
and that this sid is a real user (verifiable with samr queries).
Then later after sidHistory kicks in we get a token like this:
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"
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? :-)
More information about the samba-technical