Q35 of the IFS FAQs mentions:
…Note, however, that obtaining the SID of the current caller is often not
precisely what a filter is trying to accomplish. Instead, often the filter
wishes to know the SID of the requesting thread. For local calls, this will
typically be the same. For remote calls, however, the CIFS server routinely
utilizes impersonation during IRP_MJ_CREATE and for some
IRP_MJ_SET_INFORMATION operations. Otherwise, the CIFS server uses the local
system’s credentials. To handle this case, a filter must store away the
credential information of the original caller. In the case of IRP_MJ_CREATE
the original caller’s token is specified as part of the IO_SECURITY_CONTEXT
parameter. The ACCESS_STATE structure in turn contains the
SECURITY_SUBJECT_CONTEXT and the filter can retrieve a pointer to the token
using SeQuerySubjectContextToken. The SID can then be retrieved from the
token using SeQueryInformationToken.
Either I don’t understand what a ‘remote call’ is, or I’m not understanding
the above info. I’m using the method outlined here to obtain the SID for
the IRP_MJ_CREATE operation, and it’s always the SID of the local user.
I’ve tried accessing the local file from another host using a mapped drive,
and also from another host using IE, where the logged-on user of that other
host is not the same as the user on the local box. In all cases, my
minifilter finds the SID of the local user.
Steve