Azure Automation - Hybrid Worker - Connect-Azure AD

Brass Contributor

Is there a way to use Connect-AzureAD in Azure Automation when integrating a hybrid worker?  I have tried multiple ways to try to get it to work and have had zero success.  What is best practice for connecting to Azure when integrating a hybrid worker into your automations?

11 Replies

@Dodge-1350, when using a Hybrid Worker to connect to Azure resources, the easiest way is to use the Run As Account certificate associated with the Automation Account. You must install first the certificate in the Hybrid Worker, by following the steps detailed here. Then you call Connect-AzureAD by using the certificate thumbprint, like this:

 

Connect-AzureAD -Tenant <TenantID> -ApplicationId <ApplicationID> -CertificateThumbprint <CertificateThumbprint>

 

Don't forget to install the AzureADPreview module in the Hybrid Worker.

 

Hope this helps.

@hspinto - I tried that along with many other methods known to work in Azure Automation.  For your information, this is what I receive when I attempt to run that:

 

Connect-AzureAD : The term 'Connect-AzureAD' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:56 char:1 + Connect-AzureAD –TenantId $servicePrincipalConnection.TenantId –Appli ... + ~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (Connect-AzureAD:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException

 

So, based upon your comments and the error, maybe I do need to install the AzureADPreview module on the hybrid worker.  Do you have any information on how that is done?  A reference to the documentation that explains the steps necessary to get it done right and efficiently?  Google is good, but 100 links to pour over to find a solution to a Microsoft installation issue is a bit much to have to pour over and determine efficacy.  Any help with the documentation to get that done would be appreciated.

@Dodge-1350, yes, the error you're getting means you don't have the required module installed. You just have to run Install-Module -Name AzureADPreview from an elevated PowerShell in your Hybrid Worker. You can find instructions here.

@hspinto - perfect, thank you very much for your help and experience.  Much appreciated!

That registration of the module in the hybrid runbook worker appears to have worked properly and we are past that error, which then lead us to the next error:

Connect-AzureAD : CertificateNotFoundInStore At line:56 char:1 + Connect-AzureAD –TenantId $servicePrincipalConnection.TenantId –Appli ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : AuthenticationError: (:) [Connect-AzureAD], ArgumentException + FullyQualifiedErrorId : Connect-AzureAD,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD

Apparently the hybrid runbook worker can't see the certificate associated with the service principal? Do we have to register the certificate too on the hybrid runbook worker?

Failing line: Connect-AzureAD –TenantId $servicePrincipalConnection.TenantId –ApplicationId $servicePrincipalConnection.ApplicationId –CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint

This code works perfectly well if run within the Azure Automation side of things, but running it in the hybrid runbook worker generates that error.
Pretty sure this is the reference to get the AzureRunAsConnection involved in the action:

https://docs.microsoft.com/en-us/azure/automation/automation-hrw-run-runbooks

Please let me know if you know of other references for it or any additional issues that could result from missing modules in the hybrid runbook worker.

Hi.

 

Receiving this error when trying to get the automation cert.

 

Get-AutomationCertificate : The 'Get-AutomationCertificate' command was found in the module 'Orchestrator.AssetManagement.Cmdlets', but the module could not
be loaded. For more information, run 'Import-Module Orchestrator.AssetManagement.Cmdlets'.
At line:53 char:14
+ $RunAsCert = Get-AutomationCertificate -Name "AzureRunAsCertificate"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-AutomationCertificate:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : CouldNotAutoloadMatchingModule

 

Also receiving this error when trying to import the module

 

Import-Module : The specified module 'Orchestrator.AssetManagement.Cmdlets' was not loaded because no valid module
file was found in any module directory.

 

I'd appreciate any thoughts on troubleshooting this.

 

Ed

 

 

Hi @Ed Stalcup,

 

From your description it isn't clear if your HRW are running on-prem or in Azure. If they do run in Azure, have you considered using Managed Identity instead? Azure Automation now supports System Assigned Managed Identities (in Preview) as a replacement for RunAs accounts.

 

If your HRWs are hosted outside of Azure, you could consider using Azure Arc (onboard your HRWs to Arc) and use Managed Identities in a similar fashion.

 

You would still need to assign correct API permissions for Microsoft Graph like you would do for Service Principal (MS graph permissions for managed identities need to be granted directly to the Service Principal.).

@Dodge-1350 - Yeah, the link to register the certificate on the hybrid runbook worker was the key, once you install the certificate, the call to Connect-AzureADPreview works as expected.

@Dodge-1350 Its a bad idea to use a Run As account to automate anything.  That account is granted Contributor (overreaching) permissions at the Subscription level.  We do not use a Run As account whatsoever.  We have created service principals with specific, granular access.  Why Microsoft reccomends this is beyond me.  Even their document states it will alter subscription security.

Can you explain a scenario whereby you would see the run as account being used in Azure Automation to access those permissions exceeding the necessary authority and providing access to someone that shouldn't have it? Wouldn't they need to do that from Azure Automation, where the credential is registered?