not able to get domain SID in minifilter for CIFS I/O to kmdf ramdisk volume share.

NTFSD
1

Dear ntfsd,

I am able to determine if IO is local or from CIFS/SMB by assuming the
I/O is
remote CIFS I/O based on the following check, then attempting my CIFS
I/O
SID retrieval, then reverting to local I/O SID retrieval upon failure.
if ( (Data->Iopb->Parameters.Create.SecurityContext)
&& (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
&&
(Data->Iopb->Parameters.Create.SecurityContext->AccessState->SubjectSecu
rityContext.ClientToken) )
{ /* assume remote I/O until SID retrieval failure then revert
to Local I/O SID retrieval */ }
The scheme has proven pretty much 100% successful over 300+ GB of test
access in that
I am always able to get a SID corresponding to a DOMAINUSER/DOMAIN
account.
Since I have tried CIFS access to the minifilter attached to KMDF sample
ramdisk volume,
I have been getting SIDs belonging to the Local Machine belonging to
Administrator/BUILTIN
Which is definitely not what I want.

With a minifilter attached to a “Normal” volume (e.g. C:)

able to get SID for CIFS I/O using:
ObOpenObjectByPointer on
Data->Iopb->Parameters.Create.SecurityContext->

AccessState->SubjectSecurityContext.ClientToken
ZwQueryInformationToken on returned access token
RtlCopySid on returned SID
done.

able to get SID for Local I/O using:
ObGetObjectSecurity on Data->Thread
RtlGetOwnerSecurityDescriptor on security descriptor
RtlCopySid on returned SID
done.

with minifilter attached to KMDF sample ramdisk volume (X:)
This breaks because the test (next lines) fails and we automatically
revert to local I/O SID retrieval.
if ( (Data->Iopb->Parameters.Create.SecurityContext)
&& (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
&&
(Data->Iopb->Parameters.Create.SecurityContext->AccessState->SubjectSecu
rityContext.ClientToken) )
{ /* assume remote I/O until SID retrieval failure then revert
to Local I/O SID retrieval */ }
The result is that some SIDs gathered are for the Local
Administrator/BUILTIN, which is what I don’t want,
And other SIDs are for DOMAINUSER/DOMAIN, which is what I want.

able to get SID for Local I/O using:
ObGetObjectSecurity on Data->Thread
RtlGetOwnerSecurityDescriptor on security descriptor
RtlCopySid on returned SID
done.

NOT able to get SID for CIFS I/O using: (Because It never gets
attempted!)
ObOpenObjectByPointer on
Data->Iopb->Parameters.Create.SecurityContext->

AccessState->SubjectSecurityContext.ClientToken
ZwQueryInformationToken on returned access token
RtlCopySid on returned SID

The volumes are not being shared as “C$” and “X$” but rather as “C” and
“X” in the “normal” way.

So What is going on here?

Is my local/remote test inadequate for volume root shares for remote I/O
via CIFS?
If the remote I/O test fails, then there is no impersonating thread
doing access in place
for a CIFS call to the Samba redirector, or rather there is no thread
security impersonation
at all; and I am forever unable to get the true originating caller’s SID
for certain I/O operations?

I don’t like that, so again, What is really going on here?

Sincerely,
Stefan Kozak,
www.LRS.com

2

Why not use the BUILTIN\NETWORK and BUILTIN\INTERACTIVE pseudogroups for
this?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Kozak, Joe” wrote in message news:xxxxx@ntfsd…
Dear ntfsd,

I am able to determine if IO is local or from CIFS/SMB by assuming the
I/O is
remote CIFS I/O based on the following check, then attempting my CIFS
I/O
SID retrieval, then reverting to local I/O SID retrieval upon failure.
if ( (Data->Iopb->Parameters.Create.SecurityContext)
&& (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
&&
(Data->Iopb->Parameters.Create.SecurityContext->AccessState->SubjectSecu
rityContext.ClientToken) )
{ /* assume remote I/O until SID retrieval failure then revert
to Local I/O SID retrieval / }
The scheme has proven pretty much 100% successful over 300+ GB of test
access in that
I am always able to get a SID corresponding to a DOMAINUSER/DOMAIN
account.
Since I have tried CIFS access to the minifilter attached to KMDF sample
ramdisk volume,
I have been getting SIDs belonging to the Local Machine belonging to
Administrator/BUILTIN
Which is definitely not what I want.

With a minifilter attached to a “Normal” volume (e.g. C:)

able to get SID for CIFS I/O using:
ObOpenObjectByPointer on
Data->Iopb->Parameters.Create.SecurityContext->

AccessState->SubjectSecurityContext.ClientToken
ZwQueryInformationToken on returned access token
RtlCopySid on returned SID
done.

able to get SID for Local I/O using:
ObGetObjectSecurity on Data->Thread
RtlGetOwnerSecurityDescriptor on security descriptor
RtlCopySid on returned SID
done.

with minifilter attached to KMDF sample ramdisk volume (X:)
This breaks because the test (next lines) fails and we automatically
revert to local I/O SID retrieval.
if ( (Data->Iopb->Parameters.Create.SecurityContext)
&& (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
&&
(Data->Iopb->Parameters.Create.SecurityContext->AccessState->SubjectSecu
rityContext.ClientToken) )
{ / assume remote I/O until SID retrieval failure then revert
to Local I/O SID retrieval */ }
The result is that some SIDs gathered are for the Local
Administrator/BUILTIN, which is what I don’t want,
And other SIDs are for DOMAINUSER/DOMAIN, which is what I want.

able to get SID for Local I/O using:
ObGetObjectSecurity on Data->Thread
RtlGetOwnerSecurityDescriptor on security descriptor
RtlCopySid on returned SID
done.

NOT able to get SID for CIFS I/O using: (Because It never gets
attempted!)
ObOpenObjectByPointer on
Data->Iopb->Parameters.Create.SecurityContext->

AccessState->SubjectSecurityContext.ClientToken
ZwQueryInformationToken on returned access token
RtlCopySid on returned SID

The volumes are not being shared as “C$” and “X$” but rather as “C” and
“X” in the “normal” way.

So What is going on here?

Is my local/remote test inadequate for volume root shares for remote I/O
via CIFS?
If the remote I/O test fails, then there is no impersonating thread
doing access in place
for a CIFS call to the Samba redirector, or rather there is no thread
security impersonation
at all; and I am forever unable to get the true originating caller’s SID
for certain I/O operations?

I don’t like that, so again, What is really going on here?

Sincerely,
Stefan Kozak,
www.LRS.com

3

The information I need must be the SID holding the domain-logged-in
end-user’s credentials, even when that IO is originating from a remote
machine over the network using CIFS/SMB/WindowsShares. I turn around
and use that SID to obtain a GUID from the DC.

|-----Original Message-----
|From: xxxxx@lists.osr.com
|[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
|S. Shatskih
|Sent: Saturday, June 02, 2007 12:09 PM
|To: Windows File Systems Devs Interest List
|Subject: Re:[ntfsd] not able to get domain SID in minifilter
|for CIFS I/O to kmdf ramdisk volume share.
|
| Why not use the BUILTIN\NETWORK and BUILTIN\INTERACTIVE
|pseudogroups for this?
|
|–
|Maxim Shatskih, Windows DDK MVP
|StorageCraft Corporation
|xxxxx@storagecraft.com
|http://www.storagecraft.com
|
|“Kozak, Joe” wrote in message
|news:xxxxx@ntfsd…
|Dear ntfsd,
|
|I am able to determine if IO is local or from CIFS/SMB by
|assuming the I/O is remote CIFS I/O based on the following
|check, then attempting my CIFS I/O SID retrieval, then
|reverting to local I/O SID retrieval upon failure.
| if ( (Data->Iopb->Parameters.Create.SecurityContext)
| && (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
| &&
|(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
|bjectSecu
|rityContext.ClientToken) )
| { /* assume remote I/O until SID retrieval failure
|then revert to Local I/O SID retrieval / } The scheme has
|proven pretty much 100% successful over 300+ GB of test access
|in that I am always able to get a SID corresponding to a
|DOMAINUSER/DOMAIN account.
|Since I have tried CIFS access to the minifilter attached to
|KMDF sample ramdisk volume, I have been getting SIDs belonging
|to the Local Machine belonging to Administrator/BUILTIN Which
|is definitely not what I want.
|
|
|With a minifilter attached to a “Normal” volume (e.g. C:)
|
| able to get SID for CIFS I/O using:
| ObOpenObjectByPointer on
|Data->Iopb->Parameters.Create.SecurityContext->
|
|AccessState->SubjectSecurityContext.ClientToken
| ZwQueryInformationToken on returned access token
| RtlCopySid on returned SID
| done.
|
| able to get SID for Local I/O using:
| ObGetObjectSecurity on Data->Thread
| RtlGetOwnerSecurityDescriptor on security descriptor
| RtlCopySid on returned SID
| done.
|
|
|with minifilter attached to KMDF sample ramdisk volume (X:)
|This breaks because the test (next lines) fails and we
|automatically revert to local I/O SID retrieval.
| if ( (Data->Iopb->Parameters.Create.SecurityContext)
| && (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
| &&
|(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
|bjectSecu
|rityContext.ClientToken) )
| { / assume remote I/O until SID retrieval failure
|then revert to Local I/O SID retrieval */ } The result is
|that some SIDs gathered are for the Local
|Administrator/BUILTIN, which is what I don’t want, And other
|SIDs are for DOMAINUSER/DOMAIN, which is what I want.
|
| able to get SID for Local I/O using:
| ObGetObjectSecurity on Data->Thread
| RtlGetOwnerSecurityDescriptor on security descriptor
| RtlCopySid on returned SID
| done.
|
| NOT able to get SID for CIFS I/O using: (Because It never gets
|attempted!)
| ObOpenObjectByPointer on
|Data->Iopb->Parameters.Create.SecurityContext->
|
|AccessState->SubjectSecurityContext.ClientToken
| ZwQueryInformationToken on returned access token
| RtlCopySid on returned SID
|
|
|The volumes are not being shared as “C$” and “X$” but rather
|as “C” and “X” in the “normal” way.
|
|So What is going on here?
|
|Is my local/remote test inadequate for volume root shares for
|remote I/O via CIFS?
|If the remote I/O test fails, then there is no impersonating
|thread doing access in place for a CIFS call to the Samba
|redirector, or rather there is no thread security
|impersonation at all; and I am forever unable to get the true
|originating caller’s SID for certain I/O operations?
|
|I don’t like that, so again, What is really going on here?
|
|Sincerely,
|Stefan Kozak,
|www.LRS.com
|
|
|
|
|
|
|—
|Questions? First check the IFS FAQ at
|https://www.osronline.com/article.cfm?id=17
|
|You are currently subscribed to ntfsd as: xxxxx@lrs.com To
|unsubscribe send a blank email to xxxxx@lists.osr.com
|

4

Then what is you real task?

a) to distinguish SMB server’s file accesses from local
OR
b) to get the accessing SID for SMB accesses?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Kozak, Joe” wrote in message news:xxxxx@ntfsd…
The information I need must be the SID holding the domain-logged-in
end-user’s credentials, even when that IO is originating from a remote
machine over the network using CIFS/SMB/WindowsShares. I turn around
and use that SID to obtain a GUID from the DC.

|-----Original Message-----
|From: xxxxx@lists.osr.com
|[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
|S. Shatskih
|Sent: Saturday, June 02, 2007 12:09 PM
|To: Windows File Systems Devs Interest List
|Subject: Re:[ntfsd] not able to get domain SID in minifilter
|for CIFS I/O to kmdf ramdisk volume share.
|
| Why not use the BUILTIN\NETWORK and BUILTIN\INTERACTIVE
|pseudogroups for this?
|
|–
|Maxim Shatskih, Windows DDK MVP
|StorageCraft Corporation
|xxxxx@storagecraft.com
|http://www.storagecraft.com
|
|“Kozak, Joe” wrote in message
|news:xxxxx@ntfsd…
|Dear ntfsd,
|
|I am able to determine if IO is local or from CIFS/SMB by
|assuming the I/O is remote CIFS I/O based on the following
|check, then attempting my CIFS I/O SID retrieval, then
|reverting to local I/O SID retrieval upon failure.
| if ( (Data->Iopb->Parameters.Create.SecurityContext)
| && (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
| &&
|(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
|bjectSecu
|rityContext.ClientToken) )
| { /* assume remote I/O until SID retrieval failure
|then revert to Local I/O SID retrieval / } The scheme has
|proven pretty much 100% successful over 300+ GB of test access
|in that I am always able to get a SID corresponding to a
|DOMAINUSER/DOMAIN account.
|Since I have tried CIFS access to the minifilter attached to
|KMDF sample ramdisk volume, I have been getting SIDs belonging
|to the Local Machine belonging to Administrator/BUILTIN Which
|is definitely not what I want.
|
|
|With a minifilter attached to a “Normal” volume (e.g. C:)
|
| able to get SID for CIFS I/O using:
| ObOpenObjectByPointer on
|Data->Iopb->Parameters.Create.SecurityContext->
|
|AccessState->SubjectSecurityContext.ClientToken
| ZwQueryInformationToken on returned access token
| RtlCopySid on returned SID
| done.
|
| able to get SID for Local I/O using:
| ObGetObjectSecurity on Data->Thread
| RtlGetOwnerSecurityDescriptor on security descriptor
| RtlCopySid on returned SID
| done.
|
|
|with minifilter attached to KMDF sample ramdisk volume (X:)
|This breaks because the test (next lines) fails and we
|automatically revert to local I/O SID retrieval.
| if ( (Data->Iopb->Parameters.Create.SecurityContext)
| && (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
| &&
|(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
|bjectSecu
|rityContext.ClientToken) )
| { / assume remote I/O until SID retrieval failure
|then revert to Local I/O SID retrieval */ } The result is
|that some SIDs gathered are for the Local
|Administrator/BUILTIN, which is what I don’t want, And other
|SIDs are for DOMAINUSER/DOMAIN, which is what I want.
|
| able to get SID for Local I/O using:
| ObGetObjectSecurity on Data->Thread
| RtlGetOwnerSecurityDescriptor on security descriptor
| RtlCopySid on returned SID
| done.
|
| NOT able to get SID for CIFS I/O using: (Because It never gets
|attempted!)
| ObOpenObjectByPointer on
|Data->Iopb->Parameters.Create.SecurityContext->
|
|AccessState->SubjectSecurityContext.ClientToken
| ZwQueryInformationToken on returned access token
| RtlCopySid on returned SID
|
|
|The volumes are not being shared as “C$” and “X$” but rather
|as “C” and “X” in the “normal” way.
|
|So What is going on here?
|
|Is my local/remote test inadequate for volume root shares for
|remote I/O via CIFS?
|If the remote I/O test fails, then there is no impersonating
|thread doing access in place for a CIFS call to the Samba
|redirector, or rather there is no thread security
|impersonation at all; and I am forever unable to get the true
|originating caller’s SID for certain I/O operations?
|
|I don’t like that, so again, What is really going on here?
|
|Sincerely,
|Stefan Kozak,
|www.LRS.com
|
|
|
|
|
|
|—
|Questions? First check the IFS FAQ at
|https://www.osronline.com/article.cfm?id=17
|
|You are currently subscribed to ntfsd as: xxxxx@lrs.com To
|unsubscribe send a blank email to xxxxx@lists.osr.com
|

5

B: to get the accessing SID for SMB accesses… That being said, I want
only Domain listed accounts to be able to read/directory control this
particular volume, and to be able to restrict local accounts from
accessing it.

I was planning to respond affirmatively to Create I/O that was under the
security SID of a Domain Controler listed account, and reject all other
I/O, such as local machine account that is a non-domain-login, or any
other account that the Domain controler is not aware of, by returning a
STATUS_OBJECT_NAME_NOT_FOUND or STATUS_INVALID_PARAMETER or
STATUS_ACCESS_DENIED.

In doing some additional tests today, Ive found that If I respond to I/O
calls where the SID I obtain starts with 0x01 0x02 (meaning that in my
test environment, it is a non-domain sid) and I return that I/O call
with
STATUS_ACCESS_DENIED, A windows login dialog box appears on access
attemt to the shared drive via SMB access. I attempt to enter my Domain
login information, and I receive another I/O create attempt in the
kernel, but the IO call is stil running under the Localmachin
Administrator builtin. It seems that it is expecting access as the
local Admin for this initial root directory Create on the Shared volume
and nothing else, even if I give it a valid domain login, which is
understandable because the Dialog password box says “Connecting to
”.

So in recap;
all local DosDevice name access works fine (I can obtain the Domain
account SID I need)
All SMB access to the \machine\X drive fails because It insists on me
completing an I/O that
comes under SID Administrators\Builtin, and I don’t want to, and
It wont let explorer complete
its directory listing without it.

And there is that “and I don’t want to” bit in there, but aren’t things
supposed to be changeable, work-aroundable?

|-----Original Message-----
|From: xxxxx@lists.osr.com
|[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
|S. Shatskih
|Sent: Monday, June 04, 2007 1:11 PM
|To: Windows File Systems Devs Interest List
|Subject: Re:[ntfsd] not able to get domain SID in minifilter
|for CIFS I/O to kmdf ramdisk volume share.
|
| Then what is you real task?
|
| a) to distinguish SMB server’s file accesses from local
| OR
| b) to get the accessing SID for SMB accesses?
|
|–
|Maxim Shatskih, Windows DDK MVP
|StorageCraft Corporation
|xxxxx@storagecraft.com
|http://www.storagecraft.com
|
|“Kozak, Joe” wrote in message
|news:xxxxx@ntfsd…
|The information I need must be the SID holding the
|domain-logged-in end-user’s credentials, even when that IO is
|originating from a remote machine over the network using
|CIFS/SMB/WindowsShares. I turn around and use that SID to
|obtain a GUID from the DC.
|
|
||-----Original Message-----
||From: xxxxx@lists.osr.com
||[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
||Shatskih
||Sent: Saturday, June 02, 2007 12:09 PM
||To: Windows File Systems Devs Interest List
||Subject: Re:[ntfsd] not able to get domain SID in minifilter for CIFS
||I/O to kmdf ramdisk volume share.
||
|| Why not use the BUILTIN\NETWORK and BUILTIN\INTERACTIVE
||pseudogroups for this?
||
||–
||Maxim Shatskih, Windows DDK MVP
||StorageCraft Corporation
||xxxxx@storagecraft.com
||http://www.storagecraft.com
||
||“Kozak, Joe” wrote in message
||news:xxxxx@ntfsd…
||Dear ntfsd,
||
||I am able to determine if IO is local or from CIFS/SMB by
|assuming the
||I/O is remote CIFS I/O based on the following check, then
|attempting my
||CIFS I/O SID retrieval, then reverting to local I/O SID
|retrieval upon
||failure.
|| if ( (Data->Iopb->Parameters.Create.SecurityContext)
|| && (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
|| &&
||(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
||bjectSecu
||rityContext.ClientToken) )
|| { /* assume remote I/O until SID retrieval failure
|then revert
||to Local I/O SID retrieval / } The scheme has proven pretty
|much 100%
||successful over 300+ GB of test access in that I am always
|able to get
||a SID corresponding to a DOMAINUSER/DOMAIN account.
||Since I have tried CIFS access to the minifilter attached to KMDF
||sample ramdisk volume, I have been getting SIDs belonging to
|the Local
||Machine belonging to Administrator/BUILTIN Which is
|definitely not what
||I want.
||
||
||With a minifilter attached to a “Normal” volume (e.g. C:)
||
|| able to get SID for CIFS I/O using:
|| ObOpenObjectByPointer on
||Data->Iopb->Parameters.Create.SecurityContext->
||
||AccessState->SubjectSecurityContext.ClientToken
|| ZwQueryInformationToken on returned access token
|| RtlCopySid on returned SID
|| done.
||
|| able to get SID for Local I/O using:
|| ObGetObjectSecurity on Data->Thread
|| RtlGetOwnerSecurityDescriptor on security descriptor
|| RtlCopySid on returned SID
|| done.
||
||
||with minifilter attached to KMDF sample ramdisk volume (X:)
||This breaks because the test (next lines) fails and we
||automatically revert to local I/O SID retrieval.
|| if ( (Data->Iopb->Parameters.Create.SecurityContext)
|| && (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
|| &&
||(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
||bjectSecu
||rityContext.ClientToken) )
|| { / assume remote I/O until SID retrieval failure
||then revert to Local I/O SID retrieval */ } The result is
||that some SIDs gathered are for the Local
||Administrator/BUILTIN, which is what I don’t want, And other
||SIDs are for DOMAINUSER/DOMAIN, which is what I want.
||
|| able to get SID for Local I/O using:
|| ObGetObjectSecurity on Data->Thread
|| RtlGetOwnerSecurityDescriptor on security descriptor
|| RtlCopySid on returned SID
|| done.
||
|| NOT able to get SID for CIFS I/O using: (Because It never gets
||attempted!)
|| ObOpenObjectByPointer on
||Data->Iopb->Parameters.Create.SecurityContext->
||
||AccessState->SubjectSecurityContext.ClientToken
|| ZwQueryInformationToken on returned access token
|| RtlCopySid on returned SID
||
||
||The volumes are not being shared as “C$” and “X$” but rather
||as “C” and “X” in the “normal” way.
||
||So What is going on here?
||
||Is my local/remote test inadequate for volume root shares for
||remote I/O via CIFS?
||If the remote I/O test fails, then there is no impersonating
||thread doing access in place for a CIFS call to the Samba
||redirector, or rather there is no thread security
||impersonation at all; and I am forever unable to get the true
||originating caller’s SID for certain I/O operations?
||
||I don’t like that, so again, What is really going on here?
||
||Sincerely,
||Stefan Kozak,
||www.LRS.com
||
||
||
||
||
||
||—
||Questions? First check the IFS FAQ at
||https://www.osronline.com/article.cfm?id=17
||
||You are currently subscribed to ntfsd as: xxxxx@lrs.com To
||unsubscribe send a blank email to xxxxx@lists.osr.com
||
|
|
|—
|Questions? First check the IFS FAQ at
|https://www.osronline.com/article.cfm?id=17
|
|You are currently subscribed to ntfsd as: xxxxx@lrs.com
|To unsubscribe send a blank email to xxxxx@lists.osr.com
|

6

Are you trying the primary token or the impersonation token too?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Kozak, Joe” wrote in message news:xxxxx@ntfsd…
B: to get the accessing SID for SMB accesses… That being said, I want
only Domain listed accounts to be able to read/directory control this
particular volume, and to be able to restrict local accounts from
accessing it.

I was planning to respond affirmatively to Create I/O that was under the
security SID of a Domain Controler listed account, and reject all other
I/O, such as local machine account that is a non-domain-login, or any
other account that the Domain controler is not aware of, by returning a
STATUS_OBJECT_NAME_NOT_FOUND or STATUS_INVALID_PARAMETER or
STATUS_ACCESS_DENIED.

In doing some additional tests today, Ive found that If I respond to I/O
calls where the SID I obtain starts with 0x01 0x02 (meaning that in my
test environment, it is a non-domain sid) and I return that I/O call
with
STATUS_ACCESS_DENIED, A windows login dialog box appears on access
attemt to the shared drive via SMB access. I attempt to enter my Domain
login information, and I receive another I/O create attempt in the
kernel, but the IO call is stil running under the Localmachin
Administrator builtin. It seems that it is expecting access as the
local Admin for this initial root directory Create on the Shared volume
and nothing else, even if I give it a valid domain login, which is
understandable because the Dialog password box says “Connecting to
”.

So in recap;
all local DosDevice name access works fine (I can obtain the Domain
account SID I need)
All SMB access to the \machine\X drive fails because It insists on me
completing an I/O that
comes under SID Administrators\Builtin, and I don’t want to, and
It wont let explorer complete
its directory listing without it.

And there is that “and I don’t want to” bit in there, but aren’t things
supposed to be changeable, work-aroundable?

|-----Original Message-----
|From: xxxxx@lists.osr.com
|[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
|S. Shatskih
|Sent: Monday, June 04, 2007 1:11 PM
|To: Windows File Systems Devs Interest List
|Subject: Re:[ntfsd] not able to get domain SID in minifilter
|for CIFS I/O to kmdf ramdisk volume share.
|
| Then what is you real task?
|
| a) to distinguish SMB server’s file accesses from local
| OR
| b) to get the accessing SID for SMB accesses?
|
|–
|Maxim Shatskih, Windows DDK MVP
|StorageCraft Corporation
|xxxxx@storagecraft.com
|http://www.storagecraft.com
|
|“Kozak, Joe” wrote in message
|news:xxxxx@ntfsd…
|The information I need must be the SID holding the
|domain-logged-in end-user’s credentials, even when that IO is
|originating from a remote machine over the network using
|CIFS/SMB/WindowsShares. I turn around and use that SID to
|obtain a GUID from the DC.
|
|
||-----Original Message-----
||From: xxxxx@lists.osr.com
||[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
||Shatskih
||Sent: Saturday, June 02, 2007 12:09 PM
||To: Windows File Systems Devs Interest List
||Subject: Re:[ntfsd] not able to get domain SID in minifilter for CIFS
||I/O to kmdf ramdisk volume share.
||
|| Why not use the BUILTIN\NETWORK and BUILTIN\INTERACTIVE
||pseudogroups for this?
||
||–
||Maxim Shatskih, Windows DDK MVP
||StorageCraft Corporation
||xxxxx@storagecraft.com
||http://www.storagecraft.com
||
||“Kozak, Joe” wrote in message
||news:xxxxx@ntfsd…
||Dear ntfsd,
||
||I am able to determine if IO is local or from CIFS/SMB by
|assuming the
||I/O is remote CIFS I/O based on the following check, then
|attempting my
||CIFS I/O SID retrieval, then reverting to local I/O SID
|retrieval upon
||failure.
|| if ( (Data->Iopb->Parameters.Create.SecurityContext)
|| && (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
|| &&
||(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
||bjectSecu
||rityContext.ClientToken) )
|| { /* assume remote I/O until SID retrieval failure
|then revert
||to Local I/O SID retrieval / } The scheme has proven pretty
|much 100%
||successful over 300+ GB of test access in that I am always
|able to get
||a SID corresponding to a DOMAINUSER/DOMAIN account.
||Since I have tried CIFS access to the minifilter attached to KMDF
||sample ramdisk volume, I have been getting SIDs belonging to
|the Local
||Machine belonging to Administrator/BUILTIN Which is
|definitely not what
||I want.
||
||
||With a minifilter attached to a “Normal” volume (e.g. C:)
||
|| able to get SID for CIFS I/O using:
|| ObOpenObjectByPointer on
||Data->Iopb->Parameters.Create.SecurityContext->
||
||AccessState->SubjectSecurityContext.ClientToken
|| ZwQueryInformationToken on returned access token
|| RtlCopySid on returned SID
|| done.
||
|| able to get SID for Local I/O using:
|| ObGetObjectSecurity on Data->Thread
|| RtlGetOwnerSecurityDescriptor on security descriptor
|| RtlCopySid on returned SID
|| done.
||
||
||with minifilter attached to KMDF sample ramdisk volume (X:)
||This breaks because the test (next lines) fails and we
||automatically revert to local I/O SID retrieval.
|| if ( (Data->Iopb->Parameters.Create.SecurityContext)
|| && (Data->Iopb->Parameters.Create.SecurityContext->AccessState)
|| &&
||(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
||bjectSecu
||rityContext.ClientToken) )
|| { / assume remote I/O until SID retrieval failure
||then revert to Local I/O SID retrieval */ } The result is
||that some SIDs gathered are for the Local
||Administrator/BUILTIN, which is what I don’t want, And other
||SIDs are for DOMAINUSER/DOMAIN, which is what I want.
||
|| able to get SID for Local I/O using:
|| ObGetObjectSecurity on Data->Thread
|| RtlGetOwnerSecurityDescriptor on security descriptor
|| RtlCopySid on returned SID
|| done.
||
|| NOT able to get SID for CIFS I/O using: (Because It never gets
||attempted!)
|| ObOpenObjectByPointer on
||Data->Iopb->Parameters.Create.SecurityContext->
||
||AccessState->SubjectSecurityContext.ClientToken
|| ZwQueryInformationToken on returned access token
|| RtlCopySid on returned SID
||
||
||The volumes are not being shared as “C$” and “X$” but rather
||as “C” and “X” in the “normal” way.
||
||So What is going on here?
||
||Is my local/remote test inadequate for volume root shares for
||remote I/O via CIFS?
||If the remote I/O test fails, then there is no impersonating
||thread doing access in place for a CIFS call to the Samba
||redirector, or rather there is no thread security
||impersonation at all; and I am forever unable to get the true
||originating caller’s SID for certain I/O operations?
||
||I don’t like that, so again, What is really going on here?
||
||Sincerely,
||Stefan Kozak,
||www.LRS.com
||
||
||
||
||
||
||—
||Questions? First check the IFS FAQ at
||https://www.osronline.com/article.cfm?id=17
||
||You are currently subscribed to ntfsd as: xxxxx@lrs.com To
||unsubscribe send a blank email to xxxxx@lists.osr.com
||
|
|
|—
|Questions? First check the IFS FAQ at
|https://www.osronline.com/article.cfm?id=17
|
|You are currently subscribed to ntfsd as: xxxxx@lrs.com
|To unsubscribe send a blank email to xxxxx@lists.osr.com
|

7

I am using both, but nothing is coming in on ClientToken
I am getting from the PrimaryToken, sids of S-1-5-32-544 and S-1-5-18
when handling SMB I/O.
Apparantly that’s all the system is going to give me for some of the SMB
I/O.

|-----Original Message-----
|From: xxxxx@lists.osr.com
|[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
|S. Shatskih
|Sent: Monday, June 04, 2007 5:11 PM
|To: Windows File Systems Devs Interest List
|Subject: Re:[ntfsd] not able to get domain SID in minifilter
|for CIFS I/O to kmdf ramdisk volume share.
|
| Are you trying the primary token or the impersonation token too?
|
|–
|Maxim Shatskih, Windows DDK MVP
|StorageCraft Corporation
|xxxxx@storagecraft.com
|http://www.storagecraft.com
|
|“Kozak, Joe” wrote in message
|news:xxxxx@ntfsd…
|B: to get the accessing SID for SMB accesses… That being
|said, I want only Domain listed accounts to be able to
|read/directory control this particular volume, and to be able
|to restrict local accounts from accessing it.
|
|I was planning to respond affirmatively to Create I/O that was
|under the security SID of a Domain Controler listed account,
|and reject all other I/O, such as local machine account that
|is a non-domain-login, or any other account that the Domain
|controler is not aware of, by returning a
|STATUS_OBJECT_NAME_NOT_FOUND or STATUS_INVALID_PARAMETER or
|STATUS_ACCESS_DENIED.
|
|In doing some additional tests today, Ive found that If I
|respond to I/O calls where the SID I obtain starts with 0x01
|0x02 (meaning that in my test environment, it is a non-domain
|sid) and I return that I/O call with STATUS_ACCESS_DENIED, A
|windows login dialog box appears on access attemt to the
|shared drive via SMB access. I attempt to enter my Domain
|login information, and I receive another I/O create attempt in
|the kernel, but the IO call is stil running under the Localmachin
|Administrator builtin. It seems that it is expecting access as the
|local Admin for this initial root directory Create on the
|Shared volume and nothing else, even if I give it a valid
|domain login, which is understandable because the Dialog
|password box says “Connecting to ”.
|
|So in recap;
|all local DosDevice name access works fine (I can obtain the
|Domain account SID I need) All SMB access to the \machine\X
|drive fails because It insists on me completing an I/O that
|comes under SID Administrators\Builtin, and I don’t want to,
|and It wont let explorer complete its directory listing without it.
|
|And there is that “and I don’t want to” bit in there, but
|aren’t things supposed to be changeable, work-aroundable?
|
|
|
|
||-----Original Message-----
||From: xxxxx@lists.osr.com
||[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
||Shatskih
||Sent: Monday, June 04, 2007 1:11 PM
||To: Windows File Systems Devs Interest List
||Subject: Re:[ntfsd] not able to get domain SID in minifilter for CIFS
||I/O to kmdf ramdisk volume share.
||
|| Then what is you real task?
||
|| a) to distinguish SMB server’s file accesses from local
|| OR
|| b) to get the accessing SID for SMB accesses?
||
||–
||Maxim Shatskih, Windows DDK MVP
||StorageCraft Corporation
||xxxxx@storagecraft.com
||http://www.storagecraft.com
||
||“Kozak, Joe” wrote in message
||news:xxxxx@ntfsd…
||The information I need must be the SID holding the domain-logged-in
||end-user’s credentials, even when that IO is originating from
|a remote
||machine over the network using CIFS/SMB/WindowsShares. I turn around
||and use that SID to obtain a GUID from the DC.
||
||
|||-----Original Message-----
|||From: xxxxx@lists.osr.com
|||[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
|||Shatskih
|||Sent: Saturday, June 02, 2007 12:09 PM
|||To: Windows File Systems Devs Interest List
|||Subject: Re:[ntfsd] not able to get domain SID in minifilter
|for CIFS
|||I/O to kmdf ramdisk volume share.
|||
||| Why not use the BUILTIN\NETWORK and BUILTIN\INTERACTIVE
|||pseudogroups for this?
|||
|||–
|||Maxim Shatskih, Windows DDK MVP
|||StorageCraft Corporation
|||xxxxx@storagecraft.com
|||http://www.storagecraft.com
|||
|||“Kozak, Joe” wrote in message
|||news:xxxxx@ntfsd…
|||Dear ntfsd,
|||
|||I am able to determine if IO is local or from CIFS/SMB by
||assuming the
|||I/O is remote CIFS I/O based on the following check, then
||attempting my
|||CIFS I/O SID retrieval, then reverting to local I/O SID
||retrieval upon
|||failure.
||| if ( (Data->Iopb->Parameters.Create.SecurityContext)
||| &&
|(Data->Iopb->Parameters.Create.SecurityContext->AccessState)
||| &&
|||(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
|||bjectSecu
|||rityContext.ClientToken) )
||| { /* assume remote I/O until SID retrieval failure
||then revert
|||to Local I/O SID retrieval / } The scheme has proven pretty
||much 100%
|||successful over 300+ GB of test access in that I am always
||able to get
|||a SID corresponding to a DOMAINUSER/DOMAIN account.
|||Since I have tried CIFS access to the minifilter attached to KMDF
|||sample ramdisk volume, I have been getting SIDs belonging to
||the Local
|||Machine belonging to Administrator/BUILTIN Which is
||definitely not what
|||I want.
|||
|||
|||With a minifilter attached to a “Normal” volume (e.g. C:)
|||
||| able to get SID for CIFS I/O using:
||| ObOpenObjectByPointer on
|||Data->Iopb->Parameters.Create.SecurityContext->
|||
|||AccessState->SubjectSecurityContext.ClientToken
||| ZwQueryInformationToken on returned access token
||| RtlCopySid on returned SID
||| done.
|||
||| able to get SID for Local I/O using:
||| ObGetObjectSecurity on Data->Thread
||| RtlGetOwnerSecurityDescriptor on security descriptor
||| RtlCopySid on returned SID
||| done.
|||
|||
|||with minifilter attached to KMDF sample ramdisk volume (X:)
|||This breaks because the test (next lines) fails and we
|||automatically revert to local I/O SID retrieval.
||| if ( (Data->Iopb->Parameters.Create.SecurityContext)
||| &&
|(Data->Iopb->Parameters.Create.SecurityContext->AccessState)
||| &&
|||(Data->Iopb->Parameters.Create.SecurityContext->AccessState->Su
|||bjectSecu
|||rityContext.ClientToken) )
||| { / assume remote I/O until SID retrieval failure
|||then revert to Local I/O SID retrieval */ } The result is
|||that some SIDs gathered are for the Local
|||Administrator/BUILTIN, which is what I don’t want, And other
|||SIDs are for DOMAINUSER/DOMAIN, which is what I want.
|||
||| able to get SID for Local I/O using:
||| ObGetObjectSecurity on Data->Thread
||| RtlGetOwnerSecurityDescriptor on security descriptor
||| RtlCopySid on returned SID
||| done.
|||
||| NOT able to get SID for CIFS I/O using: (Because It never gets
|||attempted!)
||| ObOpenObjectByPointer on
|||Data->Iopb->Parameters.Create.SecurityContext->
|||
|||AccessState->SubjectSecurityContext.ClientToken
||| ZwQueryInformationToken on returned access token
||| RtlCopySid on returned SID
|||
|||
|||The volumes are not being shared as “C$” and “X$” but rather
|||as “C” and “X” in the “normal” way.
|||
|||So What is going on here?
|||
|||Is my local/remote test inadequate for volume root shares for
|||remote I/O via CIFS?
|||If the remote I/O test fails, then there is no impersonating
|||thread doing access in place for a CIFS call to the Samba
|||redirector, or rather there is no thread security
|||impersonation at all; and I am forever unable to get the true
|||originating caller’s SID for certain I/O operations?
|||
|||I don’t like that, so again, What is really going on here?
|||
|||Sincerely,
|||Stefan Kozak,
|||www.LRS.com
|||
|||
|||
|||
|||
|||
|||—
|||Questions? First check the IFS FAQ at
|||https://www.osronline.com/article.cfm?id=17
|||
|||You are currently subscribed to ntfsd as: xxxxx@lrs.com To
|||unsubscribe send a blank email to xxxxx@lists.osr.com
|||
||
||
||—
||Questions? First check the IFS FAQ at
||https://www.osronline.com/article.cfm?id=17
||
||You are currently subscribed to ntfsd as: xxxxx@lrs.com
||To unsubscribe send a blank email to xxxxx@lists.osr.com
||
|
|
|—
|Questions? First check the IFS FAQ at
|https://www.osronline.com/article.cfm?id=17
|
|You are currently subscribed to ntfsd as: xxxxx@lrs.com
|To unsubscribe send a blank email to xxxxx@lists.osr.com
|