Azure automation is great but one of the major features it has never had is the ability to give users access only to certain runbooks and not the whole automation account with every single runbook. Microsoft have now released the ability for us to assign permissions to individual runbooks for users or groups. As of writing this article the ability is only provided via powershell but i am sure a GUI version will be made available over the next few months.

In order to get this working there are two RBACs you need to apply, this first is give the users ability to run automation jobs which is set on the automation account (you only need to do this once) and the second is the ability for the users to see the runbook (you need to apply this to every runbook you want the users to see). Please also make sure that the users does not have read permission over the automation account resource group or they will be able to see all runbooks and run them.

Automation Job Operator – this is required once so the users or groups can run the runbooks and is set on automation account level

Automation Runbook Operator – this is required for every runbook you want the user or group to be able to see

Once you do this the users will be able to see individual runbooks only, i recommend you make a shared dashboard to make the user experience better.

This i what it will look like from a users perspective:

Some time ago i wrote up a post (located here) explaining how you can setup traffic manager with ADFS and have proper monitoring of the service. Today i will go over how to setup ADFS behind the Azure Application Gateway. This will enable you to protect your ADFS service and monitor it with the WAF provided by the application gateway.

Before we begin one prerequisite which i am still not sure if its really needed but i had problems and i believe this fixed it:

You need to set the default HTTPS Binding, i believe this is required as i am not sure if the health probe is truly SNI compliant, i might be wrong here but it doesn’t hurt to set this. To set it you simply need to run the following command on the WAP servers (just change the cert hash):

Ones that’s done create a Application gateway in Azure and do the following:

1. Create a Frontend listener with thew following settings:
   • HTTPS Protocol
   • Listen on port 443
   • Multi-Site type, you can do basic but that will limit your application gateway to only the ADFS service for port 443
   • Provide a PFX file of your ADFS certificate. make sure you include the private key and a strong password
2. Create a Health Probe with thew following settings (just change the host):
   • 
   • The path (so you can copy and paste): /adfs/ls/IdpInitiatedSignOn.aspx
3. Create a HTTP Setting with thew following settings
   • HTTPS Protocol
   • Cookie based affinity: Disabled (you really don’t need that for ADFS)
   • Port 443
   • Export your ADFS certificate as a base 64 format (do not include the private key) and add it.
   • Tick the “Custom probe” and select the probe we created earlier
4. Create a Backendpool which includes all your WAP servers
5. Crete a Basic Rule using the objects created earlier.

And that’s it, this is not only a secure solution but it will give you a proper monitoring of both the WAP and ADFS servers. Works great with loadbalancing between on-prem and Azure.

It is now (has been for a while) possible to modify Azure AD via the Azure Automation. The example below uses the Run As Automation Account to first Connect to Azure AD and then run the appropriate commands. You can also create a dedicated Run As account if you want, as well as use a username and password (less secure).

Before you write your code make sure that you:

• Add the “AzureAD” module to the Automation Account
• Give the Azure Automation Run As account the appropriate permission as show at the end of this article

Automation Code example (list all the groups in AD):

Give the Azure Automation Run As account the appropriate permissions:

• Go to Azure Active Directory -> App registrations -> The Run Ass Account.
• Then go to the API access as show:

• Give the appropriate access, example below:

Don’t forget to click grant permissions!

This is a bit of a self-explanatory one, but I thought I would mention it anyway. When you build an ASR Master Target server make sure if you have more than one SCSI controller that they are of the same type, it doesn’t matter what type they are (LSI Logic SAS, VMware Paravirtual, ect..) but they both need to be the same or you will get the following error on the Azure portal when you attempt to fall back the machine to On-premeses.

Quick fyi for anyone using Azure ASR, make sure if you are protecting a virtual machine located in Azure to unselect the temp drive disk D when you are adding the machine to ASR protection. If you try and protect the disk to on-premises, you will get the below error message. If you do you will need to delete the protection and reprotect without drive D. The below error only occurs when you try and reprotect to on-premises, it seem to work fine if you reprotect to another azure location.

Today I had a very fun time trying to figure out where errors were coming from my child runbook when it ran fine on it’s own. Its seems Microsoft error handling from inline calls to child runbooks is a bit buggy and cost me a day of looking through working code to figure out the problem. It reports weird errors out of which not all are actually true or correct. You may get errors like:

If you do look at the code the foreach/if loop error is referring to as the problem is most likely coming from a function or a method inside the loop. I found deleting (not commenting as it doesn’t work) all code below the if statement or foreach loop gives a better and more precise message exactly where the error is coming from.