Azure PostgreSQL Flexible Server: Admin password reset not taking effect (authentication always fails)

Question

I’m experiencing a persistent authentication issue when trying to connect to my Azure PostgreSQL Flexible Server.

Server: bodyshop-pgsql-dev.postgres.database.azure.com Admin user: adminpgsql@bodyshop-pgsql-dev Authentication mode: PostgreSQL authentication only Status: Server is “Ready” in Azure Portal Firewall: My public IP is allowed SSL: Using sslmode=require

After resetting the admin password multiple times in the Azure Portal (waiting several minutes for propagation), every connection attempt still fails with the same error:

Code

psql: error: connection to server at "bodyshop-pgsql-dev.postgres.database.azure.com" (20.226.56.111), port 5432 failed:
FATAL: password authentication failed for user "adminpgsql@bodyshop-pgsql-dev"

I have confirmed:

The admin username is correct (adminpgsql).

The server is not using Microsoft Entra authentication.

The server is reachable (no network or firewall errors).

The password meets Azure’s complexity requirements.

The issue occurs both in Cloud Shell and DBeaver.

The server is not throttling connections.

TLS/SSL is correctly configured.

At this point, it seems the server is not accepting the newly reset password, even though the reset operation completes successfully.

Question: What additional steps can I take to ensure the admin password is actually applied to the server? Is there a way to verify the internal state of the admin role or force a full credential refresh on Azure PostgreSQL Flexible Server?

Any guidance would be greatly appreciated.

If you want, I can also prepare a short version, or a more technical version for GitHub Issues or StackOverflow.

Answer 1

Given the checks already completed, the supported next steps are:

1. Try the same admin username and password from a different client such as psql or pgAdmin.
   • This helps confirm whether the failure is client-specific or a broader authentication problem.
   • Since the issue already reproduces in both Cloud Shell and DBeaver, that points away from a single-client issue.
2. Reset the administrator password again, but first verify the server can actually accept password-based authentication.
   • In Azure Portal, the Reset password button is only enabled when:
     • server status is Ready
     • authentication method is PostgreSQL authentication only or PostgreSQL and Microsoft Entra authentication
   • If the button is disabled, hovering over it shows the reason.
3. Verify password authentication support from CLI.
   • Run:

      az postgres flexible-server show \
        --resource-group <resource_group> \
        --name <server> \
        --query authConfig.passwordAuth \
        --output tsv
   

   • If password-based authentication is not enabled, a password reset command can complete without reporting an error but still not change the administrator password.
4. If resetting from Portal continues to appear successful but authentication still fails, reset from CLI:

      az postgres flexible-server update \
        --resource-group <resource_group> \
        --name <server> \
        --admin-password <new_password>
   

   • If the server is not in the Ready state, the CLI returns an error such as:

      Server <server> is busy with other operations. Please try later
   

5. If the problem is only for a non-admin role, change that password from SQL instead:

      ALTER USER <user-name> PASSWORD '<new-password>';
   

   This requires a user with the CREATEROLE attribute and the ADMIN option on that role.
6. If the password authentication failure persists after testing with another client and resetting the admin password again, capture logs and open a support request.
   • The documented guidance is to enable log capture through Azure Monitor Log Analytics or server logs.
   • If still unresolved after following the guidance, file a support ticket.

About the specific questions:

• There is no documented method here to verify the internal state of the built-in admin role.
• There is no documented method here to force a separate “credential refresh” beyond resetting the administrator password through Portal or CLI.
• If password reset operations report success but the server still rejects the admin credentials across multiple clients, the supported path in the available guidance is log capture plus an Azure support request.

---

References:

• Reset administrator password in Azure Database for PostgreSQL flexible server
• Password authentication failed for user <user-name>

Answer 2

Hi Romeo Guevara,

Thank you for reaching out to the Microsoft Q&A forum. 

The issue looks more like a username or credential problem than a firewall, network, or SSL issue.

Please try these steps:

1. Use only adminpgsql as the username. Do not use adminpgsql@bodyshop-pgsql-dev.
2. Test from Cloud Shell:

      psql -h bodyshop-pgsql-dev.postgres.database.azure.com -p 5432 -U adminpgsql -d postgres "sslmode=require"
   

3. Enter the newly reset password when prompted.
4. In DBeaver, remove the saved password and enter the new password manually.
5. In Azure Portal, confirm PostgreSQL authentication is enabled.
6. Reset the administrator password once more and wait a few minutes before testing.

There is no supported way to view the actual password/hash of the Azure PostgreSQL admin role, and normally there is no separate credential refresh operation required after a password reset.

If adminpgsql still fails from both Cloud Shell and DBeaver after a fresh password reset, this may need to be investigated as a service-side authentication issue.

References:

https://learn.microsoft.com/en-us/azure/postgresql/security/security-reset-admin-password?tabs=portal-reset-admin-password

Answer 3

Thank you very much for your guidance, Himaja. Your explanation about the authentication flow and the suggestion to validate the connection using the plain adminpgsql username were key steps in solving the issue. After following your recommendations and reviewing the authentication configuration, the connection to the Azure PostgreSQL Flexible Server was successfully established.

I truly appreciate your clear and practical support. It helped us move forward confidently and resolve the problem.