We have a piece of software used in our business that requires admin rights to run. However the staff are not allowed access to accounts with admin rights. This is within a windows 7 environment.
We have set-up a local admin accounts on the required computers through GPO.
The aim of the software I am creating to to launch the software that requires admin rights as this local admin account.
So far the software is working correctly in that it is launching the software as the account but it is still giving the errors that it gives when it does not have admin rights. If you right click and runas on the software and type in the account details manually it works fine.
SecureString pwd = new SecureString();
foreach (char c in "somepassword") { pwd.AppendChar(c); }
var psi = new ProcessStartInfo
{
FileName = location,
UserName = "localadminaccountname",
Domain = Environment.MachineName,
Password = pwd,
UseShellExecute = false,
Verb = "runas"
};
try
{
Process.Start(psi);
}
There is an exception catch statement with error reporting included with the code. There are no exceptions thrown when Process.Start(psi) is called. (Updated)
Thanks.
EDIT
The company build of windows 7 has User Access Control set to "Never Notify" so no UAC pop-up is shown when Process.Start(psi) is called.
If UAC is set to "Never Notify" then it is disabled - the user runs with the maximum set of privileges.
That means that if the user is an admin account, using the "runas" verb is unnecessary. It also means that if the user is NOT an admin account, it's possible that your application may stil fail to work (because the user can't elevate and OTS (over-the-shoulder) elevation is disabled.
Have you tried setting 'Load user profile' true for the IIS app pool? I had a similar situation. This worked for me.
Refer for more info:
Security exceptions in ASP.NET and Load User Profile option in IIS 7.5
Related
I am trying to install windows update patch(patch.msu) in a non admin account using impersonation class provided here http://stackoverflow.com/questions/125341/how-do-you-do-impersonation-in-net
I am hardcoding the username,passowrd and domain of that of Administrator .
I tried several LogonTypes but no impact and i get the following error/exception.
"Either a required impersonation level was not provided, or the provided impersonation" .
I have no clue how to proceed further ,we need to install certain patches on our customer systems with out sharing admin details to them.
Your guidance on this is highly appreciated.
My code sample
try
{
using (Impersonation impersonate = new Impersonation(Environment.UserDomainName,
"administrator", "XXXXXX"))
{
Process proc = new Process();
proc.StartInfo.FileName = "wusa.exe";
proc.StartInfo.Arguments = strPath;
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.Verb = "runas";
proc.Start();
proc.WaitForExit();
}
}
catch (Exception e)
{
throw new Exception(e.Message);
}
This is due to a security update long ago.
The "Impersonate a client after authentication" and "Create global objects" user rights were first introduced in Windows 2000 Service Pack 4 to help to increase security in Windows.
Overview of the "Impersonate a Client After Authentication" and the "Create Global Objects" Security Settings (821546.KB.EN-US.2.2)
When you assign the "Impersonate a client after authentication" user right to a user, you permit programs that run on behalf of that user to impersonate a client. This security setting helps to prevent unauthorized servers from impersonating clients that connect to it through methods such as remote procedure calls (RPC) or named pipes.
As you want to impersonate an domain administrator you need to add those user rights.
By default, members of the device's local Administrators group and the device's local Service account are assigned the "Impersonate a client after authentication" user right.
Solution
IMPORTANT: This does not give full administrator permissions to the user to install other applications.
The action for the first step is dependent on the environment:
If you are using Active Directory Group Policies edit the Domain Security Policy on the Domain Controller:
Click Start -> Programs -> Administrative Tools -> Domain Security Policy
If you are not using Active Directory Group Policies, change the configuration on the local computer
Click Start -> Settings -> Control Panel -> Administrative Tools -> Local Security Policies
Then
Expand Local Policies and select User Rights Assignment.
In the right pane, double-click Impersonate a client after authentication.
In the Security Policy Setting dialog box, click Add User or Group.
In the Select Users, Computers or Groups dialog box, type the name of the Group or User who will run the application.
Select Check Names and verify the name is correct.
Repeat the steps applied to the Impersonate a client after authentication setting to the Create global objects setting.
I have a problem with this situation:
I made 2 programs:
The first one just print an output saying that was launched with admin provileges or not, and the second one, execute the first program with admin privileges and without use the UAC. The trouble is that the second program can't launch the first with admin privileges i don't know why.
This is my code:
Code of the first program:
// This only prints if you start as administrator or not.
bool isElevated;
WindowsIdentity identity = WindowsIdentity.GetCurrent();
WindowsPrincipal principal = new WindowsPrincipal(identity);
isElevated = principal.IsInRole(WindowsBuiltInRole.Administrator);
Console.WriteLine("I got admin privileges?: "+isElevated);
Code of the second program:
// This execute the first program with admin privileges without UAC
string username = "myuser";
SecureString userpass = new SecureString();
userpass.AppendChar('m');
userpass.AppendChar('y');
userpass.AppendChar('p');
userpass.AppendChar('a');
userpass.AppendChar('s');
userpass.AppendChar('s');
Process program = new Process();
program.StartInfo.UserName = username;
program.StartInfo.Password = userpass;
program.StartInfo.FileName = "Path/First_program.exe";
program.StartInfo.UseShellExecute = false;
program.Start();
PD: I don't want the user to open the UAC, thats why i already insert the username and the password.
Thanks in advance.
You have half of the answer. The other half is that the program must request to be executed with elevated privileges. By default, Windows programs run in a "Basic" trust level, regardless of the true level of permissions possible under the user. To gain access to administrative powers, the program must request elevation, which by definition will involve UAC.
Programs like yours can request elevation using the runas verb in the ProcessStartInfo, or by specifying requireAdministrator elevated permissions in the manifest of either application (assuming you control them). Either way, if UAC is enabled, the user will get a prompt.
The only way to circumvent this is to set up the program that would otherwise require elevated permissions as a Windows service, configured in services.msc to run with administrative permissions. You'll get one UAC prompt when installing/registering the service to run in this way, and from then on the service can perform that task without any further UAC action. You can then use various communication technologies, from named pipes to true network comms like TCP, to signal the service that it should do what you want.
The following code checks for an admin user:
Text = new WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(WindowsBuiltInRole.Administrator).ToString();
Process p = new Process
{
StartInfo = new ProcessStartInfo
{
Verb = "runas",
FileName = "notepad",
}
};
p.Start();
When executed by my non-admin user, the first part shows "false" as expected. But in the UAC prompt - one of the "administrators" is my own account. How can that be?
(This only happens with one non-admin account. Not others on this computer. And is not offered as an option to them when executed from other accounts - they only see the real admins.)
Using a Windows 7 (x64) PC that is not connected to any other computer or domain (besides a wireless connection to the router). This was not the case until recently. Might it be that during installation of VS 2013 + Team Foundation Server somehow the account got partial Admin rights? Do partial admin rights even exist? (And yes. I've rebooted.)
I have an application that requeres to register a dll into a gac on a client computer everytime a new dll is deployed the problem is that the client computers only have restricted users with UAC turned on.
The application knows the credentials of a user that has admin rights.
The problem is if I have processStartInfo.UseShellExecute = false; then I can't get trough the UAC getting the error "The requested opperation requires elevation"
and if I have processStartInfo.UseShellExecute = true; then it does not allow to run the whole thing as a different user: "The process object must have UseShellExecute property set to false in order to start the process as a user"
internal static void Register(String assemblyName)
{
ProcessStartInfo processStartInfo = new ProcessStartInfo(lcDir + "gacutil.exe", string.Format("/i {0}.dll", assemblyName));
processStartInfo.UseShellExecute = false;
processStartInfo.WorkingDirectory = lcDir;
processStartInfo.UserName = lcUser;
processStartInfo.Password = Password;
processStartInfo.Domain = lcDomain;
processStartInfo.Verb = "runas";
Process process = Process.Start(processStartInfo);
process.WaitForExit();
}
I would like to know what the "Best practice" for that kind of thing is? I know the whoe concept looks to windows like a virus.
What I would like to achive the following:
User dosen't need to know an account with admin rights
The credencal's of the admin user are saved in the program's database
As much as possable Automated registration.
You should run this part of your code as Administrator.
What you need is impersonation.
See this article
Aricle Impersonation on Code project
You are not meant to embed such user strings within an application for security reasons.
The design idea is that you deploy using System Management Services or similar to manage the deployment (which sucks).
I got round it my using private assemblies, very similar to the way unix works.
If you are looking to add class support in SQL Native Client, then you will find it is an uphill struggle to get deployed each time.
If you know a local administrator name and password, you could use a central deployment solution and not try to get your app to impersonate an administrator.
I tried
var process = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = filename,
UserName = "System",
UseShellExecute = false,
},
};
process.Start();
but it yields
Win32Exception was unhandled
Login failed: unknown user name or wrong password
I will have to use CreateProcessAsUser?
How can I get the appropriate parameters to pass to that method?
The System accounts password is maintained interally by Windows (I think) i.e. attempting to start a process as the System account by supplying credentials in this way is ultimately destined to failure.
I did however find a forum post that describes a neat trick that can be used to run processes under the system account by (ab)using windows services:
Tip: Run process in system account (sc.exe)
Alternatively the Windows Sysinternals tool PsExec appears to allow you to run a process under the System account by using the -s switch.
The Username should be LocalSystem if you want to run your process with high privileges (it's a member of Administrators group) or LocalService for normal privileges
EDIT: My mistake LocalSystem & LocalService are not regulary users and, therefore, they cannot be provided as a username. Kragen's solution is the right one