Retrieving remote file access details

Hello FSD Forum,

Would anyone be able to perhaps shed some insight on this [hopefully] interesting question, please:

I am writing an FSD filter driver, and all is working fine.
I can detect remote access IRPs through a combination of techniques described elsewhere on this site (e.g. detect system process, token impersonation etc.)

What I’m trying to find out is if there is anywhere stored the machine name/ip address/netbios name of the machine that initiated the request (if it’s a local access, it’s a moot point really, only useful for remote accesses).

I have retrieved the (Client) Access Token from the IRP_MJ_CREATE message, but I can’t see if/where the remote machine name/address details are stored.

I could enumerate LSA sessions up in user mode for the given LUID, but this is inefficient at best, and potentially can give incorrect results if the same user is logged on from multiple remote points.

Another somewhat ‘heavyweight’ technique would be to maintain my own logon session table using an SSPI or similar DLL.

Has anyone come across this issue and been able to find remote machine name/address details for IRP_MJ_CREATE requests initiated from a remote machine?

Many thanks,
psturge

I opened a support request with Microsoft and spoke with a file system
engineer and a network stack engineer and they both said it can’t really be
done in any kind of safe/supportable way. But if you find anything new,
please let us know!!

Doug

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-348858-
xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, December 30, 2008 9:08 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Retrieving remote file access details

Hello FSD Forum,

Would anyone be able to perhaps shed some insight on this [hopefully]
interesting question, please:

I am writing an FSD filter driver, and all is working fine.
I can detect remote access IRPs through a combination of techniques
described elsewhere on this site (e.g. detect system process, token
impersonation etc.)

What I’m trying to find out is if there is anywhere stored the machine
name/ip address/netbios name of the machine that initiated the request
(if it’s a local access, it’s a moot point really, only useful for
remote accesses).

I have retrieved the (Client) Access Token from the IRP_MJ_CREATE
message, but I can’t see if/where the remote machine name/address
details are stored.

I could enumerate LSA sessions up in user mode for the given LUID, but
this is inefficient at best, and potentially can give incorrect results
if the same user is logged on from multiple remote points.

Another somewhat ‘heavyweight’ technique would be to maintain my own
logon session table using an SSPI or similar DLL.

Has anyone come across this issue and been able to find remote machine
name/address details for IRP_MJ_CREATE requests initiated from a remote
machine?

Many thanks,
psturge


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

There is no general solution. The pattern in which are files accessed from servers (e.g. SMB, IIS, Apache, 3-rd party…) is not easily predictable. E.g. Files can be accessed asynchronously from system worker thread. I can imagine proprietary TDI filter cooperating with FSF/mini-filter for some specific protocol with strong limitations. E.g. If SSL is used you cannot easily inspect protocol to find out relations between protocol command (TCP/IP connection) and IRP/IPRs. You can probably use man-in-the-middle attack for SSL but it is quite high price with low benefit. Note that not all SSPI providers are available in kernel mode. Furthermore it seems there is only server side implementation available.
-bg

> Furthermore it seems there is only server side implementation available.
Correction: It concerns the authentication protocols like NTLM so probably it is not case of SSL provider.

-bg

Many thanks for your informative replies.
It’s looking like the solution will have to be a co-operation between gathered FSD IRPs and some other [external] auth pkg auditor. This will most likely be in a user-mode service (e.g. SSPI DLL) - TDI will be too problematic for the reasons stated above.
When I have reached a solution, I’ll post a reply for others looking for similar functionality.

Thanks!

  • Peter

How would any such solution work if the mapping between remote accesses
and local accesses is not 1:1? If client A access a file and triggers
an IRP_MJ_CREATE, then client B accesses the file and this request is
satisfied from the existing handle (does not trigger an IRP_MJ_CREATE),
would your filter still behave correctly?

  • M

xxxxx@yahoo.com wrote:

Many thanks for your informative replies.
It’s looking like the solution will have to be a co-operation between gathered FSD IRPs and some other [external] auth pkg auditor. This will most likely be in a user-mode service (e.g. SSPI DLL) - TDI will be too problematic for the reasons stated above.
When I have reached a solution, I’ll post a reply for others looking for similar functionality.

Thanks!

  • Peter


This posting is provided “AS IS” with no warranties, and confers no rights

An excellent question.
From my [admittedly limited] testing so far, if client A and client B are different hosts, an IRP_MJ_CREATE is generated for each, even when the handles are the same (a symptom of Windows security, perhaps?). As I’ve only performed limited testing in this regard (AD auths on Win2k3), this may not always be the case. For scenarios where IRP_MJ_CREATEs are not generated, an FSD dispatch hook routine would never catch this in any case, regardless of any external login id mapping. Yes, it’s true that an IRP_MJ_CREATE is needed in order to capture the Client/PrimaryToken of the caller.
The ‘mapping’ technique to be used for any solution relies on the fact that LSA generates unique LUIDs for every logon, remote and local, including multiple logons from the same user (SID). These are the same LUIDs as stored in Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext.[Primary] -or- [Client]Token.
Once the FSD has captured the LUID, this can be ‘looked-up’ in LSA to find the assoicated logon session. It is this lookup mechanism that is being investigated (so far, a security pkg DLL is the front-runner for achieving this, as it holds both LUID and client data).
Any insight/advice into potential issues regarding Malcolm’s question about ‘missing’ IRP_MJ_CREATES would be greatly appreciated.
Thanks!

  • Peter

You are asking about specific server behavior, so the answer may very
well end up being dependent upon even the specific patch release of the
given server.

In my experience, SRV will impersonate the remote user for each
IRP_MJ_CREATE. When it has an existing handle (such as for the “root
directory” of the share) it will re-open (So,
FileObject->FileName.Length = 0 and FileObject->RelatedFileObject != 0)
precisely to ensure that a correct security check is done (otherwise, it
would be an information exposure issue, since SRV shouldn’t be making
those security decisions.) If you find a case in which this is not
true, I would expect you could report it as a security bug (that doesn’t
mean it cannot happen…)

However, let’s not lose sight of the fact that you have at least two
other standard file servers currently shipping: DAV (the “Distributed
Authoring and Versioning” protocol extensions to HTTP) and NFS. In the
former case, you’d now have to be concerned about how the DAV server
(which is IIS as far as I know) implements its own logic. I must admit,
I’ve never investigated that at all. NFS Server is now shipped in the
distribution kit for Windows Server 2008 (versus previously when it was
in a separate package called “Services For Unix” but available for
Windows 2000 Server and Windows Server 2003.) I would expect that to be
more complicated because it is performing its own security mapping
(e.g., from the NFS uid/gid protocol model to the Windows security
model.)

I said “at least” because we also have the RDP file sharing component; I
suppose one could consider that to have a server component as well.
I’ve just never had much interaction with the server side component.

If all you care about is SRV, then I would expect you would be satisfied
with it’s use of impersonation credentials along the lines you’ve
described. If your concerns go beyond that, I would not be satisfied
with the level of information I have seen about how security is
implemented to make such assumptions.

Tony
OSR

RDR/SRV may collapse several opens from the same client to a single open
on the server.

However, SRV will issue a distinct IRP_MJ_CREATE for each client trying
to access the file. This is required at minimum to guarantee cache
consistency for remote access through the oplock mechanism offered by
the local file systems.

In W7, creates from SRV will be tagged by an ECP that identifies the IP
of the client among other things. I am working on getting this into
ntifs.h and into the MSDN docs. So expect to see this soon on MSDN
online and in the W7 WDK.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

xxxxx@yahoo.com wrote:

An excellent question.
From my [admittedly limited] testing so far, if client A and client B are different hosts, an IRP_MJ_CREATE is generated for each, even when the handles are the same (a symptom of Windows security, perhaps?). As I’ve only performed limited testing in this regard (AD auths on Win2k3), this may not always be the case. For scenarios where IRP_MJ_CREATEs are not generated, an FSD dispatch hook routine would never catch this in any case, regardless of any external login id mapping. Yes, it’s true that an IRP_MJ_CREATE is needed in order to capture the Client/PrimaryToken of the caller.
The ‘mapping’ technique to be used for any solution relies on the fact that LSA generates unique LUIDs for every logon, remote and local, including multiple logons from the same user (SID). These are the same LUIDs as stored in Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext.[Primary] -or- [Client]Token.
Once the FSD has captured the LUID, this can be ‘looked-up’ in LSA to find the assoicated logon session. It is this lookup mechanism that is being investigated (so far, a security pkg DLL is the front-runner for achieving this, as it holds both LUID and client data).
Any insight/advice into potential issues regarding Malcolm’s question about ‘missing’ IRP_MJ_CREATES would be greatly appreciated.
Thanks!

  • Peter

Sarosh,

Does the same thing apply for DAV and NFS vis-?-vis the ECP information in Win7?

Tony
OSR

Any chance go getting this into a W2K8 SP?

t.

On Sat, 3 Jan 2009, Sarosh Havewala wrote:

RDR/SRV may collapse several opens from the same client to a single open
on the server.

However, SRV will issue a distinct IRP_MJ_CREATE for each client trying to
access the file. This is required at minimum to guarantee cache consistency
for remote access through the oplock mechanism offered by the local file
systems.

In W7, creates from SRV will be tagged by an ECP that identifies the IP of
the client among other things. I am working on getting this into ntifs.h and
into the MSDN docs. So expect to see this soon on MSDN online and in the W7
WDK.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

xxxxx@yahoo.com wrote:
> An excellent question.
> From my [admittedly limited] testing so far, if client A and client B are
> different hosts, an IRP_MJ_CREATE is generated for each, even when the
> handles are the same (a symptom of Windows security, perhaps?). As I’ve
> only performed limited testing in this regard (AD auths on Win2k3), this
> may not always be the case. For scenarios where IRP_MJ_CREATEs are not
> generated, an FSD dispatch hook routine would never catch this in any case,
> regardless of any external login id mapping. Yes, it’s true that an
> IRP_MJ_CREATE is needed in order to capture the Client/PrimaryToken of the
> caller.
> The ‘mapping’ technique to be used for any solution relies on the fact that
> LSA generates unique LUIDs for every logon, remote and local, including
> multiple logons from the same user (SID). These are the same LUIDs as
> stored in
> Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext.[Primary]
> -or- [Client]Token.
> Once the FSD has captured the LUID, this can be ‘looked-up’ in LSA to find
> the assoicated logon session. It is this lookup mechanism that is being
> investigated (so far, a security pkg DLL is the front-runner for achieving
> this, as it holds both LUID and client data).
> Any insight/advice into potential issues regarding Malcolm’s question about
> ‘missing’ IRP_MJ_CREATES would be greatly appreciated.
> Thanks!
> - Peter
>
>


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@openmars.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

There is a way to get this information in some cases. It is fairly straightforward to get the SID from the security information when the file is opened. You can also query for the token source, which will tell you where the request came from (Lanman server, unix server, mac server, local system, etc.) Once you have the SID pass it to user mode and get the user name via WIN32 calls. If the request came from the lanman server you can query the sessions and with the right info level you get all the sessions for that user with the machine name(s). In most cases there will be only one entry and it will be the one you are looking for. If there is more than one then you need more information. There is an authentication token that is unique per session (you can get it at create time also). If you have code running on the client systems (in the current users context) you can ping them and have them connect to a named pipe that you manage in your user mode app. When you get the message you can impersonate the user and get the authentication ID and match it to the correct machine. Beware of creating a security breach though - do not have your client app just connect to any named pipe that it gets pinged with as a rouge app could fake this and impersonate the user and do bad things.

I know this works for Windows clients, although remote sessions pose a problem in that you do not know which remote session it came from. It may also work for other clients if the server API’s are available.

This clearly does not work in all cases but depending on what you need it for it may be enough.

Note that the token source is just an arbitrary, unvalidated string and doesn’t have any secured or validated meaning. Any code using that for a security decision is broken, as it could be faked by a non-admin user mode program calling LsaLogonUser directly (in Windows XP or later).

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, January 05, 2009 3:28 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Retrieving remote file access details

There is a way to get this information in some cases. It is fairly straightforward to get the SID from the security information when the file is opened. You can also query for the token source, which will tell you where the request came from (Lanman server, unix server, mac server, local system, etc.) Once you have the SID pass it to user mode and get the user name via WIN32 calls. If the request came from the lanman server you can query the sessions and with the right info level you get all the sessions for that user with the machine name(s). In most cases there will be only one entry and it will be the one you are looking for. If there is more than one then you need more information. There is an authentication token that is unique per session (you can get it at create time also). If you have code running on the client systems (in the current users context) you can ping them and have them connect to a named pipe that you manage in your user mode app. When you get the message you can impersonate the user and get the authentication ID and match it to the correct machine. Beware of creating a security breach though - do not have your client app just connect to any named pipe that it gets pinged with as a rouge app could fake this and impersonate the user and do bad things.

I know this works for Windows clients, although remote sessions pose a problem in that you do not know which remote session it came from. It may also work for other clients if the server API’s are available.

This clearly does not work in all cases but depending on what you need it for it may be enough.


NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Excellent and useful comments - many thanks to all for providing these useful insights.

With regards using the token source - I’ve found that this value can vary hugely depending on the platform/client type, Kerberos vs NTLM etc. etc. It can give a hint into the client source, but it’s really no more than a hint.
Querying LSA sessions with the LUID (in user mode) is good for gathering the user name, but the client workstation is not included - at least, not in any documented structures that I could find (if anyone knows of any undocumented LSA structures that includes the machine name, please let us know!). Rick is correct that the client can be found in other places if there is only one login from a given user. When there’s more than one, there’s no (documented) way to tell which session maps to which address.
This is where the SSPI AP DLL comes in handy. If the DLL implements the AuditLogin function, it will be called whenever a login takes place on the machine, and provides ID, user and importantly, machine details. This API is normally for custom login mechanisms (fingerprint/retina scanners, etc.), but it can be used for this purpose as well. The main caveat is that the DLL needs to be registered and loaded before the FSD starts sending data. If the app is a service, this is not generally a problem, unless you need to catch service logins from services that loaded before your own.

Yes - there will be a similar ECP for opens from the inbox NFS server.
There is no such support for DAV.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

Tony Mason wrote:

Sarosh,

Does the same thing apply for DAV and NFS vis-à-vis the ECP information in Win7?

Tony
OSR

You would need to pursue this through your PSS contact. I see no reason
this cannot be back ported to the platforms that support ECPs.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

Tracy Camp wrote:

Any chance go getting this into a W2K8 SP?

t.

On Sat, 3 Jan 2009, Sarosh Havewala wrote:

> RDR/SRV may collapse several opens from the same client to a single
> open on the server.
>
> However, SRV will issue a distinct IRP_MJ_CREATE for each client
> trying to access the file. This is required at minimum to guarantee
> cache consistency for remote access through the oplock mechanism
> offered by the local file systems.
>
> In W7, creates from SRV will be tagged by an ECP that identifies the
> IP of the client among other things. I am working on getting this into
> ntifs.h and into the MSDN docs. So expect to see this soon on MSDN
> online and in the W7 WDK.
>
> Regards,
> Sarosh.
> File System Filter Lead
> Microsoft Corp
>
> This posting is provided “AS IS” with no warranties, and confers no
> Rights
>
>
> xxxxx@yahoo.com wrote:
>> An excellent question.
>> From my [admittedly limited] testing so far, if client A and client B
>> are different hosts, an IRP_MJ_CREATE is generated for each, even
>> when the handles are the same (a symptom of Windows security,
>> perhaps?). As I’ve only performed limited testing in this regard (AD
>> auths on Win2k3), this may not always be the case. For scenarios
>> where IRP_MJ_CREATEs are not generated, an FSD dispatch hook routine
>> would never catch this in any case, regardless of any external login
>> id mapping. Yes, it’s true that an IRP_MJ_CREATE is needed in order
>> to capture the Client/PrimaryToken of the caller.
>> The ‘mapping’ technique to be used for any solution relies on the
>> fact that LSA generates unique LUIDs for every logon, remote and
>> local, including multiple logons from the same user (SID). These are
>> the same LUIDs as stored in
>> Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext.[Primary]
>> -or- [Client]Token.
>> Once the FSD has captured the LUID, this can be ‘looked-up’ in LSA to
>> find the assoicated logon session. It is this lookup mechanism that
>> is being investigated (so far, a security pkg DLL is the front-runner
>> for achieving this, as it holds both LUID and client data).
>> Any insight/advice into potential issues regarding Malcolm’s question
>> about ‘missing’ IRP_MJ_CREATES would be greatly appreciated.
>> Thanks!
>> - Peter
>>
>>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@openmars.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Hey, midiman

I am working on a similar problem. Did you find the solution eventually? Thanks !!!

This thread is over 10 years old…Start a new thread with a new question.