Azure Automation ignoring Signing requirement for Runbooks

So, you can have Hybrid Runbook Workers require their Runbooks to be signed. Which is neat coz these are on-prem machines after all and I like to have that extra level of security of knowing the Runbooks have to be signed so anyone with access to the Automation Account cannot create their own Runbooks and make use of sensitive credentials etc. There’s official instructions too – here’s the one for Windows, and right below it there’s Linux too.

I loved the instructions – they felt very neat. And the final step of this process is to run the following cmdlets on the Hybrid Runbook Worker to actually enable this feature:

Great! I did all that and then tried running an unsigned Runbook hoping it would fail… but nope, it ran fine! Huh, odd. Maybe it only applies to new Runbooks? Nope, they too run. Perhaps a reboot of the Worker? Nada, doesn’t help!

I checked the Event Logs, the on-disk logs (C:\ProgramData\Microsoft\System Center\Orchestrator\<version>\SMA\Sandboxes by the way) but there’s nothing there. No mention of even looking for signed Runbooks! What the heck.

Then I remembered I am using the newer extension system for this Runbook Worker. Let’s add the agent based one too to see if that helps? That ran into a lot of trouble (it’s a slow process.. it downloads a bunch of modules… and requires IE Enhanced Security to be disabled which you only realize when it bombs and so you got to disable that and restart the whole thing… basically all this is why I went with extensions this time (plus I like trying out new things) including an error that this machine is already registered somewhere.

I’ve ran into that sort of an error in the past and remembered that the official instructions don’t entirely help as there’s a Registry key to go and delete (thanks to this blog post): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HybridRunbookWorker

So I searched for that in the Registry – didn’t find anything, but found HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HybridRunbookWorker2 instead. Interesting, so that must be for the extension based workers. I took a peek in that and what do you know, it has EnableSignatureValidation and TrustedStorePath. So I set these to the same values I had set earlier via the cmdlet and now the Worker enforces signing. Yay!

Wasted a lot of time on this… eugh, but at least it works now.