RunAs vs. Impersonation vs. WNetAddConnection2

[Milby7]

Hi!

Does anyone know how to open a file, or directory with specific account credentials without using WNetAddConnection2? Maybe by creating some kind of connection to the directory (similar to WNetAddConnection2)?

Here's some background to the problem if it will help:

In a nutshell; i'm writing a program that will alow a user to view documents that he/she wouldn't otherwise be able to view, browse to, amend, or copy.

The program allows a 'standard' user to access files in a location that the user account doesn't allow access to. This location is on a file server in a domain. I've created a special domain user account that has access to the location on the fileserver, but it can't be allowed access to anywhere else.

I've had loads of problems due to the fact that files need to be copied back and forth between the users pc and the location on the file server. Also some of the files might be word documents, meaning that the program will get word to load the document, but will also need to call word later on (using automation). I've tried these methods:

1) CreateProcessWithLogon - works ok, but one problem is that I then can't call word because it's running in another user's security context.
2) LogonUser + ImpersonateLoggedOnUser - works better than CreateProcessWithLogon because i can still call Word and I've managed to pass the user credentials to word to setup impersonation before opening the document. If i need to copy files between the local pc and the network location I've got problems though; the standard user can't copy because can't access the network location and the special account can't copy because can't access the local file system!!
3) WNetAddConnection2 - would work fine if the users session didn't already have connections (i.e. mapped drives) to shares on the same fileserver. this will always be the case and is a problem because you can't have more than one connection to the same network device using different credentials!?!?

If anyone has any suggestions I'd really appreciate the help!!

Thanks in advance.

 

[BobRodes]

Well, my first thought would be to rethink your solution. It seems to me to be a VERY bad habit to write programs that circumvent the security system. I get the feelng that you're not considering scalability in your solution, meaning that you haven't asked yourself what happens if you adopt this technique as an enterprise-wide architectural norm. Suppose you had thousands of programs circumventing your internal security, and each one in a different way? Furthermore, how would you track which user did what to which document, given that they would all be accessing all the documents as a "special domain user"?

So, rather than creating a "special domain user account" that has the access you require, I'd consider creating a user group with that access and adding the users that would be using this application to it. You might not need to write the application at all then, you would be able to add and subtract users at will, and perhaps most importantly you would be using a consistent means of providing users with appropriate access to files.

HTH

Bob

 

[Milby7]

Hi Bob!

Thanks for your reply, however the main problem with your approach would be that the users of that group would have access to the documents outside of the application & thus i wouldn't have control. Some of these documents will be invoices & the like, so the thought is to prevent anyone from playing with them once they've been submitted. Otherwise, preventing documents from being viewed, or copied illegally is also an issue.

I agree with what you've said to a degree, but the thought was that 'all' integrated applications would go through a central component that does all the circumventing. As for change control & tracking, users have a login account for the application therefore all these issues are already dealt with in the application.

Thanks!

 

[strongm]

You might want to have a look at

http://www.microsoft.com/windowsserver2003/technologies/rightsmgmt/default.mspx

 

[BobRodes]

Ok, that makes more sense to me now. If I were going to go about this, I'd probably do it through a component too. However, I also suggest you look at strongm's link. Personally, I'd want to have a hard look at that software before thinking about writing a solution of my own, even if it seemed like I were doing something small and the product were overkill.

Bob