Table of Contents
My Parameter input is not recognized as a cmdlet in Azure Automation
Nowadays, we roll out Azure and workplace features via a WebApp, such as Conditional Access or Privileged Identity Management for customers that need them.
This speeds up the process of onboarding customers.
We have adapted our WebApp in such a way that you can send multiple ‘components’ to the Azure Automation environment.
Somehow we kept getting a message that the script didn’t recognize e.g. ConditionalAccess or PIM as a cmdlet:
PIM: The term ‘PIM’ is not recognized as a name of a cmdlet, function, script file, or executable program.
Running it locally instead of in Azure Automation it did work, even when pasting the content in from the WebApp in Azure Automation it worked.
I have no knowledge of the WebApp. I know it is built on Razor and has a connection to Azure Automation. How it further builds up the parameters etc. I don’t know.
So, what is causing this?
What struck me about the input from the WebApp was that there were no commas around the input.
Which was the case when entering manually in Azure Automation.
There is of course a semicolon in the input and normally this is used to enter several commands on 1 line.
To keep up with the current trend, I also asked ChatGPT what it means:
In PowerShell, the semicolon (;) is used to separate multiple commands on the same line. For example:
echo "Hello"; echo "World"
Hello
WorldThe semicolon allows you to specify multiple commands to be executed in sequence, on a single line. Each command is executed in order, with the output of one command being passed as input to the next.
It’s important to note that the semicolon is only used to separate commands on the same line. To specify a command on a new line, you should use a new line character (Enter key).
So we are now one step further, apparently the input is not a string.
Even though I specify this as parameter input with [string], some kind of Invoke-Expression is done on the input that comes AFTER the semicolon.
What comes BEFORE the semicolon is seen as a string.
Funny & strange, so you could execute commands on Azure Automation without this being the intention.
Is this a security incident or normal behavior? No idea, but it doesn’t work locally and in the portal it does!
I have solved this in the runbook, and would like to see it solved in the WebApp (if possible), but my solution for PowerShell is to force change the input to a string via this method:
$Component = $Component.ToString()
