Help with PowerShell Custom Script Extension referencing Key Vault secrets for domain join and Power Automate machine group

Question

Hi everyone,

I’m trying to automate both domain joining and Power Automate registration on my Azure VM Scale Set using a PowerShell script via the Custom Script Extension. Specifically, the script needs to:

1. Join the VM to our Windows domain (using a domain account and password).
2. Add the same VM to a Power Automate machine group (which requires sensitive details like tenant ID, machine group ID, and machine group password).

To avoid storing these credentials in plain text, I’m referencing secrets in Azure Key Vault. Here’s what I’ve done so far:

• Created and stored each secret (domain credentials, tenant ID, machine group ID/password, etc.) in the Key Vault.
• Assigned the VM Scale Set’s managed identity the Key Vault Secrets User role in Access Control (IAM).
• Temporarily set the Key Vault networking to “Allow public access from all networks” to rule out firewall issues.
• Updated my PowerShell script to install/import the Az PowerShell module, then call Connect-AzAccount -Identity and Get-AzKeyVaultSecret.

Interestingly, if I hard-code all the secrets directly in my PowerShell script, the process works flawlessly—the VM joins the domain and is added to the Power Automate machine group with no issues. However, when I switch to referencing the Key Vault secrets, I encounter problems such as secrets being null, “Forbidden” errors, or the extension failing with a non-zero exit code.

Has anyone tackled a similar scenario? Any tips on confirming the correct Key Vault permissions, tenant/subscription context, or verifying whether the vault is in “Vault access policy” vs. “Azure role-based access control” mode? I’d really appreciate any pointers!

Thanks in advance!Hi everyone,

I’m trying to automate both domain joining and Power Automate registration on my Azure VM Scale Set using a PowerShell script via the Custom Script Extension. Specifically, the script needs to:

1. Join the VM to our Windows domain (using a domain account and password).
2. Add the same VM to a Power Automate machine group (which requires sensitive details like tenant ID, machine group ID, and machine group password).

To avoid storing these credentials in plain text, I’m referencing secrets in Azure Key Vault. Here’s what I’ve done so far:

• Created and stored each secret (domain credentials, tenant ID, machine group ID/password, etc.) in the Key Vault.
• Assigned the VM Scale Set’s managed identity the Key Vault Secrets User role in Access Control (IAM).
• Temporarily set the Key Vault networking to “Allow public access from all networks” to rule out firewall issues.
• Updated my PowerShell script to install/import the Az PowerShell module, then call Connect-AzAccount -Identity and Get-AzKeyVaultSecret.

Interestingly, if I hard-code all the secrets directly in my PowerShell script, the process works flawlessly—the VM joins the domain and is added to the Power Automate machine group with no issues. However, when I switch to referencing the Key Vault secrets, I encounter problems such as secrets being null, “Forbidden” errors, or the extension failing with a non-zero exit code.

Has anyone tackled a similar scenario? Any tips on confirming the correct Key Vault permissions, tenant/subscription context, or verifying whether the vault is in “Vault access policy” vs. “Azure role-based access control” mode? I’d really appreciate any pointers!

Thanks in advance!

Answer 1

Hello @razec18

Thank you for posting your query on Microsoft Q&A.

Verify that the Key Vault has been made accessible to the Managed Identity of the VM Scale Set. There are two main places where permissions are required:
Role-Based Access Control (RBAC) in Azure: It is accurate to grant access to secrets in the Key Vault by assigning the "Key Vault Secrets User" position, as you have already explained. For this role assignment, make sure the appropriate scope (subscription, resource group, or vault) is chosen.
Access Policies: Verify that the appropriate access policies have been enabled. If your Key Vault uses Vault access policies rather than Azure RBAC, this can be especially important. In this case, the Managed Identity of your VM Scale Set must be explicitly granted access to secrets within the Key Vault.

Key Vault access policies do not support granular, object-level permissions like a specific key (or to a single key), secret (or to a single secret), or certificate (or to a single certificate). When a user is granted permission to create and delete keys, they can perform those operations on all keys in that key vault.

Key Vault access policies (Not RBACs) grant permissions separately to keys, secrets, or certificate (https://learn.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).

You can grant a user access only to keys and not to secrets. Access permissions for keys, secrets, and certificates are managed at the vault level.

You can set access policies for a key vault use the Azure portal, the Azure CLI, Azure PowerShell, or the Key Vault Management REST APIs.

Reference: https://learn.microsoft.com/en-us/azure/key-vault/general/security-features#controlling-access-to-key-vault-data

Choose "Vault access policy". If you've created an Azure Key Vault with default option (you didn't select the permission model), it will have Azure RBAC for its permission model. The solution: delete your Azure Key Vault and create a new one with "Vault access policy".

Refer similar cases: https://learn.microsoft.com/en-us/answers/questions/1489283/how-do-i-use-access-control-page-now-that-vault-ac

https://learn.microsoft.com/en-us/answers/questions/2119975/how-to-add-secret-and-retrieve-it-in-vm-powershell

https://learn.microsoft.com/en-us/answers/questions/1291943/how-can-i-access-the-access-policies-in-keyvault

I hope this clarifies things.

If this answers your query, do click Accept Answer and Yes for "Was this answer helpful". And, if you have any further query do let us know.

Answer 2

Hello razec18,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are in need of help with PowerShell Custom Script Extension referencing Key Vault secrets for domain join and Power Automate machine group.

The solution here involves debugging PowerShell authentication, validating managed identity permissions, and ensuring networking is not blocking access. The best practice is not to delete and recreate Key Vault but to adjust permissions properly, do the followings:

1. Run the following PowerShell command inside the VM to check if the VM Scale Set’s managed identity can access Key Vault:

      # Check if the managed identity is assigned correctly
      $vmIdentity = (Invoke-RestMethod -Uri "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-08-01&resource=https://management.azure.com/" -Method GET -Headers @{Metadata="true"}).access_token
      Write-Output "Managed Identity Token: $vmIdentity"
   

   If this fails, ensure that: The VM Scale Set has a system-assigned managed identity enabled. The managed identity is assigned to the correct tenant and subscription. Run: Get-AzSubscription
2. For Azure RBAC Permission Model run:

      Get-AzRoleAssignment -ObjectId "<ManagedIdentityClientID>" -Scope "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.KeyVault/vaults/<KEYVAULT_NAME>"
      
   

   Ensure it returns: Specifically, Key Vault Secrets User role assigned at the Key Vault resource level and for Vault Access Policy Model run: Get-AzKeyVaultAccessPolicy -VaultName "<KEYVAULT_NAME>" Ensure the output contains permissions to Get and List secrets.
3. Then, modify the PowerShell script to explicitly check for errors:

      # Authenticate using managed identity
      try {
          Connect-AzAccount -Identity -ErrorAction Stop
          Write-Host "Successfully authenticated with Managed Identity."
      } catch {
          Write-Host "Failed to authenticate. Error: $_"
          exit 1
      }
      # Retrieve secret
      try {
          $domainPassword = Get-AzKeyVaultSecret -VaultName "<KEYVAULT_NAME>" -Name "<SECRET_NAME>" -AsPlainText -ErrorAction Stop
          Write-Host "Successfully retrieved secret."
      } catch {
          Write-Host "Failed to retrieve secret. Error: $_"
          exit 1
      }
   

   Also, check logs from the VM extension:

      Get-AzVMExtension -ResourceGroupName "<RESOURCE_GROUP>" -VMName "<VM_NAME>" -Name "CustomScriptExtension"
   

4. Check if the VM is in a VNet with private endpoints:

      Get-AzKeyVaultNetworkRuleSet -VaultName "<KEYVAULT_NAME>"
   

   Also, check if: The VM subnet is allowed in Key Vault's firewall rules and if the VM can reach Key Vault’s private endpoint using:

      Test-NetConnection -ComputerName "<KEYVAULT_PRIVATE_ENDPOINT>"
      
   

With the above, you should be able to know the root cause and find the appropriate non-overhead headway.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

---

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.