I'm writing a PowerShell script that, every few months, a third-party app will automatically call to do the following among other things:
Use [System.Web.Security.Membership]::GeneratePassword() to randomly-generate a password then use that password with Export-PfxCertificate and OpenSSL's passin.
Use a static password to authenticate via COM API to a third-party system that doesn't support API keys or anything.
What's the best way to do this securely?
As far as I'm aware, there's nothing wrong with #1 but everything I've read online regarding #2 advises:
Requiring that the user supply the credentials when the script is executed but that defeats the point of automating the process.
Using PSCredential but that's not possible here.
Using an encrypted key / password file but, as far as I'm aware, there isn't really any point in that as you're effectively still storing the password alongside the script file - if the server gets compromised then they could either read the password from the script or decrypt the password in the keyfile. Unless you use a custom encryption key which isn't stored on the server but, again, that defeats the automation.
For # 2, there are lots of resources/articles covering securing credentials when using PowerShell.
Starting with Windows Credential Manager ...
Install-Module -Name "CredentialManager"
Get-Command -Module "CredentialManager"
$Target = "YourServerName"
$UserName = "Administrator"
$Secure = Read-host -AsSecureString
New-StoredCredential -Target $Target -UserName $UserName -SecurePassword $Secure -Persist LocalMachine -Type Generic
Get-StoredCredential -Target "servername" –AsCredentialObject
Remove-StoredCredential -Target "servername"
... then looking at other methods. See this Q&A for additional approaches. Passwords in powershell logging
As for...
if the server gets compromised
... if a nefarious one is this far into your system, to be able to do this, then this kicks in: Ten Immutable Laws Of Security (Version 2.0)
Have you checked out Azure Key Vault or something similar?
If you go that route, take a look at the Az module (Windows PowerShell 5.1 or PowerShell Core). The Az.KeyVault sub module has lots of functions for working with the vault.
EDIT: To address security, we don't know much about the system. However, these are the things I would look into:
Least privilege: make sure that this service account can only do what it is supposed to do.
Time of use restrictions: if the schedule that this should execute is known, configure the system to only allow the account to successfully authenticate during that time and even JIT permissions, if possible.
Location based restrictions: Only allow the account to authenticate from the location. Best result, being able to restrict to the specific server(s) from which it should be executed (could require a dedicated egress IP(s)).
Auditing: monitor and alert for changes to these settings.
If these are in place, your exposure is that the actual system is compromised and an attacker could make unintended changes within the allowed scope during the permitted window. It is a fairly low risk, at that point, which is much better than not implementing such controls.
These could be implemented potentially within the application, or through a 3rd party trusted authentication source if it could be integrated with the application.
Related
I need to query some WMI values using PowerShell from Windows 10 devices. The script is executed in the context of a non-admin user by some software distribution tooling.
There is a local admin account, and for the current purpose (retrieving information before wiping the system) it wouldn't be a problem to put the password in the script. As automation is a hard requirement, there is no way to deal with UAC windows or the user to enter some credentials.
Is there any way to get
$sess = New-CimSession -Credential $admincred
to work without running into Access is denied, because it isn't run in an elevated context? Can I somehow self-elevate it by just having the admin credentials?
[Edit]
The comments asked to provide more concrete information:
I want to onboard many unmanaged (i.e. no software distribution tool, no domain join) Windows 10 devices to Windows Autopilot.
The devices are not at a specific site.
The device vendor can't provide the information.
The users don't have administrative privileges
The users don't know the local admin password (I do)
Exposing the local admin password is less of a problem than the missing tech knowledge of the users (the password is considered legacy)
The firewall is preventing incoming traffic (no RDP, WinRM)
Code (Source):
$devDetail = (Get-CimInstance -CimSession $session -Namespace root/cimv2/mdm/dmmap -Class MDM_DevDetail_Ext01 -Filter "InstanceID='Ext' AND ParentID='./DevDetail'")
It is too time consuming to get the information using manual remote sessions with a tool like Teamviewer. Getting the users to download a tool from the intranet and running it would be a way to go. So I created a standalone application that builds and runs a customized PowerShell script. What won't work is getting it to run in an elevated session. I always end up with Access denied.
Can I somehow self-elevate it by just having the admin credentials?
No you cannot. UAC is designed to prevent exactly what you are trying to do. Related Q&A:
elevate without prompt - verb runas start-process
UAC Getting in the Way of EXE Install Powershell
Powershell provide credentials for RunAs
There may be many workarounds, but they all will have in common that you have to go to your machines (locally or remotely) at least once, gain administrative privileges and prepare something, e. g.:
A scheduled task that runs under your local administrator account or under SYSTEM and triggers the execution of your script
Disabling UAC (temporarily) (not recommended either way)
Installing any remote management software, services or accounts (with extra run as background job privilege)
I am working on making some scripts to make my job a little bit easier.
One of the things i need is too download some files to use. I first used powershell with the command Invoke-WebRequest.
It is working really well, however it dont run on windows 7 computeres, as they have powershell 2. As i have about as many windows 7 pc's as win 10 i need to find another way.
I found that Start-BitsTransfer is a good way that should work on most computeres. My problem now is, that when using the script via my remote support session it runs the script on the local service account, and then BitsTransfer wont run and gives me an error. (0x800704DD)
Is there a way to get around that problem, or any command that can be used on both win 7 and 10 and run from the local service account?
You should update PowerShell as gms0ulman states, but if you are not the person who is in charge of this decision, you have to take other steps.
This error code...
0x800704DD
The error message ERROR_NOT_LOGGED_ON, occurs because the System Event Notification Service (SENS) is not receiving user logon notifications. BITS (version 2.0 and up) depends on logon notifications from Service Control Manager, which in turn depends on the SENS service. Ensure that the SENS service is started and running correctly.
By default, BITS runs under the LocalSystem account. To modify, stop or restart BITS, you must be logged on as an administrator. In your situation, when you log on a regular account and start the PS in elevated privilege, the BITS doesn’t run under regular user account. To resolve it, you may need to configure the log on user for BITS. Please visit the following link to configure how a service is started.
Configure How a Service is Started
Services are often run with default settings — for example, a service
may be disabled automatically at startup. However, you can use the
Services snap-in to change the default settings for a service. This is
useful if you are troubleshooting service failures or if you need to
change the security account under which a service runs. Membership in
Account Operators or Domain Admins, Enterprise Admins, or equivalent,
is the minimum required to complete this procedure. Review the details
in "Additional considerations" in this topic.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc755249(v=ws.10)
I also agree that you should not continue supporting PowerShell 2.0. Ideally, ditch Windows 7 (it's way too old now), if you can't do that, upgrade PowerShell, if you can't do that, find a new job, if you can't do that, then I guess bring on the workarounds!
postanote's answer covers the BITS angle.
The other thing you can do is just use the .Net framework's underlying libraries, which is exactly what Invoke-RestMethod and Invoke-WebRequest do (those cmdlets were introduced in PowerShell 3.0, but the guts of them were around much longer).
try {
$wc = New-Object -TypeName System.Net.WebClient
$wc.DownloadFile($url, $path)
finally {
$wc.Dispose()
}
Most people don't bother disposing IDisposable objects in PowerShell so you'll see a lot of shorthand around like this:
(New-Object Net.WebClient).DownloadFile($url, $path)
Which is probably fine if your script's process isn't going to be around for a while, but it's good to keep in mind in case you incorporate this into something of a larger scale.
I've been having issues with people modifying powershell scripts and causing mayhem. Is there a one liner that I can insert into a current script to require a password that I set in order to modify the script? I still need everyone to be able to run it.
The easiest and most straightforward way is to put the scripts somewhere that the problem users don't have write access to. There's nothing you can do in the language itself to prevent a user from modifying a file they have write access to.
If you can't do this for some reason (they are admins and have too much access), then you can do a few other things.
Signing
Apply a digital signature to your scripts.
For this to work, you need to be able to enforce an execution policy of AllSigned (or RemoteSigned if these scripts are executed directly off of a share). You might do this with Group Policy.
You also need to control access to the signing certificate and ensure that it's the only one that's trusted.
Note that these users can still copy the script locally, make modifications, run powershell.exe -ExecutionPolicy Bypass and still run their modified script.
The difference is that this is their copy and doesn't break it for anyone else. And if they overwrite the central script without signing it or signing it with an untrusted certificate then everyone will notice.
If the users are privileged enough they be able to override more of this.
Central Deployment
Put the scripts in a custom local repository and use the package management functions Find-Script / Install-Script so everyone is referring to the same ones, and have a well-thought out deployment process. This can be combined with signing.
But...
Ultimately if these users are privileged and they are acting in bad faith, this is a personnel problem and can't effectively be solved with technology. In that case, The Workplace may be able to help.
I am required to utilize an old version of ClearQuest 7, and the only APIs that are enabled in our installation are for VBA (Excel) and RatlPERL. (The REST API isn't an option for us - although it suffers the same cleartext credential problem.)
I've written a ratlperl script that executes queries into the defect database, and produces csv output. Note that ratlperl requires cleartext user credentials for authentication.
ratlperl query.cqpl -u %userid% -p %password% -q "%query%" -c %outfile%
That script is called from a Windows Batch file. When run from the Windows command line with no parameters, the batch file requests user credentials, but they can also be provided as parameters.
query.bat %userid% %password%
I trigger daily queries, with the user credentials passed as parameters for the batch file.
This all works well, but I'd rather not store the cleartext password in this way. The registry would be one possibility, but anyone with access to the machine would have access to those credentials.
How can I store these credentials in a somewhat secure way?
There's two things to watch out for. One is having your process list "show up" the auth credentials.
Particularly on Unix - if you run ps it'll show you the arguments, which might include a username and password. The way of handling this is mostly 'read from a file, not the arg list'. On Unix, you can also amend $0 to change how you show in ps (but that doesn't help command history, and it's also not perfect as there'll be a short period before it's applied).
The other is - storing the data at rest.
This is a bit more difficult. Pretty fundamentally, there aren't many solution that let your script access the credentials that wouldn't allow a malicious user to do so.
After all, by the simple expedient of inserting a print $password into your script... they bypass pretty much any control you could put on it. Especially if they have admin access on your box, at which point... there's really nothing you can do.
Solutions I'd offer though:
Create a file with (plaintext) username and password. Set minimum permissions on it. Run the script as a user that has privileges, but don't let anyone else access that user account.
That way other people can 'see' your script (and may need to to run it) but can't copy it/hack it/run it themselves.
I would suggest sudo for this on Unix. For Windows, I'm not sure how much granularity you have over RunAs - that's worth a look, or alternatively have a scheduled task that runs as your service account, and picks up 'request files' for processing that can be generated by anyone.
As the level of security doesn't need to be so high, perhaps consider to create a simple exe? The password could possibly be read out of the memory somehow, but I guess this way creates a big enough barrier.
Or something like this could be helpful?
http://www.battoexeconverter.com/
HTH
I am trying to run a powershell invoke-command on a vmware image I have:
invoke-command -computer [vmware host] -scriptBlock { commands }
This does not work because my client where I run the command is on a domain and the vm image is in a workgroup (mixed domains)
After some research, I have added the vmware host to trusted hosts (Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value [vmware host]) and if I supply credentials (administrator/password) the command works.
My question is: Is there a way to make it work without explicitly supplying the credentials e.g. either opening up the vmware host to all kinds of access or then somehow saving the credentials permanently on my client computer so that I don't need to supply them in a call using the "invoke-command -credential argument". I don't have the flexibility of adding the "-credential" argument as this code is maintained by other team.
I know I could add trust between the domains (to use kerberos) but that option is not available to me.
This is about all you can do. Use PSDefaultParameters.
http://technet.microsoft.com/en-us/library/hh847819.aspx
$PSDefaultParameterValues = #{
"Enter-PSSession:Credential" = $cred
"Invoke-Command:Credential" = $cred
}
This is possible using certificate-based authentication. You would authenticate with a client certificate that gets mapped to an account.
I admit I have not gotten around to it. I'd love to do this, but we only have about 9 Windows servers in the DMZ and it's just not worth the effort for me right now.
These links look promising:
How to use WSMan config provider for certificate authentication
WinRM with non-domain joined machine using Certs
If you do manage to get this working, I would very much like to hear about your experience.