I am unable to supply password to runas from commandline
I have tried the following
cmd /C echo my_admin_password | runas /user:DOMAIN\my_admin_login c:\test.bat
and
echo my_admin_password | runas /user:DOMAIN\my_admin_login c:\test.bat
And the error I get is
Attempting to start c:\test.bat as user "DOMAIN\my_admin_login" ...
RUNAS ERROR: Unable to run - c:\test.bat
1326: Logon failure: unknown user name or bad password.
How do I fix this?
Take a look at this link: runas utility
It's a runas free utility that have the follwing features:
It accepts password as a command line parameter so that it can be used in batch files.
It can bind started process to the interactive user Desktop so it can be used to start interactive processes from various services such as 24x7 Scheduler, 24x7 Event Server and other.
Note: Professional version of RunAs also supports encryption of the entire command line, which administrators can use to give regular users access to certain programs requiring admin-level privileges. Users don't need to know the administrator's password and cannot use it to run anything else… simple, yet very efficient solution for this common problem.
Also you can try pass the password as input for the process using subprocess.Popen.communicate or even subprocess.Popen.stdin.write.
Other interesting links:
How to pass a password to a process?
Command-line runas with password
PsExec
Related
I am a QA automation engineer and in the web app I test there's a feature that creates Active Directory users.
My tools are - Selenium (Java), RemoteWebDriver, Selenium Grid (Docker)
I was trying to find ways to validate this process and came to a stop - this field (AD) is new
to me and I need to find a way to make sure the user was created and can be logged into in the
network.
I was trying to find a way to do this and came up with 2 options, where the first one is the least
preferred way:
Make a request (API? 3rd side tool?) to get the relevant user(s).
The issue:
A user created and registered in the AD doesn't necessarily mean that the client can log into it (at least by the way I understood how AD works), and so it loses the most important consequence of the feature.
Use a VM, get the AD user information (username + password: possible) and try to log into the VM using those details.
The issue:
I haven't came across a tool that does it, the closest thing is Robot class or WinAppDriver.
WinAppDriver seems like the best solution as of now although I don't know how to make the login process work since it's the process starts before the desktop is open and I don't know how to locate the username and password field, so I figured using Robot class seems like the simplest solution, if it works on a VM that is, which as of now doesn't seem like it does.
So, before advancing on learning how to use WinAppDriver with my current automation, I'd like and appreciate your opinions about the matter or if you have simpler solutions.
Thank you very much for reading!
• We can check whether a user is created successfully or not and if that user can log in to the AD domain or not by executing a script as below. It is a powershell script that auto logs in through remote desktop protocol in the other domain joined VM from an Azure domain joined VM that checks whether the recently created user can login or not.
Powershell script : -
cmdkey /list | ForEach-Object{if($_ -like "*target=TERMSRV/*"){cmdkey /del:($_ -replace " ","" -replace "Target:","")}}
echo "Connecting to 192.168.1.100"
$Server="192.168.1.100"
$User="Administrator"
$Password="AdminPassword"
cmdkey /generic:TERMSRV/$Server /user:$User /pass:$Password
mstsc /v:$Server
• In the above script, replace the ‘$user’ value by the user principal name of the newly created user, i.e., ‘$User=”testdemo#example.com”’ and the ‘$Password’ value by the password set for that user. Also, ensure that you replace and enter the correct IP address of the domain controller/AD server. Also, ensure that before executing the above powershell script, execute the below commands in an elevated (administrator privileges) powershell console.
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Lastly, please ensure that while creating the user, the option ‘User must change password at next logon’, ‘Account is Disabled’, ‘Password never expires’ and ‘User cannot change password’ are unchecked and not selected.
• Also, you can use the below command line script for logging in to the domain joined Azure VM through RDP protocol. In the below command, replace the ‘username’ and ‘password’ with the username and password of the user created recently to log in to the Azure VM with this command line script. Also, replace the ‘TERMSRC’ with the hostname of the server system or the domain joined VM where the specified UNC path is located and replace the ‘some_unc_path’ with the actual path UNC path of the shared directory folder. Please execute the below command through elevated (administrator privileges) command prompt.
Command script: -
c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -nolog -command cmdkey /generic:TERMSRC/some_unc_path /user:username /pass:pa$$word; mstsc /v:some_unc_path
We have a subversion system up and runnuing at a central server. At the moment I can access that svn repository over a network share. As this is not good practice I will close that network share and will access my svn only over the "svn" command (I use TortoiseSVN Client for that).
As new Projects will be started in the future, me and my fellow colleagues must be able to create new repositorys on that server. For the creation you would need write-rights on that server directory, but I don't want that. Also I don't want to run to our Admin every time (all this is ok with our admin and I have his support).
First, my idea: Trigger a process on the server which will create the Repository. But here I am stuck with how to trigger a process if I am not the server admin (tried a WMI VB Script) So here would be the question, how to elevate the rights of the caller during the script execution? I do not want to store the admin password in plain text in a script or batch file.
Second, can this be done in some other forms? how do you guys create your repositorys?
Afaik there is no way of auto-elevation in CMD. The only way to do that I can think of is to use the windows schduler. You could write a bat file that executes all the commands you need. Then create a task with the scheduler and tell it to run the bat file. During the creation leave the "Triggers" section empty, check the "run with highest privileges" box, enter a user account that has the rights you need and enter the password. Then go to "Settings" and check the "Allow task to be run on demand" box.
Now the second part (OPTIONAL). Adept the user policy on the server so that the users you want to be able to execute the process are allowed to trigger scheduled tasks on the server. You could also enter the users PCs as "trusted" on your server. There are several ways to achieve that. However, afterwards the users must be able to execute scheduled tasks on the server.
Now you are done! If you've done the optional section your users can trigger the task with SCHTASKS /RUN /S <RemoteServerName> /TN "<task name>". No stored credentials needed and the script runs with elevetad rights.
If you didn't use SCHTASKS /RUN /S <RemoteServerName> /U username /P password /TN "<task name>".
I've created a procedure on VBA (Excel) that restarts services on remote servers calling the command prompt and executing the "runas" command. I need to enter the command on the servers as administrator. So far it works fine but I don't want to have to type my password for each I want to run the command in. I know how I can automate the task using VBA and the Excel. What I don't know is how could I input my password on the command prompt using VBA?
Can anybody help me?
Thanks.
I've had all sorts of issues trying to convince runas to let me specify passwords from a program.
In the end, I tossed it and downloaded psexec from the Microsoft Windows Sysinternals site, which has other good stuff as well.
While many see this as a tool running remote programs, it can also be used quite happily to run local stuff under a different user name while allowing you to specify the password as a command-line argument, such as:
psexec -d -u USER -p PWD -w WORKDIR EXECUTABLE
You should be able to create a textbox control in VBA with the input mask set to password, this will allow you to enter the password in a non-viewable fashion.
Then you can just construct the psexec command and execute it from VBA, without having to worry about injecting the password into the process running runas.
I've written a script to search/download/install Windows Updates on a machine using the Microsoft.Update.Session COM Object. When run locally it works just fine, however when running through a remote session or through Invoke-Command I receive an access denied (0x80070005) error on Microsoft.Update.Session.CreateUpdateDownloader()
I receive the same error if I attempt to create a Downloader object directly, code to reproduce the issue:
$oUpdateDownloader = new-object -com "Microsoft.Update.Downloader"
I am an administrator on the remote machine, and passing credentials (for myself explicitly or any other admin account) to the machine does not seem to change anything.
I've seen this error posted a number of times but there does not seem to be any information on solving the problem...
Any ideas?
When you are in a remote PowerShell session your logon session on this remote computer is flagged as a "network" logon (Logon Type: 3).
For some obscure (security? sell SCCM?) reason, part of the Windows Update Agent COM APIs are restricted to only be usable by locally logged on Administrators.
Using PsExec and Scheduled Tasks have been suggested as workarounds.
IMO, the most seamless (and still secureable) solution is to facilitate the RunAs-style "Local Virtual Account" feature of PowerShell Session Configurations / JEA.
Usually, JEA is used to "restrict" what a user can do on a remote computer PowerShell-wise, but we are (ab-)using it here to gain full access as if we were a locally logged on Administrator.
(1.) Create a new unrestricted (and persistent!) session configuration on ComputerB (remote server):
New-PSSessionConfigurationFile -RunAsVirtualAccount -Path .\VirtualAccount.pssc
# Note this will restart the WinRM service:
Register-PSSessionConfiguration -Name 'VirtualAccount' [-ShowSecurityDescriptorUI] -Path .\VirtualAccount.pssc -Force
# Check the Permission property:
Get-PSSessionConfiguration -Name 'VirtualAccount'
# Those users will have full unrestricted access to the system!
(2.) From ComputerA (local client) connect to our unrestricted session configuration on ComputerB:
New-PSSession -ComputerName 'ComputerB' -ConfigurationName 'VirtualAccount' | Enter-PSSession
[ComputerB]: new-object -com "Microsoft.Update.Downloader" # Yay!
This is a known issue. It appears that there is a bug with the actual COM object itself, as this issue occurs when using VBScript, PowerShell, and even C#. There is a good article that discusses managing Windows Update with PowerShell that can be found here.
The workaround is to set up a scheduled task on the computer and you can invoke that task however you see fit.
Use PsExec (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) to remotely execute PowerShell with a script file:
psexec -s \\remote-server-name C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe \\server\script.ps1
I used the script detailed at http://www.ehow.com/how_8724332_use-powershell-run-windows-updates.html, and I can remotely execute it using psexec to download and install updates.
the windows update code isn't callable form a remote machine. there are a few workarounds out on the web, including using psexec and a script (powershell or vbscript).
I used WUInstall myself and BoeProx has documented a few alternatives and has started a project PoshPAIG. I moved jobs before using this so don't know if it works.
The other solution is to change Windows registry setting using PowerShell and optionally restart wuauserv for the changes to take effect.
For example in Windows Server 2008R2 AutoUpdate settings can be found at:
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update
First of all, sorry for my poor english. I would try to explain my problem.
I am using psexec within a script to restart a cluster as follows:
script1 in node1: perform a lot of tasks (shutdown services, check status, etc..) in the node1 and after completing all task launch with psexec the script2 in node2 (psexec-d \ \ node2 script2)
script2 in node2: perform a lot of tasks and launches script3 in node1. Here is, when i recived an "access denied" in psexec when I try to run the script3 in node1. (psexec-d \ \ nodo1 script3)
I launch the script with an user that belongs to the group administrators
For security reasons I can not pass username and password, because it is not safe to leave the credentials in a .bat file.
Additional info:
I´m running the script in W2k3 server
I tried a net use and its all ok
I tried a psexec with -u username and -p username and its all ok
I tried to exec psexec with this syntax: psexec .exe -d \node1 cmd.exe "script3.bat" and returns the same error.
Thks a lot
Best Regards
Finally I have decided to use a watchdog process in the second script, so the script will be launched by this process instead of being launched by psexec.
Thanks a lot for your help and your time devoted to help me.
Best regards
It may be related with an issue that one gets from too many linked server hops using integrated authentication - a double-hop Kerberos problem.
Since Integrated Windows Authentication covers two separate authentication mechanisms:
NTLM v2 -and-
Kerberos,
if you are using Kerberos, since the user's password is never passed to the IIS server, the only way the token on the IIS server is going to hop to another machine on the network is via Kerberos Delegation. If that isn't available or allowed, then the hop won't happen (which is what it sounds like is happening).
Given that you are using default credentials, and if the current security context is an impersonation token that can not delegate, then the credentials you supply will not hop to
the other machine.
Since Windows integrated authentication creates an impersonation token, this is very likely to be the case.
Sources:
psexec problem
Windows authentification thread (forum)
Can you make the call to script2 wait for completion, rather than have script2 call back to node1:
script1 in node1: perform a lot of
tasks (shutdown services, check
status, etc..) in the node1 and after
completing all task launch with psexec
the script2 in node2 (psexec \ \ node2
script2)
script2 in node2: perform a lot of
tasks.
script1 in node1: launches script3.