Prerequisites

Permissions required for your user to install resources

To install the Azure resources and register the required applications, the following permissions are needed. In organisations with segregated duties these may be held by different people or teams — see the full authorization matrix and division of responsibilities in the Installation Overview.

1. Contributor on the Azure Subscription (preferred) or on the existing Resource Group where the resources will be installed — to create the App Services, SQL Server, databases and (optionally) the storage account.
2. Owner or User Access Administrator on the subscription/resource group — only if you enable blob storage (moveIlapFileToBlobStorage = 'true'). The deployment creates a role assignment (Storage Blob Data Contributor) for the background-job identity, and creating role assignments is not permitted by the Contributor role alone.
3. Application Developer in Entra ID (Azure AD) — to register and maintain the API and UI app registrations and enterprise applications used for authentication.
4. Entra ID SQL administrator — the user nominated as the SQL Server administrator must sign in to each database after deployment (via Entra authentication) to run the grant script, because the server is Entra-only (no SQL login/password).
5. Key Vault access — rights to import the SSL certificate and set access policies on the vault (Key Vault Administrator, or Contributor plus certificate/secret access), and to grant the Microsoft Azure App Service principal read access to it.

Other prerequisites

Azure Key Vault

An Azure Key Vault with a certificate (SSL) for your domain that can be accessed by your account and azure applications. See how to create key vault, add access policy and upload certificate.

Custom Domains

We recommend using custom domain for the Azure resources to avoid using azurewebsites.net as it is frequently blocked in corporate firewalls.

SSL Certificate

To enable custom domain, a SSL certificate is required, and this should be stored as a keyvault certificate.

DNS

To make use of custom domains, CNAME- records need to be added for the web applications. Add the CNAME records at your DNS provider to link each custom domain to the corresponding Azure resource — for example, map app.yourdomain.com to yourapp.azurewebsites.net.

Create the key vault and upload the certificate

These steps create the resource group and Key Vault, grant access, and import your SSL certificate with the Azure CLI. They are also packaged as ready-to-run scripts in the deployment package under Azure.IaC/Scripts/ — setup-keyvault-certificate.azcli (Bash) and setup-keyvault-certificate.ps1 (PowerShell): edit the CONFIG block at the top and run it to perform every step below. The commands here are shown in Bash; on Windows use the PowerShell script or adjust the variable syntax.

Sign in and select your subscription, and set some variables:

az login
az account set --subscription '<your-subscription-id>'

RESOURCE_GROUP='rg-ilapanalytics-dev'
LOCATION='westeurope'
KEY_VAULT_NAME='kv-ilapanalytics-dev'   # 3-24 alphanumerics/dashes, start with a letter, globally unique
CERT_NAME='ilapanalytics-dev'
CERT_PFX_PATH='./ilapanalytics-dev.pfx'
APP_SERVICE_APP_ID='abfa0a7c-a6b6-4736-8310-5855508787cd'   # "Microsoft Azure App Service" (well-known)

Step 1: Create the resource group

Skip this if you are using an existing resource group. Use the same region you will deploy the apps in.

az group create --name "$RESOURCE_GROUP" --location "$LOCATION"

Step 2: Create the key vault

Skip this if you are using an existing key vault. This creates it in the access-policy model used by the following steps.

az keyvault create \
  --name "$KEY_VAULT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --enable-rbac-authorization false

Step 3: Grant your user access to certificates and secrets

USER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
az keyvault set-policy --name "$KEY_VAULT_NAME" --object-id "$USER_OBJECT_ID" \
  --certificate-permissions get list create import update delete \
  --secret-permissions get list set delete

Step 4: Grant the App Service principal read access

App Service needs read access to bind the certificate to your custom domains. Grant the "Microsoft Azure App Service" principal get on secrets and certificates (creating its service principal first if it does not yet exist in your tenant).

APP_SVC_OBJECT_ID=$(az ad sp show --id "$APP_SERVICE_APP_ID" --query id -o tsv 2>/dev/null || az ad sp create --id "$APP_SERVICE_APP_ID" --query id -o tsv)
az keyvault set-policy --name "$KEY_VAULT_NAME" --object-id "$APP_SVC_OBJECT_ID" \
  --certificate-permissions get --secret-permissions get

Step 5: Import the SSL certificate

Import your certificate as a .pfx. Take note of the certificate name — it is used in the Bicep webAppParams.*.certificateName.

az keyvault certificate import \
  --vault-name "$KEY_VAULT_NAME" \
  --name "$CERT_NAME" \
  --file "$CERT_PFX_PATH" \
  --password '<pfx-password>'

Checklist before installation

Before you start the installation, verify that you (or your team, between you) have:

• Contributor role, or resource group access, in the Azure subscription
• Owner or User Access Administrator, if you enable blob storage (moveIlapFileToBlobStorage = 'true')
• Application Developer role in Azure AD, and the two app registrations created
• A nominated Entra ID SQL administrator who can run the post-deployment grant script
• Key Vault access to import the certificate and set access policies
• A custom domain with DNS CNAME records
• An SSL certificate stored in the Azure Key Vault
• The resource group and key vault in the correct (same) region

Notes and recommendations

• Use the same region for all resources (resource group, key vault, app services) to reduce latency.
• Regularly monitor your key vault access policies to ensure compliance with corporate security standards.
• For troubleshooting, make sure your DNS settings propagate correctly and verify access permissions in Azure AD.