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.
Related
I have a simple .exe on a network share that merely creates a dummy file on a network share. The program works. I've wrapped it in a .bat file, a .ps1 file, and a .vbs file, and they all work. However, when I create a SCOM rule to invoke any of these beasts it does not run. Am I missing a management pack or building the rule wrong such that SCOM doesn't run my module? What's the secret to having SCOM run an external module? Thanks.
First, Does your SCOM Agent's RunAs account have permission to access the file?
Most folks deploy the SCOM agent and leave it running under a local account.
Second, if this is a custom authored rule, is your rule properly configured to run on the target system or is it running on the management server? ( what is your target? )
With the basics covered, I have a hunch that your SCOM rule is executing PowerShell based on your use of 'invoke'. If you run PowerShell remotely without enabling CredSSP then you wont be able to make an authenticated connection to the file share downstream.
This guy explains it better then I can: https://4sysops.com/archives/using-credssp-for-second-hop-powershell-remoting/
If this is not the issue can you paste in the actual action the rule is taking?
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 have a bunch of PowerShell scripts that call out to external programs to perform certain actions (no choice about this). I'm trying to find a way to allow users to connect to a constrained remote session using delegation to run these scripts (and the external binaries) as a privileged account, WITHOUT the user being able to execute the binaries with the privileged account.
I've found that if I constrain the endpoint using NoLanguage and RestrictedRemoteSession, or using a startup script to remove access to those parts of the system that it breaks the scripts because they're no longer able to execute the binaries.
Is there any possibility of making this work, or will I have to rewrite my existing scripts as DLL cmdlets which could then make the calls to the external binaries (or write just a proxy command in a DLL to make the calls)?
Create scheduled tasks without a trigger, configure them to run as a privileged user, and have your restricted users start them from the Task Scheduler.
You are looking for JEA or Just Enough Admin. It does exactly what you are trying to do with restricted endpoints.
http://blogs.technet.com/b/privatecloud/archive/2014/05/14/just-enough-administration-step-by-step.aspx
Start with the video. Jeffery Snover may give you the details needed to make your solution work as he explains step by step how JEA was built.
If i create a powershell runspace, either programatically with .NET or just by launching the powershell console; How secure are the scripts/commands that are run?
I'm not speaking about signing scripts, but the actually memory space that the scripts are run in.
I'm worried that if sensitive information is gathered as part of the script (a sql query into a salary database for example) that someone could hack this data out.
I know most people are thinking SecureString at this point, i know about SecureString.... I'm wanting to know specifically about the powershell runspace, not how to store strings securely inside a runspace (lets hope that last sentence didn't just answer my own question).
Specifically :
Are other applications/scripts/whatever able to peer into the runspace and see the commands i'm running?
Powershell script security works by controlling whether or not a script is "allowed" to run on your machine. If you have a machine running an execution policy of "AllSigned", that machine will require the Powershell script to be signed by a trusted certificate.
Scott Hanselman has a really good article on it here.
To my knowledge, your command history isn't permanently saved. You can do a "get-history" to see the commands you've entered in your current session, but it's not like linux/unix where "history" will contain all of the commands you've ever run on the system. As far as other applications being able to "peer into" or query your session, I have no idea.
I am DBA. I am trying to write bunch of scripts that I could execute from one central server. Ideal would be to send all the scripts from central server to say 50+ servers across multiple win domains (for databases management purposes).
The problem I am running into is - security. Seems like PowerShell Remoting is the way to go. But when I send a script to another server, I get 'not digitally signed' error.
I could 'self sign'. But that cert if only trusted on local machine. So that option is out.
Maybe Certificate Authority is a way to go. Or adding trusted hosts. I just have no clue on this one, so if you know any blog posts or how to do this - it would be big help.
Well, it's a security risk, but there's always the possibility of setting the execution policy to RemoteSigned, keeping a local repository on each server and calling those as needed via PS-Remoting. I don't like that idea one bit though.
If you are doing remote execution, you will need to sign your scripts. A detailed step by step can be found here. It even covers deploying the cert via GPO so that it's domain trusted.
I would use PowerShell remoting. This would allow you to run it as remote commands instead of remote scripts. If you catch the bottom of this SimpleTalk article, after "Persistent Sessions". It shows the option of executing a set of commands against each server instead of the script. This should prevent having to deal with the remote signed issue and provide a little more control.
The only thing to deal with on remote sessions is your credentials. I have not tried this on multiple domains but a few stand-alone servers.