Welcome to a tale from the lab of Jon Warnken a Premier Field Engineer.
I have been working with Azure Automation recently, had a need for a runbook that required access in two different Azure Tenants. Because I had a virtual machine in one tenant (Tenant1) that is using a dynamic public IP address that is being used in a DNS zone record in another tenant (Tenant2), I need to update the DNS record when the ip address changes. Now if the VM was in the same tenant as the dns zone this would be easy by making an alias record and map it to the public IP of the VM.
A quick search found a couple of existing runbooks that work with in the same tenant. After updating the code to use parameters and the Az modules this is runbook code I am using:
If you would like to use this runbook, you will find it published on the PowerShell Gallery and can be imported into your automation account.
Up to this point I have been testing with in the same tenant and everything was working great. Because my automation account does not have any access in the other tenant, when I use a subscription id in Tenant2 the runbook will fail. Now I had to figure out how to authenticate this runbook in my second tenant. I considered three different options:
1 – Create an account in Tenant2; store the password in a key vault in Tenant1; have the runbook retrieve the password and use it to authenticate when needed for actions in Tenant2.
2 – Create an account in Tenant1; add the account as a guest user in Tenant2; use the account to execute the runbook.
3 – Delegate the automation account’s run as account in Tenant 2.
Option 1 worked when manually testing the code but ran into context and timing issues when executing via the automation account. This approach also has security and operational risks that would not make it acceptable for a production environment.
Option 2 worked when manually testing but still failed when executing in the context of the automation account.
The only challenge I had was getting the principal id for my automation run as account. The run as account exists as an application and a managed application in Azure Active Directory. If you go the portal and look up the application you will see the Managed application instance.
Clicking on that link will allow you to discover the correct object id to use with your ARM template.
Armed this and the role id you want to delegate complete the parameter json file and onboard the delegation in the target tenant. I used the resource group delegation template option
And setup the parameter file to delegate a user with owner access and my automation account with dns zone contributor access.
Now this runbook can check and update the DNS record in the remote tenant.
Hopefully you find this useful and happy automating.
Disclaimer The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.