The design of my application is that standard user operations run first (and produce interested information even if the user cannot proceed) and then optionally offers to make some system changes accordingly, which requires elevation. If the user chooses to proceed, the program reruns itself requiring elevation with a command line switch that tells it where in the workflow to resume. The new process then picks back up where the old one left off and makes the changes the user requested.
My problem is I don't know how to write unit tests against the library methods that necessarily make privileged calls without running all of Visual Studio as administrator. I'd really like to avoid doing that so I'm fine with the system prompting me for credentials to run some or all of my unit tests. But currently as a standard user, the calls simply fail with the "System.Management.ManagementException: Access denied" exception.
Any ideas or experiences with handling this beyond elevating the whole of Visual Studio for the session? Since I'm using the built-in unit tests, ideally the solution would still display per-test results in the test results window but that's not a requirement.
I'm not sure what you are doing that requires administrator privileges, but I would suggest that in a unit test you shouldn't actually be calling those methods, but mocking out the classes that those methods are called on.
In this way you can make sure that the right calls are being made with the right parameters, but you aren't changing the state of the system.
You could impersonate an Admin account using LogonUser().
Take a look at this blog that’s trying to solve your problem.
I liked this codeproject implementation for calling LogonUser better. There's actually many codeproject examples of LogonUser() if you search around a little.
Related
A project I'm writing at the moment requires a Windows Service to be written as it needs to run unattended. One requirement in the specification says that the service should also be able to be run interactively. This is no great problem as I can simply use Reflection to get at the OnStart/OnStop methods and use Console.ReadKey() to pause for keyboard input.
All that's really causing me to pause here is that in order to do this I need to change the output type of the project from Windows Application to Console Application. I'd like someone that has a detailed understanding of the differences between these two choices to explain what the difference is between them and if there are any ramifications for stability in production.
If, while executing in interactive mode, the service is NOT showing Forms, you can change the output type and expect no trouble. If Forms are needed, output type should remain Windows Application. As a general rule, I always start developing service apps as Console apps. It's easy to debug. When it is almost done with testing and debugging, I change to a service app.
This is more of a general theory question as I'm stuck on how to proceed since this is my first time developing an application...
I'm developing a reporting application in VS 2015 that requires two types of functionality. It needs to have a GUI so that users can interact with and create reports and those reports need to be scheduled via Windows Task Scheduler. I'm planning on using a Console Application for the scheduling portion. My question is, what would be the best way to implement this? As of right now I have two separate Projects in a single Solution. Is this the best route to take considering my needs or is there a better option that I'm not aware of? I've done some searching online but have not been able to find a valid solution. It's especially difficult since the scheduling portion needs to pull the application settings from the Windows Form Application.
Any help or guidance would be greatly appreciated. Thank you in advance!
The only reason you would need a console application would be if you actually needed a console interface. It doesn't sound like that's the case—the interface will be written in WinForms. Therefore, you don't actually need two separate applications. You can combine all the necessary functionality in a single executable.
The way to do this is by checking for command-line parameters that indicate whether the app should run interactively or headless. Probably, what you'll want to do is make the app run interactively when no command-line parameters are passed. This would be the normal case, the situation the user gets into when they double-click your app to launch it from Explorer.
When it comes time to schedule your app to run a task in the background (with Task Scheduler or anything else), you signal this by passing a special command-line parameter to your app. You can decide what this is, and you may need several of them if your app can do multiple things in the background. If configuration information/parameters need to (or can) be passed to the app to configure how it should perform the background task, you can pass these on the command line, too. Or, as you mention in the question, you could pull these settings from whatever was set/saved by the user the last time they ran the interactive version of the app.
The trick is just checking for these command-line parameters in your application's Main method. In the design I proposed, if there are no command-line parameters specified, then you just go ahead and create the main form like you normally would. If there are command-line parameters, then you need to parse them to see what action is being requested. Once you've parsed them and determined which background task should be run, you just run that background task—without ever creating/showing a form.
There are lots of different solutions for parsing command-line parameters. Using a library would probably be the easiest way, and also give you the most features. But if you just needed something really simple, like a /background mode, then you could easily write the code for this yourself, without taking a dependency on a library or needing to learn how to use it.
So you could do all of this with a single project in a single solution if you wanted to. Or, you could split different aspects of the functionality out into different projects that compile to libraries (e.g., DLLs), but still have only a single executable for simplicity.
In Windows XP it was possible to substitute the logon interface for your own GINA implementation that could add additional features to the logon screen as well as implement some organisation-specific features.
I've looked at a number of MSDN articles and they all suggest that it is impossible to achieve that with the new logon system (Windows Vista and newer).
However, at the login screen or every time the SAS sequence is invoked, the LogonUI process starts up and provides a GINA-like interface for the user to interact with.
I was wondering, is it possible to roll your own implementation of LogonUI for the purpose of replacing the login/SAS UI? I couldn't find any articles on it, but I think it is a viable option.
Tad late, but here you go. You can create a custom credential provider with your own fields to accept logon credentials (whichever form they may take). If you want to go beyond that and build a bit of workflow, you will need to launch a modal window in the credential's SetSelected method. You can then pretty much use your GINA implementation (without the actual GINA functions). Use the CPUS type to know which mode you are running in (LOGON, LOCK_WORKSTATION, CHANGE_PASSWORD etc.) and customize your UI accordingly.
Obviously, this is not the "recommended" approach (quite hacky, actually), but it is the easiest. One caveat: you will have problems with C-A-D timeouts etc., so be prepared for some surprises.
The other, possibly more elegant way, is to build the custom credential provider with the logon/unlock screen (the right way). Then provide links to trigger other workflows (for instance, reset password). You can write custom screens that get launched when a particular link is clicked by implementing the credential's CommandLinkClicked method.
If you have time and you want to do this right, I would recommend the second approach. You will save yourself a lot of headaches down the road.
I have run into a case where a Windows Form application is being run regularly via a scheduled task on a Windows Server 2003 box. The GUI is, obviously, not being used to take in any user input, so it is at best pointless. But is it also dangerous? Could it cause anything to go pop on the box?
It should not really harm.
You may want to create a standard shortcut to the application then in "properties" select the "Run" -> "Minimized" option.
Don't forget to point the task sceduler to execute the new shortcut rather than the direct application.
The GUI is, obviously, not being used
to take in any user input, so it is at
best pointless.
Just because it doesn't take input doesn't mean it does nothing. While the GUI part of it is probably pointless, the application execution itself may not be.
A Windows Form application being run regularly is the same as any other process being run regularly, and it may have been for whatever reason that the developer of the app wanted a GUI to appear while it was doing its thing or may have had plans to allow users to interrupt the running process through the GUI.
The developer may even be using a GUI control for application execution. A "good" example of this would be using a web rendering control for its DOM processing capabilities.
Could it cause anything to go pop on
the box?
If it doesn't correctly dispose of any resources it uses then yes.
I wouldn't imagine GUI apps are any more notorious than console apps for this, but the fact that someone perhaps unnecessarily used a GUI app (maybe they had only been introduced to WinForms projects) is a strong indicator to check the code and make sure all appropriate resources are being disposed of correctly (think 'using' blocks).
To understand what I'm asking, it's important to distinguish from among the several uses of SUID in Unix.
I have a project that uses an executable in the user's PATH which is owned by the project and which has the SUID bit set. In this way, when it runs, it runs in the context of the file's owner, not the calling user. This way, it has access to things that the user does not, and thereby these things are protected from the user by normal file system protections. This works reasonably well. Plans are to move the project to a client-server architecture but that's going to take some time. In the mean time, how can I replicate this type of behavior on Windows systems?
Note that the project's executables do not call the SETUID library call though, frankly, that would be a great feature to add, in my opinion, given what the project does. The project does not need system root privileges. It's first security concern is that it needs to protect its own files from the user (which is simply any user other than the file owner) and it would be very nice if it had the ability to switch to "user context" to access the file system as if it were the calling user. (In this way, it could more easily determine what is OK for the project to touch and what is not.)
The project is written in a combination of C and Java - a C program with SUID set calls the Java code...
I am keen to know all such mechanisms, and am especially focused on those which are:
Suitable for C and Java, and;
Easy to implement for non-Windows programmers, and;
Require minimal coding unique to Windows.
If some solutions are superior, please share your thoughts on whatever you are aware of in this regard.
NOTES:
LogonUser: Requires a password in plain text. How can that be an answer?
RunAs: Requires password be entered at PROMPT! ...As with LogonUser only worse; I don't see how this is an answer.
Cygwin has an excellent discussion on how they do this without requiring the user password here: Using Windows security in Cygwin
Basically they install a custom LSA authentication package that provides security tokens without requiring a password. As a fallback, when the authentication package is not installed, they use the undocumented NtCreateToken API.
An application wanting to impersonate could make a cygwin setuid call before calling java.
I don't think there's an equivilent of SETUID in Windows, but you can launch a process as another user. If you are using C, there are really only two major Windows Specific functions you'll need to look into:
LogonUser
CreateProcessAsUser
The docs for those functions are pretty good, so it shouldn't be that huge of a challenge. Basicly, you'll use LogonUser to impersonate the user, then CreateProcessAsUser to launch the JVM as that user.
You could also look at the RUNAS command, but I'm not sure if that would meet your needs or not.