EldoS | Feel safer!

Software components for data protection, secure storage and transfer

SID of remote user on a network share is always that of SYSTEM

Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages
#35816
Posted: 02/02/2016 12:33:16
by Vinay K (Basic support level)
Joined: 01/30/2016
Posts: 9

My environment is quite simple.

On my Windows 2012 server, I have two standard users 'Alice' and 'Bob' and one admin user "admin"

I share a folder "C:\foobar" as user "admin". The folder is explicitly shared to only three users "admin", "Alice" and "Bob" with Read/Write permissions.

I run the FileMon.exe as admin, and navigate to "C:\foobar". All activities are logged in FileMon as user "admin". I do switch user on same box and login as user "Alice" and navigate to "C:/foobar" and do some activity in this folder. I can see that the FileMon will log all events correctly as user "Alice". I can further do same activities as user "Bob", and FileMon logs correctly.

However, instead of navigating to "C:\folder", I open the explorer (on the same machine) to the share "\\<comupter-name\foobar" and do some activity as any user, all file activities are logged as SYSTEM in the FileMon.

So problem occurs while accessing the folder as a share. There is a Windows Server Service that manages all connection to shares, but I do not see any config settings there.

PS: command "net accesses" gives the correct username of the logged in user.


Thanks.
#35817
Posted: 02/02/2016 12:51:31
by Eugene Mayevski (EldoS Corp.)

procmon.exe uses *N notification events. Notifications don't provide the user name. This is by design.

If you add synchronous rules for *C events, you should be able to get the user names.


Sincerely yours
Eugene Mayevski
#35818
Posted: 02/02/2016 13:16:33
by Vinay K (Basic support level)
Joined: 01/30/2016
Posts: 9

Quote
procmon.exe uses *N notification events. Notifications don't provide the user name. This is by design.


If you are talking about the Process Monitor from sysinternal.com, it does give the real remote network username in the details.


Quote
If you add synchronous rules for *C events, you should be able to get the user names.


How do we do this?

Will the callback filter be able to get the user names then?

Thanks.
#35819
Posted: 02/02/2016 13:37:05
by Vladimir Cherniga (EldoS Corp.)

Quote
G_115198218267181571372 wrote:
ow do we do this?

Will the callback filter be able to get the user names then?

Just add a CbFltFileOpenC callback handler into the FileMon sample and request originator information from there. That will be enough.
#35820
Posted: 02/02/2016 17:53:16
by Vinay K (Basic support level)
Joined: 01/30/2016
Posts: 9

Thanks, that worked fine.
#35844
Posted: 02/04/2016 16:38:48
by Vinay K (Basic support level)
Joined: 01/30/2016
Posts: 9

Are there any performance numbers on CallbackFilter that you can share?

Our use case is,
1. We run the CallbackFilter on a Windows share
2. The number of users using this share run into hundreds.
3. We are using the synchronous *C callbacks because we need remote username.
4. We register for file/folder create, read/write, rename, delete, security changes etc.

At what traffic etc. can we expect performance issues?

Thanks
#35847
Posted: 02/05/2016 03:23:33
by Vladimir Cherniga (EldoS Corp.)

Quote
G_115198218267181571372 wrote:
At what traffic etc. can we expect performance issues?

It depends on the number of callbacks you are processing per time unit. It is implied that switching from kernel mode to user mode and vice versa is expensive operation by default. Controlling data flow in read/write callbacks takes an additional time to process data copying. I would suggest do not assign a big number of callback rules with a long paths, it may cause a delays in processing.
If you minimize delays in callbacks processing, that will be enough to keep performance in acceptable range.
Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.

Reply

Statistics

Topic viewed 6364 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!