EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Getting the real user from a network share

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
Posted: 05/13/2011 10:48:57
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Hello, everyone!

I have an issue that is kind of peculiar, as most of my posts are!

We set up our virtual drive as a Network Drive and by default that allows us to share it out over our Windows Network. So, if a person on a remote machine wants to he can map our network drive in his Windows system. Now, for those of you familiar with this process, when you map a drive the system either uses the Windows userid and domain from your login to connect to the network drive, or you can supply alternate credentials for that connection.

We have done this and it works fine in general, we are having some minor problems that I'd like some help with. The virtual disk server program, where all the callbacks reside, runs as a system service on the server machine that the remote user connects to. Therefore the local security context for that program is under the \NT AUTHORITY\SYSTEM user. When the remote user connects his security context should be the user and domain that he used to map the network drive, which may be his login or some other login that he provides, but it shouldn't be \NT AUTHORITY\SYSTEM, unless he is somehow connecting to the drive through a system service on his machine.

Anyway, in our examples that do this we have found that when I stop the program in the debugger in the OpenFile, ReadFile, WriteFile, EnumerateDirectory, CloseFile callbacks, what I said above is true, and that is great. The one problem we have seen is that the DeleteFile callback is somehow called under the security context of \NT AUTHORITY\SYSTEM rather than the remote userid of the remote system.

The way that I get all this information is I use the Sender->GetOriginatorToken to get the security context token and the I use that in the Windows APIs GetTokenInformation to get the SID (sic!, my name) and then I use the Windows API LookupAccountSid to get the userid and domain.

The reason we need this information is that our database system has its own form of authorization and it needs to determine if that remote user has the authority to do whatever it is he is trying to do, be it Read, Write or Delete.

If the information is not available, then I could try to find a callback that is always called when the drive is first mapped by the remote user, get his context there, authenticate him with our database system and the allow him to do anything he wants, but again how do I know it is him in the Delete callback, when it seems like all deletes are done under the auspices of
Posted: 05/13/2011 12:45:14
by Eugene Mayevski (EldoS Corp.)

Based on your description, it looks that Delete is executed really by the system under following circumstances:

the user can "schedule" file deletion by either deleting a file for which there exist open handles or simply by calling MoveFileEx(delay_until_reboot). In one or both of those cases it's likely that the OS performs the operation on behalf of the user.

Sincerely yours
Eugene Mayevski
Posted: 05/14/2011 14:39:48
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I believe I have solved my problem. In the DeleteFile callback I use the FileInfo->get_HandleContext() method to get the context I set up when I opened the file and in there I have placed a file descriptor that is specific to the user that opened the file. This allows me to use the correct descriptor for the user who was already authenticated when he opened the file. You may say, what if he never opens the file before deleting it? But, that isn't a problem since the act of enumerating the directory, which Windows does when Explorer looks at the file, automatically opens the file and creates that FileInfo Context.
Posted: 05/14/2011 15:00:34
by Eugene Mayevski (EldoS Corp.)

I am glad that you have saved the problem for now, yet I have mentioned the cases where your solution will probably fail to work due to design of the OS. If it's the service doing the job on user's behalf after reboot, you can do nothing about this (maybe only deny the request).

Sincerely yours
Eugene Mayevski
Posted: 10/23/2012 07:50:54
by Michael Dudenhoeffer (Standard support level)
Joined: 10/23/2012
Posts: 7

Hello all!

I have encountered the same problem. I have a shared network folder and now, when a domain user is deleting a file, the DeleteFile callback is called. So far, so good. But I don't get the domain user, instead i get NT AUTHORITY for the domain name and SYSTEM for the user name. Please have a look at the following debug trace:

GetUserIdentity [domain=VS,username=mdd, user-sid=S-1-5-21-527237240-162531612-725345543-1125]
CbFsOpenFile filename=\Test\designer_frame.jpg ctx=01089CE0

GetUserIdentity [domain=VS,username=mdd, user-sid=S-1-5-21-527237240-162531612-725345543-1125]
CbFsCloseFile filename=[\Test\designer_frame.jpg] ctx=01089CE0 destroy=00

GetUserIdentity [domain=NT AUTHORITY,username=SYSTEM, user-sid=S-1-5-18]
CbFsDeleteFile: \Test\designer_frame.jpg
CbFsDeleteFile: \Test\designer_frame.jpg [direntry=01089CE0]

As you can see, the OpenFile and CloseFile callbacks are called with the correct user information (domain VS, username mdd).

Is it possible, to change that behavior in the CBFS? If not, is there some other workaround to receive the real username?
Posted: 10/23/2012 08:55:11
by Volodymyr Zinin (EldoS Corp.)

Do you use the GetOriginatorToken method to obtain the user identity from the callbacks? And please specify the version of CallbackFS you are using.
Posted: 10/23/2012 09:01:11
by Michael Dudenhoeffer (Standard support level)
Joined: 10/23/2012
Posts: 7

Yes. I'm calling GetOriginatorToken and then GetTokenInformation using the returned Token handle. The CBFS version is
Posted: 10/23/2012 09:31:35
by Volodymyr Zinin (EldoS Corp.)

Based on the CallbackFS sources I see that the OnClose and then OnDelete callbacks are called in the same context. So, theoretically, they should return the same user identity. I will check it later.
About the workaround of the problem - it's better to check the user identity inside the OnCanFileBeDeleted callback. Windows performs deletion in the following way -
1. Opens a file/directory which is being deleted (CallbackFS calls the OnOpen callback).
2. Calls the special "set file information" request where the DeleteFile flag is set (CallbackFS calls the OnCanFileBeDeleted callback).
3. Closes the file/directory (CallbackFS calls the OnClose callback plus the OnDelete one).
I.e. when you finish the OnCanFileBeDeleted callback with the error the originator of the request gets it and processes it somehow (shows the error to user, etc). In the case the OnDelete callback finishes with error then this error just gets lost.
Posted: 10/23/2012 09:32:16
by Eugene Mayevski (EldoS Corp.)

Please check if below information (from the help file) is applicable to you:

Network access
If you share the created virtual disk, you might want to get security information (account name etc.) of the network user, who accesses the virtual disk. Disks can be shared in several modes in Windows:

First is authenticated mode. In this case the network redirector (the process that receives remote disk requests and directs them to the disk driver) is impersonated to the account of the caller user and GetOriginatorToken method will return account information of that caller.
Next is guest mode. In this mode GetOriginatorToken returns information of GUEST account.
Third mode is administrative shares (those that exist by default and are named C$, D$ etc.). For such shares GetOriginatorToken returns information of LOCAL_SYSTEM account.

Sincerely yours
Eugene Mayevski
Posted: 10/23/2012 10:27:02
by Michael Dudenhoeffer (Standard support level)
Joined: 10/23/2012
Posts: 7

Thanks so far. I will check your suggestions and response then.
Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.



Topic viewed 3637 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!