LinkedAuthorizationFailed when adding VNET new resource via ARM template

Question

I am trying to deploy a function app using a ARM template from the azure portal. I am getting this error but not sure what needs to be changed. Any suggestions?

The client has permission to perform action 'Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action' on scope '/subscriptions//resourcegroups//providers/Microsoft.Web/sites/', however the linked subscription 'xxxxxx' was not found. (Code: LinkedAuthorizationFailed)

{
"contentVersion": "1.0.0.0",
"parameters": {
    "siteName": {
        "defaultValue": "defaultName",
        "type": "String",
        "metadata": {
            "description": "Function app name to create"
        }
    },
    "storageAccountName": {
        "defaultValue": "defaultName",
        "type": "String",
        "metadata": {
            "description": "AzureWebJobsStorage name - a azure storage account that currently exists"
        }
    },
    "environment": {
        "defaultValue": "dev",
        "allowedValues": [
            "dev"
        ],
        "type": "String",
        "metadata": {
            "description": "The environment targeted"
        }
    },
    "location": {
        "defaultValue": "[resourceGroup().location]",
        "type": "String",
        "metadata": {
            "description": "Physical location - can leave Default"
        }
    },
    "serviceAppPlan": {
        "defaultValue": "default",
        "type": "String",
        "metadata": {
            "description": "App service plan name - can leave if environment specified"
        }
    }
},
"resources": [
    {
        "type": "Microsoft.Web/sites",
        "apiVersion": "2022-09-01",
        "name": "[parameters('siteName')]",
        "location": "[parameters('location')]",
        "kind": "functionapp,linux",
        "properties": {
            "serverFarmId": "[parameters('serviceAppPlan')]",
            "virtualNetworkSubnetId": "[format('/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Network/virtualNetworks/{2}/subnets/default', subscription().displayName, resourceGroup().name, reference(resourceId('Microsoft.Network/virtualNetworks', format('{0}-myVnet', parameters('environment'))), '2020-11-01'))]",
            "clientAffinityEnabled": false,
            "siteConfig": {
                "linuxFxVersion": "DOTNET|6.0",
                "alwaysOn": true,
                "ftpsState": "Disabled",
                "appSettings": [
                    {
                        "name": "AzureWebJobsStorage",
                        "value": "<storage here>"
                    },
                    {
                        "name": "APPLICATIONINSIGHTS_CONNECTION_STRING",
                        "value": "<app-insights here>"
                    },
                    {
                        "name": "FUNCTIONS_EXTENSION_VERSION",
                        "value": "~4"
                    }
                ],
                "ipSecurityRestrictions": [
                    {
                        "vnetSubnetResourceId": "[format('/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Network/virtualNetworks/{2}/subnets/default', subscription().displayName, resourceGroup().name, format('{0}-myVnet', parameters('environment')))]",
                        "action": "Allow",
                        "tag": "Default",
                        "priority": 34,
                        "name": "[format('{0}-myVnet', parameters('environment'))]"
                    },
                ]
            }
        }
    }
]

}

Answer 1

Found my issue:

The documentation for Site.VirtualNetworkSubnetId says it needs to be in this format: /subscriptions/{subscriptionName}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}

I was attempting to get the subscriptionName with subscription().displayName. This does not seem to work and produces the error above. Using subscription().subscriptionId instead and passing that in does work.

I have no idea why, I guess it could be a permission issue or perhaps a bug/documentation issue.