Problem: how to limit access to database files only to designated FoxPro application?
Q: does anybody know about similar solution for Novell server (i.e. a FoxPro application starts on workstation and access resources on a Novell server impersonating the security context)?
In many situations FoxPro dbf files can be viewed/modified in Excel, copied, moved, deleted by a user with sufficient permissions for the data folder.
RunAs utility, available in W2K and XP, can solve this issue. With this utility user A can run FoxPro application with access level of user B.
W2K domain: MYDOMAIN
W2k server: MYSERVER
Data folder on MYSERVER: c:\data
WinXP workstation, MYSTATION, current user: Peter
FoxPro app on MYSTATION: c:\apps\hr.exe
This application maps c:\data on MYSERVER to H:
Peter has no access to c:\data on MYSERVER, the data files can not be neither viewed nor copied. When he starts hr.exe directly, the application is not able to map the network resource and fails.
To start the application properly Peter types in DOS window (can be a batch file as well):
runas /user:[email protected] "c:\apps\hr.exe"
runas /user:[email protected] "c:\apps\hr.exe" | SANUR < password for DataUser >
Note, the SANUR part of the above command line is using a freeware utility to pipe the password to the runas command. Check out http://www.commandline.co.uk/sanur - William Fields
DataUser is user account on MYDOMAIN with access level sufficient to work with files in c:\data on MYSERVER.
Now hr.exe is able to map c:\data on MYSERVER and works normally. Still Peter has no access to data files outside of hr.exe application.
Please discuss -- Anatoliy Mogylevets
Why not to use Logon User and Impersonate Logged On User API calls to do all the work internally to VFP application?
Just a small sample from my collection:
From: "Remus Rusanu"
Subject: Re: DBF Security
Date: 14 ноября 2002 г. 19:06
This is a reply I posted some time ago into a different thread, but is related to this subject.
What kind of server are you refering to? Network file server with VFP DBC on it, database server (SQL or Oracle)?
The general answer is yes, you can use the program to log in as a different user, using the Logon User API function. After this call is made, the program will take the credentials of the given user and will access any resource using this credentials.
If the server is a network server, you can explicitly deny access too all users except this user that will be the VFP program. Same can be done for a database server.
Here's an example:
#define LOGON32_PROVIDER_DEFAULT 0
#define LOGON32_LOGON_INTERACTIVE 2
#define LOGON32_LOGON_NETWORK 3
#define LOGON32_LOGON_BATCH 4
#define LOGON32_LOGON_SERVICE 5
#define LOGON32_LOGON_UNLOCK 7
DECLARE integer LogonUser IN AdvApi32.DLL;
DECLARE integer ImpersonateLoggedOnUser IN AdvApi32.DLL integer hToken
DECLARE integer RevertToSelf IN AdvApi32.DLL
nToken = 0
? LogonUser("username","domain","password",LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, @nToken)
* Access will be granted, you are accessing the dbf as domain\user
USE "\\server\share\secret file.dbf"
* Now access will be denied, you are accessing the dbf as the currently user logged on at the computer's console.
MODIFY FILE "\\server\share\secret file.dbf"
Since only the program knows the password for the user that has access to the files, only the program can access the files.
- You let the Windows infrastructure handle security and access rights
- Very easy to implement, just call Logon User and Impersonate Logged On User at the very beggining of the program
- Any resources accessed by the program must be accessible to the program's secret user. I.e. if you print a report to a network printer, access rights must be granted on that printer.
- The password is stored in clear text in the program's exe. You can avoid this using some encryption.
P.S. Sorry, I'm totally new to Wiki, so I suppose somebody can reformat this page :(
After spending two days trying to make the code above work on a Windows 2008 server (so that I could later enumerate opened shares on another Windows 2008 server) I discovered the following:
1. The currently logged in user (in security context of whom the application was started originally) MUST be listed in the "Local Security Policy\Local Policies\User Rights Assignment\Impersonate a client after authentication" group. Otherwise Logon User in the code above will produce a valid handle and Impersonate Logged On User will return 1 (success), but attempting to access a file on remote server (use a table) will fail.
2. The remote server where database files are located must have UAC turned off, or the following key in registry set to 1:
If that key does not exist then create a DWORD called "LocalAccountTokenFilterPolicy" and set the value to 1
3. It is very important to close handle phToken at the end of your code after you issued RevertToSelf()
Very good article on this here: http://forums.asp.net/t/1657035.aspx
Hi Igor, thanks for your reply. I tried those three API calls recently but was not able to map network drive, UNC path did not work either. May be I missed something, will try again. -- Anatoliy Mogylevets
Please keep this discussion going. I've tried to do similar things with Create Process With Logon W (the API-equivalent of Launch As...) with mixed results. I think one has to be careful about the context in which the application is running, that is as a COM server (perhaps under a DCOM-managed identity) or as a stand-alone application. - lc
After all Impersonate Logged On User gives better solution (thanks to Igor Korolyov and Hugo Ranea). So far I tested it within simple FoxPro app -- all worked fine. As soon as I have testing results for much larger application I will post them on this page. -- Anatoliy Mogylevets
[2004.10.06] AFAIK there are some settings that affect this API calls - but they are documented in MSDN - process must have SE_TCB_NAME privilege under Win 2 K not to fail on Logon User, and
SE_CHANGE_NOTIFY_NAME privilege in "some cases" - sory, don't know what do they mean. As I tried this sample under account that have local computer admin privileges - I don't have any problems...
BTW I don't "map drives", but use UNC path to create (or access) file on protected share. New file owner was account, I'm logged in into VFP app - not my usual domain account. BTW they all (my startup account and the one in Logon User call) was AD accounts.
Could this "approach" run under Windows Network that DOES NOT has domain, but workgroup?
As long as you are able to allow and deny user permissions to folders on local computer this approach will work on a local computer (WinXP Pro, W2K). I'm not sure that without global (domain) user names it will work across a LAN. Someone should probably try :) -- Anatoliy Mogylevets
I just wanted to point out that there are certain risks using impersonation, for example if the VFP application that is using it opens (within the impersonation code) external programs, for example Explorer, the user would now have the rights of the impersonated user, and will be able to delete/view/modify files that are out of his/her permission scope.
Well, I think I was wrong about this (or it is a feature of XP SP2?), and if you try to open explorer even from within the Impersonate/EndImpersonate, it will fail to open a protected folder
Category 3 Star Topics
( Topic last updated: 2013.11.01 04:07:54 PM )