2

I have a windows desktop app (written in Delphi) that allows users to store and retrieve files.

  1. The application stores these files in a single network shared folder (Active Directory).
  2. The various users of the app do not all have permission to see all of the files, these permissions are controlled by the app.

Currently we have to allow every user of the app access to the shared folder, so a malicious user could find the directory and gain access to all of the files.

Is there a way that the app can act as a specific user such that only the "app as a user" and not each individual needs permission to the shared folder?

Tony
  • 818
  • 1
  • 7
  • 21
  • If the answers below aren't satisfying, it's worth going back to your requirements and deciding whether a different storage model is worth considering. – Argalatyr May 08 '13 at 17:33
  • 2
    You are going about this the wrong way. Windows already implements security. File system objects are secured. If you want different users, or groups of users, to have segregated rights, simply secure the file system accordingly. This has absolutely nothing whatsoever to do with your Delphi app. This is pure and simple a server admin issue. That is the only place where you can deal with this. – David Heffernan May 08 '13 at 17:42
  • @DavidHeffernan I failed to convey in #2 that the combination of users who might have permission to access any given file is U! so server based management won't work. – Tony May 08 '13 at 19:39
  • 1
    @Argalatyr I appreciate the observation, in retrospect it might be easiest to store all these files in a database where I have more control. – Tony May 08 '13 at 19:41
  • "The combination of users who might have permission to access any given file is U!" That makes no sense to me. Never mind. If you want to manage your user security client side then I guess I don't understand your problem. – David Heffernan May 08 '13 at 22:47
  • Sorry I was in a hurry I meant the number of users factorial. Any given file could be accessible to any unique combination of users so management directly though AD seems impractical. – Tony May 09 '13 at 02:34
  • Why would that be hard to manage under AD? – David Heffernan May 09 '13 at 20:54

3 Answers3

5

You need to either:

1) run the app as the desired user.

2) have your code programmably impersonate the desired user, via LogonUser() and ImpersonateLoggedOnUser(), or other similar functions, before then accessing the shared folder. Don't forget to stop impersonating when you are finished using the folder.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • I'm accepting this because it's exactly what I was looking for in the original post. In the end though it would appear that adding a server side app or changing my storage mechanism may be a tidier solution. Thanks. – Tony May 08 '13 at 19:43
  • LogonUser(), ImpersonateLoggedOnUser() and RevertToSelf() should be wrapped in a try/finally block. If an exception occurs in your code reverToSelf() will not be called which imposes a security risk. – iPath ツ May 09 '13 at 07:44
1

Not directly, no. The app has exactly the same rights as its user has. That's part of the OS's security model. If I had to deal with something like this, I'd do it this way:

Create a second program that runs as a Service, and set it to run under a user account that has access to the shared folder. It should implement some sort of validation logic, and listen for incoming messages. (What exact method it uses for this is up to you, but you're essentially creating a server.)

Your desktop app runs under the limited user accounts. To request a file, it sends a message to the server, in which it identifies the user and the request it's making.

The server checks the request, and if it's valid, retrieves the file and passes it back to the user app. If not, it should return some sort of error message.

Mason Wheeler
  • 82,511
  • 50
  • 270
  • 477
  • How is that secure? Are you going to implement you own security? – David Heffernan May 08 '13 at 17:43
  • 1
    This is really the best way to go, but it's not a quick solution. SOAP/HTTPS with client authentication certificate, is what we would use where I work. – Chris Thornton May 08 '13 at 17:44
  • @David: That's up to the OP to implement, depending on what the security requirements are in this particular scenario. I deliberately left that part vague, because the question isn't about authentication; it's about how to get a user to be able to access things he isn't able to access directly. – Mason Wheeler May 08 '13 at 17:48
  • @MasonWheeler agreed. A classic scenario would be where users are authorized within an application to update certain fields of a database table but not others. Maybe one class of users can update customer name/address, but not credit terms, tax ID, etc.. Or perhaps one class of users can update customer records where they are the sales/territory rep. That sort of thing. You have to have access through the application, but you can't allow someone to take the database file and edit directly with Excel, or some DBA utility. – Chris Thornton May 08 '13 at 18:17
  • @Chris We are saving files to a network share that is secured with AD. It's not a DB. It's a trivial server admin task. Zero coding required. – David Heffernan May 08 '13 at 18:44
1

Not with standard file sharing -- the application is always going to running in the security context of the logged in user.

There's 2 obvious solutions I can see:

  1. Work with the AD security and user accounts you already have in place to modify the rights to the files in the shared folder. This only works if the security in your application can be mapped to AD security objects already. If you need to allow for impersonation (e.g. An administrator "logging into" the app as himself or herself from another user session), then you're going to need to get very comfortable with the various Windows Security APIs.
  2. Write a server-side component that will handle your application's authentication mechanism and provide file listings and content to the client.

It's possible that #2 could be implemented with something like WebDAV, FTP/SFTP/FTPS, or some other "already done" file transfer protocol that you can piggy back off of to save you some work.

afrazier
  • 4,784
  • 2
  • 27
  • 30