What does the LinkedAuthorizationFailed mean in PowerShell?

Question

I'm trying to add virtual network rules in a cosmos db using PowerShell. The VNETS exist in different tenants. I done the same for Storage accounts and it worked fine. I am getting the following error. Could someone give me some pointers as to where i'm going wrong? is it possible to do this in a cosmos db database?

Set-AzureRmResource : LinkedAuthorizationFailed : The client has permission to perform action 'Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action' on scope '/subscriptions/Subscription ID of Cosmos DB/resourceGroups/nbspreprd3/providers/Microsoft.DocumentDb/databaseAccounts/nbspreprd3-config-document-db', however the current tenant '' is not authorized to access linked subscription ''. At line:8 char:5 + Set-AzureRmResource -ResourceType $ResourceType -ResourceGroupNam ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : CloseError: (:) [Set-AzureRmResource], ErrorResponseMessageException + FullyQualifiedErrorId : LinkedAuthorizationFailed,Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.SetAzureResourceCmdlet

This is the PowerShell Script

$ResourceGroupName = "*******"
$accountname = "*******" 
$ResourceType = "Microsoft.DocumentDb/databaseAccounts" 
$cosmosAccount = Get-AzureRMResource -ResourceType $ResourceType -ResourceGroupName $resourceGroupName -Name $accountName
$VnrID1 = "/subscriptions/*******/resourceGroups/build-agents/providers/Microsoft.Network/virtualNetworks/build-agents-vnet/subnets/build-2-subnet"
$VnrID2 = "/subscriptions/*******/resourceGroups/build-agents/providers/Microsoft.Network/virtualNetworks/build-agents-vnet/subnets/build-3-subnet"
$VnrID3 = "/subscriptions/*******/resourceGroups/build-agents/providers/Microsoft.Network/virtualNetworks/build-agents-vnet/subnets/=build1-subnet"


function setCosmosRule {

    Param($ResourceGroupName, $accountname, $ResourceType, $cosmosAccount, $VnrID1)

    $vnetrules = $cosmosAccount.Properties.virtualNetworkRules
$existsCosmos =($cosmosAccount.Properties.virtualNetworkRules | Where-Object {$_.id -eq $VnrID1} | Measure-Object).Count -ne 0
if(-not($existsCosmos)){

    $ourObject = New-Object -TypeName psobject 
    $ourObject | Add-Member -MemberType NoteProperty -Name id -Value $VnrID1
    $ourObject | Add-Member -MemberType NoteProperty -Name ignoreMissingVNetServiceEndpoint -Value True

    $newVnetRules = $vnetrules, $ourObject
    $cosmosAccount.Properties.virtualNetworkRules = $newVnetRules
    $CosmosDBProperties = $cosmosAccount.Properties
    Set-AzureRmResource -ResourceType $ResourceType -ResourceGroupName $ResourceGroupName -ResourceName $accountname  -Properties $cosmosDBProperties -Force 
}


}

Any pointers and tips are much appreciated

Thankyou

If they are in different tenants then don't they first have to be peered first via subnets from both subscriptions? — Mark Brown
Is that your cosmos db and Vnet resource are in the different tenant and subscription? — Jim Xu
Thanks @MarkBrown - I have peered both subnets both ways but still get the same error — tee2k21
@JimXu Yes the cosmosdb is in one tenant and the vnet resource is in another tenant. I thought doing a cross tenant peering would make it work but that has not worked either. — tee2k21
@TaherKhan Could you please check if you have the permissions to access the different tenants? — Jim Xu

Stringfellow Stringfellow · Accepted Answer · 2020-03-17T19:10:10

We solved a similar problem by granting our deployment service principal Network Contributor on the external subscription.

We encountered the same error in nearly the same scenario when deploying a composite ARM template with a Key Vault, Service Bus, Storage Account, and Cosmos DB Account. The first three deployed successfully and the firewalls were setup with the expected VNet/subnets from a separate subscription, peered to deployment target subscription VNet. Everything with RBAC in the external subscription looked fine. Digging into the Microsoft documentation for service endpoints led me to the following:

"After you add the VNet service endpoints to an Azure Cosmos account, to make any changes to the account settings, you need access to the Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action action for all the VNETs configured on your Azure Cosmos account. This permission is required because the authorization process validates access to resources (such as database and virtual network resources) before evaluating any properties."

Source: https://docs.microsoft.com/en-us/azure/cosmos-db/vnet-service-endpoint?toc=%2Fazure%2Fvirtual-network%2Ftoc.json#are-additional-rbac-permissions-needed-for-azure-cosmos-accounts-with-vnet-service-endpoints

It didn't really make sense that we needed to add the explicit permission for the Cosmos DB account, especially since the other resources types were fine. Once the additional access policy was added, then the Cosmos DB account deployed successfully.

What does the LinkedAuthorizationFailed mean in PowerShell?

1 Answers