• State Not Answered
  • Replies 3 replies
  • Subscribers 69 subscribers
  • Views 523 views
  • Users 0 members are here
Options
Related

AR Powershell scripts and O365 tenants - Service Principals vs Managed Identities

JohnnyQuest

In the past, I have successfully implemented the use of Office 365 Service Principals in Script Activities that are managing objects in tenants.  Typically, this involves placing a certificate on the AR server and registering this certificate on the Service Principal in the tenant.  This is pretty much identical to the way the AR service itself works with tenants.

The current best practices from Msft would tend to guide us towards using Managed Identities instead of service principals.

So far I haven't had any luck leveraging these from Script Activities nor from Scheduled Task scripts run by the Admin service.  The script fails to authenticate with the tenant.  I believe this is because the Powershell runtime instantiated by the Admin service doesn't pass the AR host's computer identity to the tenant.

I am curious if anyone has gotten this approach to work from "inside" of Active Roles as I have described above?

Parents
  • 0

    Hi, is your Active Roles server an Azure VM, an Azure Arc-enabled server, or plain on-prem ? According to my findings Managed Identity isn't the host's computer identity and isn't passed by the runspace — it's a token fetched from a local metadata endpoint (169.254.169.254) that only exists on Azure VMs or Arc-enabled servers. On a plain on-prem server there's nothing to authenticate against, which would explain the failure in both Script Activities and Scheduled Tasks.

Reply
  • 0

    Hi, is your Active Roles server an Azure VM, an Azure Arc-enabled server, or plain on-prem ? According to my findings Managed Identity isn't the host's computer identity and isn't passed by the runspace — it's a token fetched from a local metadata endpoint (169.254.169.254) that only exists on Azure VMs or Arc-enabled servers. On a plain on-prem server there's nothing to authenticate against, which would explain the failure in both Script Activities and Scheduled Tasks.

Children
  • 0 in reply to sebestyen bedo

    This is what I figured was (not?) happening.

  • 0 in reply to JohnnyQuest

    Hi Johnny,

    Sebestyen nailed the mechanism: a Managed Identity isn't the host's identity and isn't passed by the runspace — it's a token fetched from the local IMDS endpoint. So it only works where that endpoint exists:

    • On-prem: no endpoint, so it always fails (Script Activities and Scheduled Tasks alike). Stick with the service-principal + certificate pattern — it's still fully supported.
    • Azure VM: IMDS at  169.254.169.254  is reachable by any process on the box, so AR can use it. Authenticate directly against it, e.g.  Connect-MgGraph -Identity  (Microsoft.Graph/Az modules only — legacy MSOnline/AzureAD don't support MI), and grant the MI the Graph permissions explicitly.
    • Azure Arc server: also works, but via a different endpoint that needs extra rights on the service account.

    Quick test — drop this in a Script Activity; a token back means IMDS is reachable:

    Invoke-RestMethod -Headers @{Metadata='true'} -Uri '169.254.169.254/.../token

    Hope that helps,

    Aron