[RESOLVED] Running program with full rights in Limited User Profile

I need a way to run my program with full user rights on XP.

The current situation though is that almost all the users will be running under a "limited account" on XP Home. Those that are running under a limited account each have an admin user setup on their pc's which I have the username/passwords for.

My initial thought is that I could make a small program which would act as the loader to run the main program with different user credentials. I have used Process.Start() to run other programs and it looks like there is the ability to run a program with a different username/password except it wants a domain name too. Is there a way around the domain name?

What would be better would be if there's a way for a program to "evelate" it's permission level while it's running. I don't know if this is even possible though.

I was looking at System.Security namespace but I'm finding it difficult to google for anything useful on that.

Can anyone suggest how best I could go about this?

The only way you can run your program with full rights while a limited user logged on is to write your application as a service. It is the only way.

If you write your program as a service, if you wish to have an kind of Vista compatibility, you must separate the UI into another application which runs in the user's space. In general, this is a good idea to do anyway.

Under XP with fast user switching, your service UI will only be visible from session 0, which is shared with the first user. Any additional users will not be able to see your UI. If you plan on only supporting XP / 2k / 2k3 and only supporting a single user on at any one time, you can get away with keeping your UI in your main application. However, you really should plan on divorcing the two and using some IPC mechanisms to coordinate things between the GUI instances (yes, you need to plan on having more then one running at the same time) and the service.

Just remember the GUI part will not be able to do anything beyond being a GUI, especially in a limited user (or guest user) context. At best you can write to the public space and have very restricted read privileges to anything else.

if it was possible for programs to overwrite security settings
i would think virus programmers and malware people and trojan horse makers would have a fieldday ;)

I generally agree with DeepT's approach. As a little more detail, I would specifically implement all of the "operational" code as a Windows Service and expose a WCF endpoint. Your UI then should need no rights beyond a limited user.

In this arrangement, ANY user in ANY session would be able to launch your UI.

Thank you for all your suggestions.

Writing the program as a service with a seperate GUI interface is obviously the better option.

Unfortunately I am not able to go that route at this time.

I have managed to solve my issue though. I have used the folllowing code (I have just copied the relevant portions here):

Code:

---

using System.Security.Principal;
using System.Security;

void CheckPermissions()
                {
                        //checks whether program has full rights or not.
                        //if not it elevates program to designated username/password
                        //as set in database.
                        //NOTE: NOT TESTED IN VISTA
                        if (!IsAnAdministrator())
                        {
                                //not administrator, elevate permissions
                                string pass = ReturnSetting("elevation");
                               
                                System.Security.SecureString ss = new SecureString();
                               
                                foreach (char pchar in pass)
                                {
                                        ss.AppendChar(pchar);
                                }
                               
                                try
                                {
                                        Process.Start("program.exe", "admin", ss, "");
                                        Application.Exit();
                                }
                                catch (Exception ex)
                                {
                                        ErrorLog(11, "Error Elevating Permissions", ex.Message);
                                        MessageBox.Show("Program may not work correctly. Please contact your system Administrator");
                                }
                        }
                       
                       
                }

bool IsAnAdministrator ()
                {
                        WindowsIdentity  identity = WindowsIdentity.GetCurrent();
                        WindowsPrincipal principal = new WindowsPrincipal (identity);
                       
                        return principal.IsInRole(WindowsBuiltInRole.Administrator);
                }

---

Two functions that I havn't listed code for:

ReturnSetting() - this is a function that returns a specific setting for the program, either registry or ini file. In this example it returns a password for the "admin" user. And no, my password is not stored in plain text, it is returned in plain text by the function though ;)

ErrorLog() - This logs all errors for me for later checking/debugging.

Other than those two everything should be fairly self-explanatory. I found that the process.start function allows a blank domain name in which case it just uses the username+password.

My program opens, shows the splash screen briefly, closes and then opens again with full rights.

Well... I suppose you could do that. I think most users would not want to be giving their admin password to a program. I do not think you can consider this solved unless you test this under vista, unless you do not care if it works under vista or not.

You also need to be aware the under vista, even an 'admin' user can not do a lot of things without elevated privileges. IE: If bob is an admin, and bob runs a program that wants to save a file in the program files directory, it will be forbidden to do that.

Hence, if your application is run by Tim, a limited user, with Bob's credentials, it will not be able to write into the program-files directory under vista. Because Tim is not an admin, he will not be able to elevate your program (despite it being run as Bob) to let it do what it wants.

In other words, your trick will not work for a limited user on a vista box, and will pop an elevation prompt (or simply fail) while running as Bob. Only privileges ABOVE admin will not require these prompts to be answered. The "Local System" or "System" accounts will allow you the freedom you desire, but neither of them have any kind of UI support.