Postgresql Flexible Server Unexpected Error Trying to Add Entra Admin

Question

I am trying to add a Microsoft Entra Administrator to an existing Postgresql Flexible Server but am seeing this error:

{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceOperationFailure\",\"message\":\"The resource operation completed with terminal provisioning state 'Failed'.\",\"details\":[{\"code\":\"InternalServerError\",\"message\":\"An unexpected error occured while processing the request. Tracking ID: '{redacted}'\"}]}

Here are some details on the setup:

• Active Directory auth is enabled
• Password auth is enabled
• I am trying to set an active directory Group as admin
• Tried using Terraform and also using portal
• Postgresql 16
• Using delegated subnet

Happy to provide additional details or tracking id if needed.

Thanks

Answer 1

I was able to resolve this. The issue was the Group I was trying to sign had been created with "Microsoft Entra roles can be assigned to the group" set to "Yes". I created a new Group with that value set to "No" and the assignment worked.

Answer 2

Hello Philip !

Thank you for posting on MS Learn Q&A.

Azure Database for PostgreSQL Flexible Server supports Microsoft Entra admins as users, groups, service principals or managed identities. Group admins are valid.

https://learn.microsoft.com/en-us/azure/postgresql/security/security-entra-concepts

The most suspicious detail is delegated subnet / private access. Adding an Entra admin group requires the Flexible Server backend to reach Microsoft Entra ID / Microsoft Graph.

Entra ID needs outbound connectivity for operations such as adding Microsoft Entra admin groups. For private access, you must allow outbound traffic to the AzureActiveDirectory service tag and if you use a route table add a route to AzureActiveDirectory with next hop Internet. Custom DNS must also resolve login.microsoftonline.com and graph.microsoft.com.

https://learn.microsoft.com/en-us/azure/postgresql/security/security-entra-configure

Try to check these first:

NSG on the delegated subnet : Allow outbound HTTPS/443 to service tag AzureActiveDirectory.

Route table / forced tunneling : if 0.0.0.0/0 goes to Azure Firewall, NVA, or on-prem you need to add a route for AzureActiveDirectory to Internet or make sure the firewall/proxy allows the required HTTPS traffic.

For custom DNS, confirm these resolve publicly:

•  login.microsoftonline.com
  

•  graph.microsoft.com
  

and for the delegated subnet rules avoid NSG rules that use Application Security Groups for PostgreSQL Flexible Server and make sure required PostgreSQL subnet traffic and Storage service tag traffic are not blocked.

Microsoft also notes that PostgreSQL Flexible Server private-network deployments can be affected by route tables, especially when outbound traffic is forced through a firewall or appliance, and specifically calls out the AzureActiveDirectory route requirement for Microsoft Entra connections. ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/postgresql/network/concepts-networking-private"Networking Overview with Private Access (Virtual Network) - Azure Database for PostgreSQL | Microsoft Learn")) Also, Flexible Server does not support NSG rules where an Application Security Group is part of the rule, and restrictive NSGs must still allow subnet PostgreSQL traffic and Storage traffic.

https://learn.microsoft.com/en-us/azure/postgresql/network/concepts-networking-private

To isolate whether it is a network issue or group object issue, try adding a single Entra user as admin temporarily. If the user also fails, it strongly points to networking/service-side provisioning. If the user succeeds but the group fails, verify the group object ID, tenant, and group type.

You can also try the CLI directly using the group object ID:

az postgres flexible-server microsoft-entra-admin create \
  --resource-group <resource-group> \
  --server-name <server-name> \
  --display-name "<group-display-name>" \
  --object-id <group-object-id> \
  --type Group \
  --debug

For Terraform, make sure the server authentication configuration is fully applied before creating the Entra admin resource. Microsoft notes that Entra-auth deployment flows should use explicit dependencies so Entra authentication is enabled before dependent database/identity operations.

https://learn.microsoft.com/en-us/azure/postgresql/security/security-entra-concepts

If the NSG, UDR, firewall/proxy, and DNS checks are all correct and the same operation fails from both Portal and CLI, then this is likely a backend provisioning failure. In that case, open an Azure support ticket.