PowerShell Security and Delegation - PKI and PSRemoting

Yesterday, I had a great time with the CincyPowerShell user group discussing security and delegation in PowerShell with PKI, code-signing certificates, PowerShell Remoting and PowerShell Web Access ( new with Windows Server 2012! ).

In this article, I'm posting links to the PowerShell snippets we walked through for each topic ...

PowerShell and PKI

Lots of organizations are looking for ways to better control the secure execution of PowerShell scripts by permitting only scripts created by trusted script authors to run.  If your organization has a Public Key Infrastructure ( PKI ) implemented, you can leverage it for enrolling code-signing certificates and sign your PowerShell scripts.  But, what if you don't currently have a PKI already implemented?  Well, here's a couple options that you can use to help jumpstart your efforts:

  1. You can use Windows Server 2012 Active Directory Certificate Services to set up a PKI in your environment pretty quickly.  Best practice is to setup a standalone root CA that you then use to sign one or more subordinate enterprise CA's to enroll and sign requested certificates.  Once your subordinate CA(s) are up and running, you can then power off your standalone root CA for safe, secure storage.
     
    DO IT: Download Windows Server 2012 and work through this Step-by-Step Guide to setup your PKI.
     
  2. If you don't control Active Directory in your shop, you can still can create your own self-signed CA and code-signing certs using the free makecert tool.  Your AD Admins will then need to help you publish the CA as a Trusted Root certificate and your code-signing certificate as a Trusted Publisher certificate using Group Policy.

Once you've got your certificate strategy in place, you can download the PowerShell snippets below to sign your PowerShell scripts and update your PowerShell execution policy to "All Signed" so that only scripts signed by a Trusted Publisher will execute in your environment.

PowerShell Remoting and PowerShell Web Access

PowerShell Remoting and PowerShell Web Access are certainly cool capabilities for remote, multi-server automation via PowerShell, but we can also use these capabilities with customer PowerShell Session Configurations to securely delegate only specific PowerShell modules and Cmdlets to users ( think Developers and Help Desk engineers ) for just the remote tasks they need to perform. 

How are you securing PowerShell?

Got any tips that you use to secure PowerShell scripts in your environment?  Feel free to share in the comments below!

- Keith