Partager via

Échec de l’authentification par mot de passe pour l'utilisateur <user-name>

Cet article vous aide à résoudre un problème qui peut se produire lors de la connexion à Azure Database pour PostgreSQL - Serveur flexible.

Symptômes

Lorsque vous tentez de vous connecter à Azure Database pour PostgreSQL - Serveur flexible, vous pouvez rencontrer le message d’erreur suivant :

psql : erreur : connexion au serveur sur «<nom de serveur>.postgres.database.azure.com » (x.x.x.x.x), le port 5432 a échoué : FATAL : échec de l’authentification par mot de passe pour l’utilisateur «<nom d’utilisateur>»

Cette erreur indique que le mot de passe fourni pour l’utilisateur <user-name> est incorrect.

Après l’erreur d’authentification par mot de passe initiale, vous pouvez voir un autre message d’erreur indiquant que le client tente de se reconnecter au serveur, cette fois sans chiffrement SSL. L’échec ici est dû à la configuration pg_hba.conf du serveur qui n’autorise pas les connexions non chiffrées.

connexion au serveur sur «<server-name>.postgres.database.azure.com » (x.x.x.x.x), échec du port 5432 : FATAL : aucune entrée pg_hba.conf pour l’hôte « y.y.y.y.y », utilisateur « <user-name> » , base de données « postgres », aucun chiffrement

Lors de l’utilisation d’un client libpq prenant en charge SSL, avec des outils tels que psql, pg_dumpou pgbench, il s’agit d’un comportement standard pour essayer de se connecter une fois avec SSL et une fois sans. La raison de cette approche est que le serveur peut avoir des règles différentes pg_hba pour les connexions SSL et non SSL. Le message d’erreur combiné que vous recevez dans ce scénario ressemble à ceci :

psql : erreur : échec de la connexion au serveur sur «<server-name>.postgres.database.azure.com » (x.x.x.x.x), échec de la connexion au port 5432 : FATAL : échec de l’authentification par mot de passe pour l’utilisateur «<user-name>» connexion au serveur à l’adresse «<server-name>.postgres.database.azure.com » (x.x.x.x.x), échec du port 5432 : FATAL : no pg_hba.conf entry for host « y.y.y.y », utilisateur « <user-name> », base de données « postgres », aucun chiffrement

Pour éviter cette double tentative et spécifier le mode SSL souhaité, utilisez l’option de connexion sslmode dans votre configuration cliente. Par exemple, si vous utilisez des variables libpq dans l’interpréteur de commandes bash, vous pouvez définir le mode SSL à l’aide de la commande suivante :

export PGSSLMODE=require

Cause

L’erreur rencontrée lors de la connexion à Azure Database pour PostgreSQL - Serveur flexible provient principalement de problèmes liés à l’authentification par mot de passe :

  • Mot de passe incorrect L’authentification par mot de passe a échoué pour l’erreur d’utilisateur <user-name> se produit lorsque le mot de passe de l’utilisateur est incorrect. Cela peut se produire en raison d’un mot de passe mal typé, d’une modification récente du mot de passe qui n’a pas été mise à jour dans les paramètres de connexion ou d’autres problèmes similaires.

  • utilisateur ou rôle créé sans mot de passe Une autre cause possible de cette erreur est la création d’un utilisateur ou d’un rôle dans PostgreSQL sans spécifier de mot de passe. L’exécution de commandes telles que CREATE USER <user-name> ou CREATE ROLE <role-name> sans instruction de mot de passe associée entraîne un utilisateur ou un rôle sans jeu de mots de passe. Toute tentative de connexion avec ces types d’utilisateurs ou rôles sans définir de mot de passe entraîne une défaillance d’authentification avec l’erreur d’authentification par mot de passe.

  • Violation de sécurité potentielle Si l’échec d’authentification est inattendu, en particulier s’il existe plusieurs tentatives ayant échoué, il peut indiquer une violation de sécurité potentielle. Les tentatives d’accès non autorisées peuvent déclencher de telles erreurs.

Résolution

Si vous rencontrez l’erreur « Échec de l’authentification par mot de passe pour l’utilisateur <user-name>», procédez comme suit pour résoudre le problème.

  • Essayez de vous connecter avec un autre outil

    Si l’erreur provient d’une application, essayez de vous connecter à la base de données à l’aide d’un autre outil, tel que psql ou pgAdmin, avec le même nom d’utilisateur et le même mot de passe. Cette étape permet de déterminer si le problème est spécifique au client ou à un problème d’authentification plus large. Gardez à l’esprit toutes les règles de pare-feu pertinentes susceptibles d’affecter la connectivité. Pour obtenir des instructions sur la connexion à l’aide de différents outils, reportez-vous au panneau « Se connecter » dans le portail Azure.

  • Modifier le mot de passe

    Si vous rencontrez toujours des problèmes d’authentification par mot de passe après avoir essayé un autre outil, envisagez de modifier le mot de passe de l’utilisateur. Pour l’utilisateur administrateur, vous pouvez modifier le mot de passe directement dans le portail Azure, comme décrit dans ce lien. Pour d’autres utilisateurs ou l’utilisateur administrateur dans certaines conditions, vous pouvez modifier le mot de passe à partir de la ligne de commande. Vérifiez que vous êtes connecté à la base de données en tant qu’utilisateur avec l’attribut CREATEROLE et l’option ADMIN sur leur rôle. La commande permettant de modifier le mot de passe est la suivante :

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

  • Définir le mot de passe pour l’utilisateur ou le rôle créé sans

    Si la cause de l’erreur est la création d’un utilisateur ou d’un rôle sans mot de passe, connectez-vous à votre instance PostgreSQL et définissez le mot de passe du rôle. Pour les rôles créés sans privilège LOGIN, veillez à accorder ce privilège en définissant le mot de passe :

    ALTER ROLE <role-name> LOGIN;
ALTER ROLE <role-name> PASSWORD '<new-password>';

  • Si vous soupçonnez une violation de sécurité potentielle

    Si vous pensez qu’une violation de sécurité potentielle provoque un accès non autorisé à votre serveur flexible Azure Database pour PostgreSQL, procédez comme suit pour résoudre le problème :

    1. Activer la capture de journal Si la capture de journal n’est pas déjà activée, configurez-la maintenant. Clé d’enregistrement de journaux pour avoir un œil sur les activités de base de données et intercepter les schémas d’accès inhabituels. Il existe plusieurs façons de procéder, y compris les journaux d’activité Azure Monitor Log Analytics et serveur, qui permettent de stocker et d’analyser les journaux des événements de base de données.

    2. Identifier l’adresse IP de l’attaquant

      • Passez en revue les journaux pour rechercher l’adresse IP à partir de laquelle les tentatives d’accès non autorisées sont effectuées. Si l’attaquant utilise un outil basé sur libpq, vous verrez l’adresse IP dans l’entrée de journal associée à la tentative de connexion ayant échoué :

        connexion au serveur sur «<server-name>.postgres.database.azure.com » (x.x.x.x.x), échec du port 5432 : FATAL : aucune entrée pg_hba.conf pour l’hôte « y.y.y.y.y », utilisateur « <user-name> » , base de données « postgres », aucun chiffrement

        Dans cet exemple, y.y.y.y est l’adresse IP à partir de laquelle l’attaquant tente de se connecter.

      • Modifier log_line_prefix Pour améliorer la journalisation et faciliter la résolution des problèmes, vous devez modifier le paramètre log_line_prefix dans votre configuration PostgreSQL pour inclure l’adresse IP de l’hôte distant. Pour enregistrer le nom d’hôte distant ou l’adresse IP, ajoutez le code d’échappement %h à votre log_line_prefix.

        Par exemple, vous pouvez modifier votre log_line_prefix au format suivant pour la journalisation complète :

        log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u,app=%a,client=%h '

        Ce format inclut :

        • %t pour l’horodatage de l’événement
        • %p pour l’ID de processus
        • [%l-1] pour le numéro de ligne de session
        • %d pour le nom de la base de données
        • %u pour le nom d’utilisateur
        • %a pour le nom de l’application
        • %h pour l’adresse IP du client

        En utilisant ce préfixe de ligne de journal, vous pouvez suivre le temps, l’ID de processus, l’utilisateur, l’application et l’adresse IP du client associés à chaque entrée de journal, fournissant un contexte précieux pour chaque événement dans le journal du serveur.

    3. Bloquer l’adresse IP de l’attaquant explorer les journaux pour repérer les adresses IP suspectes qui continuent de s’afficher dans les tentatives d’accès non autorisées. Une fois que vous avez trouvé ces adresses IP, bloquez-les immédiatement dans vos paramètres de pare-feu. Cela empêche leur accès et empêche toute tentative plus non autorisée. En outre, passez en revue vos règles de pare-feu pour vous assurer qu’elles ne sont pas trop permissives. Les règles trop larges peuvent exposer votre base de données à des attaques potentielles. Limitez l’accès aux plages d’adresses IP connues et nécessaires uniquement.

En suivant ces étapes, vous devez être en mesure de résoudre les problèmes d’authentification et de vous connecter à votre serveur flexible Azure Database pour PostgreSQL. Si vous rencontrez toujours des problèmes après avoir suivi l’aide fournie, n’hésitez pas à déposer un ticket de support.