Getting AadAuthOperationCannotBePerformedWhenServerIsNotAccessible on ARM template when deploying server admin with dependsOn for server

[aj9411]

Hello, I am intermittently seeing this error when deploying a resource of type Microsoft.DBforPostgreSQL/flexibleServers/administrators via ARM template.

StatusCode: Conflict, Status: Failed, ErrorCode: AadAuthOperationCannotBePerformedWhenServerIsNotAccessible, ErrorMessage: The server '{server name}' is not in an accessible state to perform Azure AD Principal operation. Please make sure the server is accessible before executing Azure AD Principal operations.

I first deploy a postgres server (Microsoft.DBforPostgreSQL/flexibleServers) and explicitly depend on this server for the deployment of the Microsoft.DBforPostgreSQL/flexibleServers/administrators resource.

This situation complicates having stable, reliable deployments as sometimes the dependsOn condition is satisfied when apparently the postgres server is not ready for an Azure AD operation. I think this is a bug, the dependsOn condition for the postgres server should not be fulfilled until the server is ready for an Azure AD operation.

example arm operation id: A6CE82DD8683DCEF, sadly don't have the correlation id available

[TimLinsenmayer]

Got the same issue over here.

[aj9411]

@TimLinsenmayer, I talked with the team that owns Microsoft.DBforPostgreSQL/flexibleServers. In addition to adding the admin in my ARM template, I added a firewall rule. These two operations had the potential to happen in parallel, and when they did, the server returned that error I shared above. So in my case, the fix was to perform the operations serially. I suppose the documentation doesn't do a good job at explaining this.

[MattParkerDev]

@TimLinsenmayer, I talked with the team that owns Microsoft.DBforPostgreSQL/flexibleServers. In addition to adding the admin in my ARM template, I added a firewall rule. These two operations had the potential to happen in parallel, and when they did, the server returned that error I shared above. So in my case, the fix was to perform the operations serially. I suppose the documentation doesn't do a good job at explaining this.

I'm having the same issue, and am also adding an administrator, and a firewall rule. I guess making one depend on the other should fix the issue :)

[TimLinsenmayer]

Can confirm this works. I placed my two ressources of Microsoft.DBforPostgreSQL/flexibleServers/administrators@2024-08-01 into their seperate module, running after my psql module has finished.
That pitfall should be documented though...

[szv]

Hi,
I faced the same issue.
For me it works, when the firewallRule resource depends on the administrator resource.
Then I am able to apply everything in the same Bicep file and the same deployment.

Sample:

resource dbServer 'Microsoft.DBforPostgreSQL/flexibleServers@2024-11-01-preview' = {
  name: ...
  location: ...
  sku: {
    name: ...
    tier: ...
  }
  properties: {
     .........
  }

  resource administrator 'administrators' = {
    name: '........'
    properties: {
      principalType: 'User'
      principalName: '...........'
      tenantId: '............'
    }
  }

  resource AllowAllAzureServicesAndResourcesWithinAzureIps 'firewallRules' = {
    name: 'AllowAllAzureServicesAndResourcesWithinAzureIps'
    dependsOn: [
      administrator // Important: It is not possible to simultaniously assign an administrator and firewall rules. Required: Firewall rules depending on administrator assignments  https://github.com/Azure/azure-postgresql/issues/127
    ]
    properties: {
      startIpAddress: '0.0.0.0'
      endIpAddress: '0.0.0.0'
    }
  }

  // Databases
  resource pseDb 'databases' = {
    name: '.........'
    properties: {
      charset: 'UTF8'
      collation: 'en_US.utf8'
    }
  }
}

[benjaminsampica]

This is very annoying and even the proposed solutions in here don't seem to work 100% of the time.

[wstinkens]

I'm having the same issue when I deploy PSQL flexible server with firewall rules and AAD admins. The proposed solution where firewallRule resource depends on the administrator resource doesn't work.

Can someone provide an example on how to deploy the administrators in a separate module? If I try this I run into issues with defining the parent of the Microsoft.DBforPostgreSQL/flexibleServers/administrators resource. This cannot be an output of my psql model.

[benjaminsampica]

@wstinkens this ended up working for me. This was created in part from some example in another Microsoft repository but I'm sorry I don't remember which one.

param applicationDatabaseAdminsName string
param applicationDatabaseAdminsObjectId string
param applicationIdentityName string
param applicationName string
param ecosystem string
param location string
param resourceName string

var ipAddressAllowList = [
  '0.0.0.0' // Azure
]

resource postgres 'Microsoft.DBforPostgreSQL/flexibleServers@2025-06-01-preview' = {
  name: resourceName
  location: location
  sku: {
    name: 'Standard_B1ms'
    tier: 'Burstable'
  }
  properties: {
    version: '18'
    authConfig: {
      activeDirectoryAuth: 'Enabled'
      passwordAuth: 'Disabled'
    }
    storage: {
      storageSizeGB: 32
      autoGrow: 'Enabled'
    }
    network: {
      publicNetworkAccess: 'Enabled'
    }
    backup: {
      backupRetentionDays: 30
      geoRedundantBackup: 'Disabled'
    }
  }

  resource postGisConfiguration 'configurations' = {
    name: 'azure.extensions'
    properties: {
      value: 'POSTGIS'
      source: 'user-override'
    }
  }

  resource database 'databases' = {
    name: '${applicationName}-${ecosystem}-db-01'
    properties: {}
  }
}

// This must be done separately due to conflicts with the Entra setup
resource ipFirewallRule 'Microsoft.DBforPostgreSQL/flexibleServers/firewallRules@2025-06-01-preview' = [for (ip, i) in ipAddressAllowList: {
  name: '${applicationName}-${ecosystem}-dbfw-0${i}'
  properties: {
    startIpAddress: ip
    endIpAddress: ip
  }
  parent: postgres
}]

// This must be after all other setup to avoid conflicts.
resource admin 'Microsoft.DBforPostgreSQL/flexibleServers/administrators@2025-06-01-preview' = {
  name: applicationDatabaseAdminsObjectId
  properties: {
    principalType: 'Group'
    principalName: applicationDatabaseAdminsName
  }
  parent: postgres
  dependsOn: [
    ipFirewallRule
  ]
}

output connectionString string = 'Server=${postgres.properties.fullyQualifiedDomainName};Database=${postgres::database.name};User Id=${applicationIdentityName};Port=5432;Ssl Mode=Require;'
output hostName string = postgres.properties.fullyQualifiedDomainName
output databaseName string = postgres::database.name