I have an application developed in vb.net which needs administrator privileges. I have set level = "requireAdministrator" in the application manifest. My client wants this application to be run by a local user due to some restrictions in their organization. So I created another ‘Launcher’ application which will actually save an administrator credentials in an encrypted format and will use the saved credentials to run the ‘Original’ application.
Everything works fine if I’m using the ‘Administrator’ account (Built-in account). But if I’m using the credentials of the manually created administrator account – the process.start () line is throwing an error “The requested operation requires elevation”
I really couldn’t identify the difference between the built-in administrator and manually created administrator account. I confirmed that both the users (built-in and manually created) are members of Administrators and HomeUsers. I tried all possibilities by creating different users with different user groups and even with different OS (windows 7 and Windows 10 – both 32 and 64 bit versions) – but, all are working in the same manner as explained above. Is there anything that I have to change in my code?
Dim psi As New System.Diagnostics.ProcessStartInfo()
psi.FileName = (AppToStart)
psi.RedirectStandardError = True
psi.RedirectStandardOutput = True
psi.CreateNoWindow = True
psi.UseShellExecute = False
psi.UserName = TbUser.Text
psi.Password = ConvertToSecureString(TbPass.Text)
psi.Domain = ""
Dim p As Process = Process.Start(psi)
Additional Info: Here I'm running this 'Launcher' application as a standard user (not administrator) and the application works well and it really elevates the privileges if
TbUser.Text = “Administrator” and
TbPass.Text = 123 (Administrator password).
But this is not elevating privileges if
TbUser.Text = “Adminuser” (which is also an administrator belongs to the same ‘Administrators’ group) and
TbPass.Text = 321 (password for Adminuser).
Unfortunately you can't do this and here is why...
Basically verb isn't recognized when psi.UseShellExecute = False, this would need to be psi.UseShellExecute = True. You are doing this while trying to use runas as an elevated permission.
In your situation, you would not use the verb = runas, make sure the application has already been started with the correct permissions.
Please see more here about elevating privileges, Hans Passant say's it best...
Related
I have an application's shortcut on the desktop; the application works different according to the user permissions. What I want is to call the shortcut from the less privilegiated user and automatically access to the admin account hidding the admin's password to the current user. In this way, the normal user will have access to more options in the application without knowing another user's account data.
I have tried creating bat files, but the password can be seen easily. I am looking the way to do it with VB but I'm not sure if this is the best option. This software does what I want, the thing is that isn't free.
https://4sysops.com/archives/run-a-program-with-administrator-rights-runasspc-cpau-and-steel-run-as-compared/
http://www.robotronic.de/runasspcEn.html
Thanks for the help.
#Create a Desktop Shortcut with Windows PowerShell
If(!$ShortcutFileName)
{
$ShortcutFileName = (Get-Item $TargetFile).Basename
}
$ShortcutFile = "$env:Public\Desktop\$ShortcutFileName.lnk"
$WScriptShell = New-Object -ComObject WScript.Shell
$Shortcut = $WScriptShell.CreateShortcut($ShortcutFile)
#Run as different user, saves the password
$a="runas.exe /savecred /user:$RunAsUser ""$TargetFile"""
$Shortcut.TargetPath = "runas.exe"
$Shortcut.Arguments = "/savecred /user:$RunAsUser ""$TargetFile"""
$Shortcut.IconLocation = $TargetFile
$Shortcut.Save()
You can download detail SQL script from how to create a shortcut to run an application as a different user(PowerShell)
I am trying to execute a batch file using the Process class. This code is in the middle of a larger section of code where I am using LogonUser() and WindowsIdentity.Impersonate() to impersonate the local PC admin account.
I was attempting to run a batch file within a Process, without adding credentials in ProcessStartInfo, but doing it that way caused the batch file to fail silently - no errors were raised, and expected output from the batch file never was returned (I am reading stderr and stdout asynchronously, fwiw).
I then added the credentials to ProcessStartInfo, but now I get an "Access is denied" error if I do not first call WindowsImpersonationContext.Undo(), and an "Logon failure: unknown username or bad password" error if I do call .Undo() before Process.Start(). I have triple-checked that the username/password/domain is correct, for multiple accounts.
If my code has no LogonUser() or WindowsIdentity.Impersonate() calls (and no credentials in ProcessStartInfo), then I don't have a problem with the batch file executing and output from batch file being captured.
I am able to run the batch file from the desktop successfully, either as the local admin or an arbitrary local user account. I can see its permissions show that it should be readable/executable from the accounts I am trying to run it. This is really quite the stumper; any help is appreciated.
The problem was that I needed to redirect all 3 streams; I was only redirecting 2 (out, err, not in). That basically fixed things.
Are you looking for something like this?
Process proc = new Process();
proc.StartInfo.FileName = #"C:\WINNT\notepad.exe";
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.CreateNoWindow = true;
proc.StartInfo.Domain = "mydomain.com"; // Domain of IIS Computer
proc.StartInfo.UserName = "kaung"; //Administrator for that computer
System.Security.SecureString password = new System.Security.SecureString();
password.AppendChar('m'); //Password
password.AppendChar('y');
password.AppendChar('p');
password.AppendChar('a');
password.AppendChar('s');
password.AppendChar('s');
password.AppendChar('w');
password.AppendChar('o');
proc.StartInfo.Password = password;
proc.Start();
I'm writing a VBscript that I would like to alter the anyonymous authentication configuration for a specific site on my web server. However, I'm unsure of how this is done in the commit path. Currently, I am able to change the setting on a global scale, but I only want to target one particular site folder. My best guess was to simply include the site path at the end of MACHINE/WEBROOT/APPHOST.
'CHANGE ANONYMOUS AUTHENTICATION GLOBALLY (working code):
Set adminManager = CreateObject("Microsoft.ApplicationHost.WritableAdminManager")
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST")
anonymousAuthenticationSection.Properties.Item("enabled").Value = True
anonymousAuthenticationSection.Properties.Item("userName").Value = "myUser"
anonymousAuthenticationSection.Properties.Item("password").Value = "myPass"
adminManager.CommitChanges()
'MY BEST GUESS AT TARGETING A SPECIFIC SITE (returns error 80070005):
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST/Sites/InsideFTL/Corp/redirects/netXposure")
The code that you have above should work, are you running it from an elevated command prompt?
You could also try to make sure that it is committing to ApplicationHost.config to make sure it is not a locking issue by setting CommitPath, and make sure that the identity under you are running the script has write access to it.
'CHANGE ANONYMOUS AUTHENTICATION For Default Web Site:
Set adminManager = CreateObject("Microsoft.ApplicationHost.WritableAdminManager")
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST"
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST/Default Web Site")
anonymousAuthenticationSection.Properties.Item("enabled").Value = True
anonymousAuthenticationSection.Properties.Item("userName").Value = "myUser"
anonymousAuthenticationSection.Properties.Item("password").Value = "myPass"
adminManager.CommitChanges()
I'm trying to write an application that will allow a non-administrator user to create virtual directories in IIS6. I've tried numerous different ways of impersonating a administrative account but nothing seems to work to create the virtual directory.
Here's some of what I've tried:
dim sDirPath as string = "IIS://remotehost/W3svc/1/root"
Dim de As DirectoryEntry = New DirectoryEntry()
de.Path = sDirPath
de.AuthenticationType = AuthenticationTypes.Secure
de.Username = tbxUsername.Text
de.Password = tbxPassword.Text
''Fails here
virtualId = CType(de.Invoke("Create", "IIsWebVirtualDir", dirName), DirectoryEntry)
Using the AccountAlias class from here:
aa.BeginImpersonation()
Try
dim sDirPath as string = "IIS://remotehost/W3svc/1/root"
Dim de As DirectoryEntry = New DirectoryEntry()
de.Path = sDirPath
de.AuthenticationType = AuthenticationTypes.Secure
''Fails Here
virtualId = CType(de.Invoke("Create", "IIsWebVirtualDir", dirName), DirectoryEntry)
Finally
aa.EndImpersonation()
End Try
what is the correct way to impersonate another user in winforms application that will allow me to create the virtual directory WITHOUT the user that's running the application being an administrator on the web server? I know this can be done, IIS manager allows you to use "connect as" checkbox to do it.
It's been a long time since I hit this problem so I may be remembering a few things wrong. But IIRC ...
The root directory of IIS is protected by an ACL that requires administrative privs in order to create a new directory. A simple impersonation likely will not fix this issue because I believe under the hood you are combining both COM and either RPC or Local RPC. Impersonation across COM boundaries is tricky in native code and very tricky from managed code. It's very likley that you are running into an issue in this area with your impersonation trick.
It is possible though to lift the restriction on the web server and have normal users create root directories in IIS. I outlined the process to do so in the following blog post
http://blogs.msdn.com/jaredpar/archive/2005/02/04/367137.aspx
I am writing a launcher program, and when I go to start the process I get the "The directory name is invalid" error. Here is the code that is launching the process:
Const DEBUG_ROOT = _
"Z:\Kiosk_JC\KioskSignIn.root\KioskSignIn\KioskSignIn\KioskSignIn\bin\Debug"
Dim oKiosk As New System.Diagnostics.Process
oKiosk.StartInfo.UserName = oEnc.Decrypt(Username)
oKiosk.StartInfo.Password = oEnc.DecryptSecure(Password)
oKiosk.StartInfo.Domain = oEnc.Decrypt(Domain)
''// The AddBS function appends a '\' to the passed string if it is not present
oKiosk.StartInfo.WorkingDirectory = AddBS(DEBUG_ROOT)
oKiosk.StartInfo.FileName = "KioskSignIn.exe"
oKiosk.StartInfo.UseShellExecute = False
Dim proc As Process = Nothing
proc = System.Diagnostics.Process.Start(oKiosk.StartInfo)
I saw on another question here that I needed to set the WorkingDirectory (before I started searching I was getting the error). Even though I have this property set, I am still getting the error. Any thoughts?
More info
I should also note that my Z:\ is a on my network. I have a function that resolves a path to UNC. When I ran this function on DEBUG_ROOT, I get the same error.
I tried moving the application to c:\kiosk. Same result. I am logged in as the user I am impersonating, so I have access to all shares and files.
Here is the link, for some reason the URL formating wants to consume all the text after the link is designated:
Referred Post
Mapped drives are per-user. You are likely starting the process with a different user.
Sounds like the process can't see the Z: drive or doesn't have security access. What user context does the app run under? Perhaps the Z: drive is not available in that context.
I got the same error as you do. most likely the user you use to run the process does not have access to specified resource (exe file)
try to move your exe to some other location and/or give your user access rights to the file.