Is it possible to debug a C# .NET 4 application, run unit tests, etc., using domain user credentials other than my own? I have several elevated permissions that the users and/or service accounts will not posses, and want to avoid skewing my tests and ultimately suffering from "it works on my machine" syndrome.
I specifically want to create a SqlConnection object that uses a domain service account, rather than my own. I must use a domain account, and not SQL Server account, to allow SQL Server to emit PEXEC calls to other hardware. (Sounds fun, eh?)
I am surprised the option to run debug/release as a different domain user is not already setting in the solution/project Debug properties panel. It seems like something that would be useful. Sure, I understand the security risks, but you have to admit that would be very useful in many cases.
Thanks in advance!
Possible duplicate of this question? (Using VSCommands addon)
Or this cheap way, from VBForums:
Create your executable, then using "Run As" execute it under the normal user's credentials. Once it starts, open an instance of VS and attach the debugger to it.
Related
Microsofts preferred way to handle application configuration and runtime data seems obvious at a first glance: App.config, which will be stored in the application execution directory (C:\Program Files\ProductLocation in most cases.) where only privileged users have write access. (Makes sense to me, because a casual user shouldn't be able to alter essential application configurations).
For normal user configuration, there's a user.config which will be copied into each users personal application data directory (%APPDATA%).
But this leads to a few questions:
How can I alter configurations for every user without executing the process as administrator?
Where should I store application data that doesn't get deployed with the application, instead should be generated when the application is started the first time?
How is it possible to have e.g. dynamic connections strings, like for a database health monitor application?
I checked out the program data folder (%PROGRAMDATA% -> C:\ProgramData), but it seems this place is read-only for the standard user. (Windows Installer does create folders in here if needed, but they're all read-only.) -> What happend to %ALLUSERS%?
Example where the Microsoft way may fail in my eyes:
A financial application where every user should store his information in the same database (a SqlCE file db), where as the application has to run with user privileges (I don't want to be administrator to manage my wallet). The application needs connection to a database that isn't available at runtime and may be generated in during the first run using EntityFramework. So it could be possible that even the connection string has to be dynamic, and not configured in the app.settings where such information is fixed.
This is stupid! Users could read sensitive information from other users by directly accessing the file database!
-> Security is not only a file permission thing, there could also be database users, certificates, cryptography etc.)
Do I have to develop my own settings handler as a workaround to the Microsoft intended way?
I guess this question is asked a numerous times on SO, but every answer I found showed up workarounds, different solutions. Questions regarding "best practice" are closed immediately, so I tried to provide a practical example here.
What code do I need for a C# application to restart the user's IIS while the user does not have Admin rights?
I don't think it's possible through code alone (and if it was, it'd be an exploit.)
You'd need to write a daemon that ran as a privileged user that accepted restart commands from unprivileged sources, say by checking for the existence of a lockfile or similar, or accepting commands over a socket, and then restarted the server accordingly.
Which would be a serious security risk, still, but whatever floats your boat.
It still might be better to think hard about why you want to do this. I think you'll find that whatever criteria prevent you from making the relevant user an IIS admin are excellent arguments for why the user shouldn't be rebooting IIS either.
I've got an winforms application which uses a SQL Express back-end (which is always on the local machine).
I've run into a variety of user issues where a user performs a task that creates a new database in a particular location, but it turns out that the "NT Authority\Network Service" does not have sufficient permissions over the location they specify.
I'd like to check at runtime if the user running SQLSERVR has access to a particular folder.
I've got WMI code running to determine the user/SID of the SQLSERVR process. My next step is to try to get the WindowsIdentity/WindowsPrincipal of the user so that I can query the file access rules.
But I'm stuck - how can I reliably get a WindowsIdentity when all I have is the user/domain/SID? It doesn't seem like there's a constructor that is well suited to this?
You would have to pinvoke LogonUser to obtain a token. I seriously doubt that's going to work, these service accounts are highly privileged.
Do ask yourself if this is worth the hassle. Maybe a warning is desirable but there is nothing that you could do yourself to fix the problem. It is going to require an administrator to really fix the issue. Focus on getting a good diagnostic out of the exception you get.
Can I suggest you take a different (simpler) approach? Try just impersonating the service/user account and write a quick temp file and then delete it. If you can write that file (and delete it) you can be sure that the SQL Server can do the same thing.
Here's a post that talks about impersonating the NETWORK SERVICE account: http://geek.hubkey.com/2008/02/impersonating-built-in-service-account.html
At my company we have a product which pretty much interacts with everything you can imagine... registry, databases, devices, etc... it is composed of many parts but the entire application is launched by a single executable (start.exe) which is responsbile for launching everything else - this is all legacy code and run under a USER account.
Currently this is launched as a STARTUP item (or by double-clicking on the desktop icon) in Windows, meaning when the user logins into the USER account the application (start.exe) automatically kicks off, under this account it has all the permissions it needs to run and everything has been fine for years...
Now comes the change - I have written a service (Serv.exe) that is running as LocalSystem - this service is responsible for updating the various software components of our product and works as follows:
- when the product detects an update it signals the LocalSystem service (Serv.exe) and then terminates itself
- Serv.exe will then perform all the updating
Now, after everything is done, the product (via start.exe) needs to be launched again automatically ... and this is where I need some advice ... what is the best way to restart the product (start.exe)?
Right now I use the LocalSystem Service (Serv.exe) and impersonate the USER account as follows:
- CreateEnvironmentBlock for the USER
- CreateProcessAsUser(start.exe) as the USER with the corresponding EnvBlock
- DestroyEnvironmentBlock
But is this really 100% equivalent to double-clicking on the icon in the USER account context? I need to ensure that everything is identical when it is either launched on STARTUP of USER or by Impersonation from Serv.exe (LocalSystem) - is there a risk involved? Will I still have the same rights/abilities with all databases? registry? device interaction? etc..
By loading the EnvBlock I seem to get everything I need but ... is this not a good way to do it...?
Kind of hoping for some guidance and advice from the pro's out there ...
Any help or hints would be much appreciated.
Thanks,
Update: Here is a post named: Launching an interactive process from Windows Service in Windows Vista and later. Which is exactly what you are looking for. It starts with:
The first thing you should do about it is that; don't do it. There are many limitations and bad implications and restrictions involved.
So first test if your current solution works. That depend on what the process is doing. If it is not involving user interaction. Or manipulating the current user session. Then you don't need this complex solution. If you need it, than good luck!
Before update: Its not 100% equivalent. Except authorization there are, in windows, sessions and, in each session, there are desktops. The process that is lunched from the service will run on the service session and desktop ( if the service has it). Depending on what the start.exe does, it may be important or not.
Look at the SetTokenInformation function.
Instead of launching the application directly as a "startup item" you could start a "launcher.exe" that then would launch your application. The service could then signal "launcher.exe" that another instance of the application should start after an update. Using this method you can't use the service to update "launcher.exe", but this executable should be very simple and hopefully not require any updates. Using this method would avoid all the pitfalls of trying to start an interactive application from a service.
I'm currently in the process of creating a Windows service application which will monitor changes to certain keys made in the HKEY_USERS registry. The way I do this is by collecting the SID of the current user. The issue I'm having is that its returning the administrators SID due to the service currently running as local system.
What I need the system to do is collect and return the SID of the currently logged in user (by this I dont mean the local service, local system or network service but the person whos logged into windows via the GINA), so what I need the service to do is run as that user. This will also allow the service to write back to the users network drive which is the intention of this program.
The issue I'm having is that when I try and install a user service using installutil.exe it asks for a username and password now I've tried my own credentials (I have an admin and non admin account) but it isn't having any of it plus I want the user to change depending on the person logging on and not to be fixed. Is there any way to do this?
The "The current user" assumption is a desktop Windows concept, and with Fast User Switching even that is not true anymore. The Windows services layer is rather common across desktop and server variants, and doesn't really deal well with this. It sits below the interactive sessions layer. One of the ways this manifests itself is in the ability to run services even if there are zero users logged in.
This all seems a bit confused. There can be any number of people logged on via remote desktops etc. If you as a service want to see their registry, you definitely wont get there via HKCU. If you want something like this, you should be using an autorun exe rather than a service. Anything like inspecting sessions and injecting stuff into them to access the loaded registry hive in the session is way overkill and not likely to be clean in any way.
You can find a process that runs with every user like explorer.exe then get the SID of the user that runs the process (you can use WMI like in the function here)