I'm trying to edit the registry from a PowerShell script which will run on startup (through the task scheduler). Since the domain account I'm using does not have privileges I'm getting an error. Can I pass through credentials for a local admin account within the script?
Note: I need a solution that won't raise a user prompt for username/password. The script is supposed to be automated without need for user input.
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
I am configuring TWS job in one of our application windows server but when the job triggered it is throwing the below exception. I am using domain user to execute the job.
AWSBDW079E Jobman could not run the job because the system call used to launch the job failed: Jobmon was unable to retrieve user information.
Do I need any special permissions for the user to run the job.
Any help?
On Windows, TWS needs userid and password in order to impersonate the user.
You have to specify the USER object with the appropriate Workstation name, userid and password.
Using Dynamic Agents there are also other options using Executable job types, e.g. you can store the password locally on the agent with the parm utility.
I have figured out the issue. The issue was with the user permissions. The user which is used to run the job on the workstation must have the below permissions.
Allow log on locally
Log on as a batch job
I am writing a PowerShell script to archive compressed C2 Audit files to a file share. What is possibly the last problem I am having is giving the .Net compression routine the privilege to manipulate the files. During development, I could flaunt my account's admin role to propagate Full Access privileges to the files in the DATA directory. However, the script is to run from a PowerShell step in an Agent job, and I want to automate the ACL change as well.
For an added level of difficulty, I am doing this under SQL Server 2012, so I am stuck with PowerShell 2.0. I am using .Net 4.5 compression routines via a process of loading $RunActivationConfigPath with a temporary config file. I was not able to find a way to change that config file to promote the admin role, though.
This is a segment of a script by Benjamin Armstrong that checks if the connection is using Administrator privileges.
# Get the ID and security principal of the current user account
$runtimeWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$runtimeWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($runtimeWindowsID);
# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;
Write-Output ("Running under "+$runtimeWindowsID.Name)
Write-Output ("PS Version "+$PSVersionTable.PSVersion.Major)
# Check to see if we are currently running as an administrator
if ($runtimeWindowsPrincipal.IsInRole($adminRole) -eq $true) {
Write-Output "We are strong."
} else {
Write-Output "We are not strong."
}
Running the script as an Agent Job step produces:
Running under NT Service\SQLSERVERAGENT
PS Version 2
We are not strong.
Running the script from sqlps in Admin mode produces:
Running under DOMAIN\myusername
PS Version 2
We are strong.
All the ways I've seen to elevate a script involve using a script file. For example, creating a new process and executing it with RunAs as the Verb. I want to avoid script files and have everything in the step. I like the added security (however small) of needing SSMS privileges to view the code.
So, here are my questions:
1) Is there a way to elevate commands in a script block?
2) Is there a way to have the PowerShell step in an Agent Job run in Admin mode?
Extra credit question:
3) If I do need to add the Agent service account to a Windows User Group, which of the two dozen groups would give that account the minimum privileges needed to alter an ACL for a file, then eventually delete it?
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'm tryning to start a .bat file as the last step in OnAfterInstall in the context of an other user. I'm doing this by using the Process.Start overload with user name, domain and password as input. It works fine if I do not check the 'Everyone' in the installation. If i have the 'Everyone' selected I get access denied, with the same user (administrator). If I run the installment using the .start method with just the proccess name it work fine.
To test this I made a Windows froms application that start the proccess the same way after I install using 'Everyone', and it works fine.
Does anyone know why I can't access the file in OnAfterInstall with 'Everyone' selected, using an other user context?
Most likely when you check everyone you are telling the install program it doesn't need elevate permissions so it doesn't ask for them. Even when you run as an admin in windows vista or 7 your process token is that of a user until the UAC elevates you. There are a set of polices you need to be able to call createprocessasuser which is what is happening underneath. Give all polices related to the above api to everyone and then see if it works.