0

I am working on the examination system and need to implement the following scenario: User ( standard windows user ) completes the exam and then it is saved on the network share. For security reasons the share does not have permissions for this user account. So I use impersonation API ( LogonUserEx, ImpersonateLoggedOnUser, RevertToSelf). It all worked fine when the user with which I do the impersonation had admin privileges on the local computer but the requirements are that it will be standard user. With standard user the share is not visible. When I log in interactively with this user the share is visible and writable. So I assume that the standard user can not mount share when not logged in interactively. Is this correct? Is there a workaround?
The only time my code runs with elevated privileges is during the setup of the software. I thought about using WNetAddConnection2 API but I need the share to be mounted to this "hidden" user profile and not the administrator one that runs the setup.

SparcU
  • 742
  • 1
  • 7
  • 27
  • Are you sure LogonUserEx is succeeding? The user account might not have the necessary logon right. I am not aware of any unusual restrictions on network access for non-interactive accounts. – Harry Johnston Mar 30 '12 at 02:07
  • Note also that this approach won't be secure. A determined user will be able to gain control of the account you are impersonating. A better approach would be to either (a) use the user's own account, arranging the content and permissions on the server so as to isolate the users from one another; or (b) use a system service running in a domain account, passing information from the user application to the service via named pipes or any similar method. – Harry Johnston Mar 30 '12 at 02:12
  • I am not allowed to run anything on the server. And yes LogonUserEx suceeds. How do you think the user doing the exam will be able to obtain the credentials of the secure user? It maybe possible with programming but if you logged on interactively and have only windows shell in front of you? – SparcU Mar 30 '12 at 07:55
  • (1) I didn't suggest running anything on the server. You could install a system service on each of the clients, running in the context of the account you're currently impersonating. That way, the sensitive account's password won't be potentially exposed to the user. (Or, depending on circumstances, you could get the server share reorganized so that the users are isolated.) – Harry Johnston Mar 30 '12 at 23:37
  • (2) If LogonUserEx and ImpersonateLoggedOnUser are succeeding, the problem might be that you the impersonation level is only SecurityImpersonation. You need SecurityDelegation level to access network resources. I can't find any documentation stating what impersonation level to expect in your scenario, but you could use OpenThreadToken and GetTokenInformation to find out. I don't see why this would be different depending on the privilege level of the account being impersonated, though. – Harry Johnston Mar 30 '12 at 23:44
  • (3) If you can prevent the user from running any of their own code, there probably isn't any way for them to take advantage, although you'll also need to make the executable execute-only and/or encrypt the password. (Otherwise they could open the executable in notepad and see the password!) HOWEVER, note that it is *very hard* to stop people from running their own code. They might bring it in over the network, or via USB stick. – Harry Johnston Mar 30 '12 at 23:49
  • (3a) Also, I'm not sure how the network redirector behaves when called during impersonation. The connection might be opened in the user's logon session rather than that of the impersonated account, even though the impersonated account's password is used to establish the connection. If so, then if the user opened the share from Explorer the existing credentials might automatically be reused. – Harry Johnston Mar 30 '12 at 23:54
  • (If you would like to discuss options in more detail, feel free to email me.) – Harry Johnston Mar 30 '12 at 23:58
  • One more thought: you're not using LOGON32_LOGON_NETWORK are you? – Harry Johnston Mar 31 '12 at 00:28
  • Some more info I learned: When I add WNetAddConnection2 during setup the problem goes away. Which is even more confusing as the setup runs as admin user. I am using LOGON32_LOGON_NEW_CREDENTIALS in LogonUserEx – SparcU Mar 31 '12 at 12:18
  • The password for share is saved during the setup ,encrypted with CryptProtectData and saved to file. – SparcU Mar 31 '12 at 12:23
  • Note that with LOGON32_LOGON_NEW_CREDENTIALS, the redirection should be established in the student's own context so they are likely to be able to access it directly, bypassing your security. – Harry Johnston Apr 01 '12 at 01:00
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/9549/discussion-between-harry-johnston-and-sparcu) – Harry Johnston Apr 01 '12 at 01:01
  • Now I have a different problem. When the shared folder is on the different computer everything is great. But if the computer is the same one that has the share the impersonated access does not work. This is quite strange. – SparcU Apr 04 '12 at 14:29

0 Answers0