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.
Related
I want to write a function in a windows service application to remove a given computer name from Active Directory.
The Windows service is running on a machine which is domain-joined to the DC. Currently I have logged in to this machine with domain admin account.
The Windows service is running under the security context of "NT AUTHORITY/SYSTEM" and this should not be changed, as there shouldn't be any user interaction after installing the application, meaning that admin shouldn't enter their credentials in services.
When I run the application with my newly added code to delete the computer account, it doesn't work. However, when I change the logon info on the Windows Service and update that with domain admin credentials, it's able to successfully remove the computer account from AD.
Below is [a shortened version of] the function used to delete computer accounts.
Is there any way I can modify the code to be able to remove Computer Accounts using the same security context (NT AUTHORITY/SYSTEM)?
private void DeleteComputerAccount(string CompName, DirectoryEntry DirEntry)
{
try
{
//Delete computer account
DirectorySearcher search = new DirectorySearcher(DirEntry, "(name=" + CompName + ")");
SearchResult res = search.FindOne();
res.GetDirectoryEntry().DeleteTree();
}
catch (Exception)
{
Throw();
}
}
Where DeleteComputerAccount is called:
DirectoryEntry dirEntry = new DirectoryEntry("LDAP://domain.contoso.com");
string compName = "MyWorkstation01";
DeleteComputerAccount(compName, dirEntry);
When a service runs as local system, it will access the network (and thus AD) in the security context of the host's computer account. You can delegate the computer account (or better, a group which the computer is a member of) the ability to delete objects from AD. This link has accurate advice on how to complete that task - http://sigkillit.com/2013/06/12/delegate-adddelete-computer-objects-in-ad/
While not what you asked, a couple other things stand out to me:
You're not filtering your search very well. You might get something other than what you want back. I'd suggest a filter like this instead: (&(objectClass=computer)(sAMAccountName=<PCName>$))
Local system is a lot of access. Could you run this as network service instead?
I'm using Windows 10. Here is my code to map the network drive.
System.Diagnostics.Process p = new System.Diagnostics.Process();
p.StartInfo.UseShellExecute = true;
p.StartInfo.Verb = "runas";
p.StartInfo.FileName = "net.exe";
p.StartInfo.Arguments = "use Z: " + dPath; //dPath has escaped characters
p.Start();
What I was trying to do was trying to run the command net.exe use Z: DPATH as administrator but the Z drive does not appear in File Explorer but when I run the exact same command using cmd with Admin rights, the Z drive appears correctly.
Proof of mapped drive
My Network drive is mapped as evidenced below (Encountered this error when trying to re-map it manually) just that it wasn't appearing under Network Locations in File Explorer > This PC.
This behaviour is caused by UAC (User Account Control). When logging on to Windows as an admin, there are two sessions created. One with admin rights and one without. When you map the drives programmatically, you are doing it with the session with admin rights.
However, when you use File Explorer to view the Network Locations, you are using standard rights. For mapped drives, the admin and standard rights are not shared. Hence, the admin is not able to view the mapped drive eventhough it was created with admin rights.
Solution 1
Click Start, type regedit in the Start programs and files box, and
then press ENTER.
Locate and then right-click the registry subkey
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
Point to New, and then click DWORD Value.
Type EnableLinkedConnections, and then press ENTER.
Right-click EnableLinkedConnections, and then click Modify.
In the Value data box, type 1, and then click OK.
Exit Registry Editor, and then restart the computer.
Solution 2
Run File Explorer as administrator
When making a right click on the Explorer and select "Run as
administrator" it doesn't start the Windows Explorer with admin
rights. The Windows Vista/7/8/10 Explorer includes a special function to
block such requests.
To disable it, start regedit.exe and go to the following key:
HKEY_CLASSES_ROOT\AppID{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}
make a right click on Permissions and set your user as owner of the key and
give your current user writing permissions.
Next, delete or rename the value RunAs. Now the Elevated-Unelevated
Explorer Factory is disabled and you can start the Explorer with admin
rights.
Solution 3
If the above can't work, disable your UAC (User Account Control) by going into User Account Control Settings and moving the slider to Never notify
Also, if you have Professional, Enterprise, or Ultimate version of windows installed, you need to look into a program in Administrative tools called Local Security Policy and disable all the policies related to UAC in Security Settings > Local Policies > Security Options (Located in the bottom 15 policies of the list)
It helped me restarting explorer.exe with admin rights via Task Manager.
I want to check some Windows services status on different remote servers like this:
ServiceController sc = new ServiceController("MyWindowsService", "COMPUTER_NAME");
var status = sc.Status
But I don't (and can't) have Administrator privileges on those servers.
What right should I be asking for to check the status ?
I don't wanna be able to restart them either, I need Read access only,
The application isn't running on the same machine.
Non-admin users can connect to the Service Control Manager remotely, provided they have the "Access this computer from the network" user right. By default this right is granted to all users.
Access to individual services is controlled by the ACL on each service. You must already know the service name, because a non-admin user cannot enumerate services remotely.
The default security descriptor for a service is as follows:
D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
You can determine the security descriptor for a service using the sc sdshow command. The string format is described in Security Descriptor Definition Language on MSDN.
OK, let's expand out that security descriptor string. This is a bit tricky because the mapping between the SDDL permissions and equivalent security manager permissions does not appear to be well documented in MSDN or in the SDK headers; luckily, Wayne Martin has already done the heavy lifting for us and posted the results in the blog entry Service Control Manager Security for non-admins.
D: - this part is the DACL, the permissions on the service.
Since all the entries are allow entries, the order isn't significant; I'll list them from least to most privilege for convenience.
(A;;CCLCSWLOCRRC;;;IU) - allow the interactive user the following rights:
CC - SERVICE_QUERY_CONFIG (the right to query the service configuration)
LC - SERVICE_QUERY_STATUS (the right to query the service status)
SW - SERVICE_ENUMERATE_DEPENDENTS (the right to see service dependencies)
LO - SERVICE_INTERROGATE (the right to send SERVICE_CONTROL_INTERROGATE)
CR - SERVICE_USER_DEFINED_CONTROL (the right to send a user defined control)
RC - READ_CONTROL (the right to see the permissions)
(A;;CCLCSWLOCRRC;;;SU) - allow services the following rights:
same as for the interactive user
(A;;CCLCSWRPWPDTLOCRRC;;;SY) - allow local system the following rights:
same as for the interactive user, plus:
RP - SERVICE_START (the right to start the service)
WP - SERVICE_STOP (the right to stop the service)
DT - SERVICE_PAUSE_CONTINUE (the right to send pause and continue requests)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) - allow the Administrators group:
same as for local system, plus:
DC - SERVICE_CHANGE_CONFIG (the right to reconfigure the service)
SD - DELETE (the right to delete the service)
WD - WRITE_DAC (permission to change the permissions)
WO - WRITE_OWNER (permission to take ownership)
The second part of the security descriptor string (S:(...)) is the SACL, which controls what auditing is done. We're not interested in that at the moment.
You will notice that there are no allow permissions applicable to non-administrative remote users. To give remote access to a particular user, add an allow ACE for that user with the same permissions as the interactive user.
If this is your own service, you can change the permissions when the service is installed using the SetServiceObjectSecurity function. You could also write a program using this function to change the permissions on an existing service.
Alternatively, you can use sc sdset at the command line to set the permissions for an existing service based on a SDDL string. You will first need to look up the SID string for the user; in a domain, you can do this using Active Directory Users and Computers. The SID string can be seen via the Attribute Editor tab, in the objectSid attribute. (Unfortunately you can't copy and paste that way. Suggestions for more convenient methods of looking up a user's SID are welcomed.)
If the SID string were S-1-5-21-131085535662-8349591032-725385543-5981, for example, the command line would be
sc sdset myservice D:(A;;CCLCSWLOCRRC;;;S-1-5-21-131085535662-8349591032-725385543-5981)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)
(You do not need to specify the SACL; if absent, the existing SACL will be retained.)
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
I'm developing a windows service in C#.net, Account: LocalSystem, System: Windows XP SP3
I want this service to check for all currently logged users if a specific application is running and if not - start this application AS corresponding user name.
I provide domain, name, password, but Start() throws Win32Exception
exception "Access is denied"
process.StartInfo.Domain = domain;
process.StartInfo.UserName = name;
process.StartInfo.Password = password;
process.StartInfo.FileName = fileName;
process.StartInfo.UseShellExecute = false;
process.Start();
The user whose credentials I provide is in administrator group - the application successfully runs if started manually.
Is this accomplished in a different way?
Thank you!
How are you checking for applications which are running? In Windows Vista and newer, there is separation between the services and desktops. This may mean that you cannot access the desired information and the service is bombing out for that reason. There is an 'allow interaction with desktop' or similar check box in the service dialog. You might want to try enabling that.