Jump to content

Remote Script Signing Required


Guest Steve D.
 Share

Recommended Posts

Guest Steve D.

We are evaluating this tool and like it so far. Our production environment requires signing of remote scripts. This is not something we wish to change. How do I go about signing all the Windows password reset scripts? Where do I find them so I can open them with a PS editor and sign them?

I can view them under PowerShell Scripts in the Administration tab but it says they can't be edited there or I'd copy them out to my favorite PS editor, sign them and then paste the results back into that interface.

This can't be an uncommon need, yet I can find no reference to it.

Link to comment
Share on other sites

Hi Steve,

 

Thanks for your enquiry, but unfortunately we do not have anything native in the software to allow this - this is mainly because you are the first customer to ever request this.

You can find all the scripts in the folder c:\inetpub\passwordstate\setup\scripts. Once you have edited them, you need to go back into that screen in Passwordstate and chose the option to restore each of the scripts. 

The main issue with this is that if we ever make changes to these scripts, it will overwrite your changes. So if you could contact us via our support page, and provide us an example of what changes you need to make, we'll see if we can try and start supporting this natively in the application.

Thanks

Click Studios

Link to comment
Share on other sites

I'm surprised by this. We are a fairly open environment but with growing security concerns. We want to limit those who can remotely execute powershell scripts. We allow users to write scripts and run them on their local systems but anything that is psremote must be signed using a code signing certificate issued by our CA. These certificates are published to targeted systems to allow those administrators to execute scripts on them using psremote. If a user has rights, they can psremote into the server and execute commands one at a time but they can't execute commands or scripts using Invoke-command. If your going to run batch commands against large numbers of systems in our environment, your script must be reviewed and signed by one of the admins holding a code signing certificate.

There are code signing certificate holders for desktop systems. There are code signing certificate holders from various groups of servers. There are a couple of code signing certificate holders that are environment wide.
 

This is managed by putting these individuals certificates into the trusted publishers machine certificate store using group policy. There are several group policy objects that put different certificates in the various machine store based on system type and ownership group.

This ties into the powershell script execution policy "RemoteSigned" which is applied to all systems throughout the environment, also using group policy.

There isn't any code to share. Basically, you take your script and execute a command that uses your code signing certificate to sign the script. It adds a block of encrypted txt to the end of the script. Example:

# SIG # Begin signature block

# ....

# ....

# ....

# SIG # End signature block

 

Unless the machine has a matching certificate in it's trusted publisher's certificate store the script will not run.
 

Also, you can not create a single signature and use it over and over. Each scripts signature is calculated based on it's contents. If the script is altered in any way after being signed, it will not execute.

We also secure psremote using ssl certificates. All systems have SSL certificates issued to them and are configured to use SSL encrypted psremote sessions on port
5986.

Link to comment
Share on other sites

Hi Steve,

 

Thanks very much for the information. For all our Windows related Password Reset Scripts, we do not use psremote, but we do use Invoke-Command. So if we were able to provide a solution here, does Invoke-Command rule out the use of our scripts anyway?

 

Also, with our scripts, we do not reference them on the file system at all, except for when we wish to restore them into the database - and they are encrypted in the database with the standard 256bit AES Encryption.

Based on what you've said, it doesn't sound like we could actually provide a feature where we inject the signature block into scripts dynamically, as every script needs to be different. So the only option we can think of here is:

  • You would need to take a copy of the scripts in the folder c:\inetpub\passwordstate\setup\scripts and sign the ones you want (I'm assuming all)
  • On the screen Administration -> PowerShell Scripts, you would need to add new scripts for Resets and Validation, and paste the content of the singed scripts above
  • Then when you add new password record, you would need to select your own scripts, instead of the ones we automatically assign - we pre-select scripts based on the Account Type selected

Do you think this is a possibility at all Steve?

Regards

Click Studios

Link to comment
Share on other sites

Yes. This is doable. There are only 3 scripts that would need this. local administrators, services and tasks. I'll set this up and test it in our stage environment and test it.

The only way I could see for you to do this is to write into the code for passwordstate a way to sign these scripts using certificates in the administrators personal store. Create a Sign Me button, if you will. Many of the powershell editors i use have signing extensions that tie into the user's certificate store and allow the author the ability to select a certificate to sign the script currently being edited with. Once setup, its a one click operation. PowerGUI (before dell killed it) and Visual Studio Code which is my current editor of choice offer plug-ins that do this.

An option on the powershell scripts tab to sign selected scripts with a pop-up presenting you with available certs from your personal store to sign the selected script with. Only those scripts that run against Windows domain member systems would need to be signed. Those that deal with network devices or other os versions aren't affected by this.

Once in place, we'll have to come back and resign these scripts each time we update the product, then go through all the autoupdate password lists and reassign the correct script again. Correct?

Link to comment
Share on other sites

Hi Steve,

 

Thanks again for the information, and for the suggestions - we can start looking into these. We're not sure if it's possible to showing available certs in IIS like this, but we'll look into it - I'm guessing it would require some level of authentication to query this, and the NETWORK SERVICE account used on Application Pools probably won't have access.

 

If you're using a clone of our scripts, which you've signed yourself, then our upgrades will not touch these - so you resets and validations should continue to work fine, as long as you have selected your own scripts on each of the Password record screens.

Regards

Click Studios

Link to comment
Share on other sites

Sorry, I may have been a little vague there. It was 3am for me while we were corresponding...

When I say the administrators personal certificate store, i mean the user who is running the passwordstate administrative interface, i.e. the passwordstate administrator who has rights to see and manipulate the scripts. it's their credentials that would be used to access their certificate store, not the account the services run under. They have full rights to their certificate store and that is where the code signing certificate that is needed is stored.

 

Thanks for your help!!

Link to comment
Share on other sites

3am - what are you doing :)

 

Sure we understand - but we would need to code this authentication to the personal certificate store though, as IIS will use the account associate with the Passwordstate Application Pool in IIS - but we should be able to do some sort of impersonation here.

Regards

Click Studios

Link to comment
Share on other sites

  • 2 years later...

Hello Rathinger,

 

Upon further investigation with Steve a while back, this feature by Microsoft for signing scripts with certificates is only relevant if you are executing the script off of the file system - we do not do this, instead we read from the database and execute in memory.

 

So we tested this against a machine that had “set-executionpolicy allsigned” set, with Invoke-Command, and it executed fine without signing the script. If you want to replicate this behaviour yourself manually, you can try this:

  • Run “set-executionpolicy allsigned” on your machine
  • Sign a PowerShell script as appropriate with your code signing certificate
  • Open the script off of the file system in PowerShell ISE, and execute – it executes fine as it’s signed
  • Make a small change to the script, save it, but do not re-sign it again – the execution fails this time as the script has been modified
  • But then open a new tab in PowerShell ISE, copy the script contents across from the other tab, and it executes fine – because it is not executing the script off of the file system

 

Have a look at this article also - https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy 

Regards

Click Studios 
 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...