Service Fabric clusters should only use Microsoft Entra ID for client authentication

What does the recommendation "Service Fabric clusters should only use Microsoft Entra ID for client authentication" check?

Audits each classic Service Fabric cluster (Microsoft.ServiceFabric/clusters) and flags any whose 'azureActiveDirectory' block is empty or absent, meaning clients can connect to the management endpoint using a client certificate alone rather than a Microsoft Entra ID token. It inspects only how administrators and tools authenticate to the cluster: it does not check node-to-node certificate security, the cluster protection level, role-based access inside the cluster, or application traffic. It also does not cover Service Fabric managed clusters, which carry a separate recommendation, so an Entra-secured managed cluster will not satisfy this control for a classic cluster.

Why does "Service Fabric clusters should only use Microsoft Entra ID for client authentication" matter?

A cluster that authenticates clients with only a certificate ties every administrator to a shared secret. That certificate has to be distributed to each operator, it rarely rotates, and anyone who copies the private key from a laptop or a CI runner gains full management access with no record of who acted. There is no per-user revocation, no conditional access, and no multi-factor prompt standing between a leaked .pfx and the cluster. Binding client authentication to Microsoft Entra ID moves access onto a centralised identity system: you grant the read-only or admin role to named users and groups, enforce MFA and conditional access, and revoke a departing operator in one place. For a cluster running production workloads, that is the difference between an auditable access model and a single file that quietly grants the keys to everything.

How do I fix "Service Fabric clusters should only use Microsoft Entra ID for client authentication"?

1. Register the two Microsoft Entra applications the cluster needs (a web application for the cluster and a native application for clients) using the SetupApplications script from the Service Fabric samples, then capture the tenant ID, cluster application ID and client application ID it returns.
2. Add the 'azureActiveDirectory' object to the cluster resource so Entra becomes the client authentication method. In Bicep set 'properties.azureActiveDirectory' to '{ tenantId: <tenant>, clusterApplication: <clusterAppId>, clientApplication: <clientAppId> }', or apply the same block via 'az resource update --resource-type Microsoft.ServiceFabric/clusters --set properties.azureActiveDirectory.tenantId=<tenant> properties.azureActiveDirectory.clusterApplication=<clusterAppId> properties.azureActiveDirectory.clientApplication=<clientAppId>'.
3. Assign the built-in policy in Deny mode so new clusters cannot ship without Entra. Look the definition up by name rather than hardcoding its ID: pid=$(az policy definition list --query "[?displayName=='Service Fabric clusters should only use Azure Active Directory for client authentication'].name" -o tsv); az policy assignment create --name sf-entra-client-auth --policy "$pid" --params '{"effect":{"value":"Deny"}}' --scope <scope>.

# 1. Establish the Entra path FIRST: provision a SQL Entra admin (an Entra group is best).
gid=$(az ad group show --group "sql-admins" --query id -o tsv)
az sql server ad-admin create \
  --resource-group rg-data \
  --server-name sqlprodcust \
  --display-name "sql-admins" \
  --object-id "$gid"

# 2. Switch the Synapse workspace to Microsoft Entra ID Only (local SQL admin disabled).
az synapse workspace update \
  --resource-group rg-data \
  --name synprodanalytics \
  --use-microsoft-entra-only-authentication true

# 3. Disable the Cosmos DB account key ONLY after clients use a managed identity (NoSQL API).
az resource update \
  --resource-group rg-data \
  --name cosmosprodcust \
  --resource-type "Microsoft.DocumentDB/databaseAccounts" \
  --set properties.disableLocalAuth=true

# 4. Ratchet it shut: assign the built-in policy by its EXACT display name (look up its id, never hardcode a GUID).
pid=$(az policy definition list \
  --query "[?displayName=='An Azure Active Directory administrator should be provisioned for SQL servers'].name" -o tsv)
az policy assignment create \
  --name require-sql-entra-admin \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"