Apr 13 2021 05:37 AM
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?
Apr 14 2021 02:16 PM
@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.
Apr 14 2021 02:39 PM
@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.
Apr 14 2021 03:27 PM
@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.
Apr 15 2021 05:06 AM
@hspinto - perfect, thank you very much for your help and experience. Much appreciated!
Apr 15 2021 05:37 AM
Apr 15 2021 05:52 AM
Apr 15 2021 12:07 PM
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
I'd appreciate any thoughts on troubleshooting this.
Ed
Apr 16 2021 10:30 AM
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.).
Apr 16 2021 12:34 PM
@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.
Jul 30 2021 11:05 AM
@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.
Aug 11 2021 06:30 AM