Demander l'évaluation
← Toutes les erreurs expliquées

ORA-01017 : Logon denied, la connexion refusée

Par Omar Sall, DBA Oracle · publié le 28 septembre 2026 · sévérité dans Deynao : Vigilance

La base a refusé les identifiants présentés. Elle fonctionne ; elle a dit non à cette connexion. La cause la plus fréquente est un mot de passe faux, mais ce même code couvre un compte absent du conteneur visé, ou un ancien vérificateur de mot de passe après une mise à niveau, et il précède de peu un compte verrouillé : chaque nouvel essai compte, et dix refus consécutifs verrouillent le compte par défaut. Première chose à regarder, avant de réessayer : l'état du compte dans DBA_USERS. Le premier contrôle est dans Vérifier.

Ce que vous voyez

En anglais

ORA-01017: invalid username/password; logon denied

En français

ORA-01017: nom utilisateur/mot de passe non valide ; connexion refusée

Le message revient au client qui tentait la connexion : SQL*Plus, SQL Developer, un serveur d'applications, un traitement planifié, un outil de sauvegarde, une sonde de supervision. Il ne dit pas laquelle des causes est en jeu : le constructeur rend le même texte que le nom soit inconnu, le mot de passe faux, ou le compte absent du conteneur visé, et la formulation actuelle de son portail le dit en toutes lettres, « invalid credential or not authorized » (page d'erreur officielle). Un compte verrouillé répond autrement : ORA-28000: The account is locked. en anglais, ORA-28000: Compte verrouillé. en français, relevés sur une base 21c (le portail écrit aujourd'hui « The account is locked; login denied »). Un mot de passe expiré répond ORA-28001 ; pendant le délai de grâce, la connexion passe avec l'avertissement ORA-28002.

Le refus est enregistré par l'audit de la base, quand il est configuré pour cela. Sur une base neuve, la politique prédéfinie ORA_LOGON_FAILURES est active par défaut, en audit unifié pur comme en mode mixte (documenté ainsi en 19c, constaté sur une 21c), et chaque échec de connexion va dans UNIFIED_AUDIT_TRAIL avec le compte, l'utilisateur système, le poste, le programme client et le code de retour (politiques prédéfinies, référence de la vue). Sur une base mise à niveau depuis une version antérieure, cette politique n'est pas activée d'elle-même (même page). Avec l'audit classique, le seul dispositif en 11.2, il faut AUDIT SESSION WHENEVER NOT SUCCESSFUL et un paramètre AUDIT_TRAIL autre que NONE pour que DBA_AUDIT_SESSION reçoive les refus (instruction AUDIT, référence 11.2). Pour une tentative cliente ordinaire, la source à consulter est la trace d'audit ; le code peut néanmoins apparaître dans le journal d'alertes ou dans des fichiers de trace quand il est provoqué par un processus de la base elle-même ou par une connexion ouverte depuis le serveur.

Ce que ça veut dire

Cette page traite des comptes authentifiés par mot de passe, le cas des comptes applicatifs et d'un compte de supervision ; une authentification externe ou centralisée (système d'exploitation, Kerberos, annuaire) peut produire le même code pour d'autres raisons, hors de son périmètre. À la connexion, le serveur compare ce que le client présente au vérificateur, l'empreinte du mot de passe enregistrée pour ce compte, dans le conteneur où la connexion arrive. Trois choses peuvent manquer : la correspondance, le compte lui-même, ou un vérificateur que le protocole du client sait utiliser. Le code est le même dans les trois cas.

Sur le terrain

La séquence typique commence par un mot de passe qu'on change : rotation planifiée, départ d'un prestataire, demande du responsable sécurité. Les personnes sont prévenues ; les machines ne le sont pas toutes. Un traitement planifié sur un serveur qu'on avait oublié, un pool de connexions qui redémarre, un outil de rapports, une sonde de supervision : l'un d'eux présente encore l'ancien mot de passe, à chaque cycle. Dix refus plus tard, le compte est verrouillé. La personne qui saisit alors le bon mot de passe reçoit ORA-28000, en conclut que le nouveau est faux, essaie l'ancien, et reçoit le même refus. Le réflexe « on déverrouille et on avance » reverrouille aussitôt, au rythme du client fautif, qui n'a pas changé. Ce qu'il faut, avant de déverrouiller, c'est le nommer, et la trace d'audit donne pour chaque refus l'utilisateur système, le poste et le programme (contrôle 2 ci-dessous).

Trois faux diagnostics fréquents :

Un outil de supervision qui se reconnecte à chaque cycle est, dans cette séquence, le client fautif idéal. C'est le sujet de la dernière section.

Vérifier

Les contrôles ci-dessous sont en lecture seule. Ils demandent SELECT sur DBA_USERS, DBA_PROFILES, UNIFIED_AUDIT_TRAIL, DBA_AUDIT_SESSION, V_$OPTION et V_$PARAMETER, accordés directement, sans rôle : c'est exactement ce que fait le script de privilèges de Deynao, et c'est vérifiable sur le compte de supervision dans USER_TAB_PRIVS. Exécutés sur une base 21c. Les colonnes lues dans DBA_USERS, DBA_PROFILES et DBA_AUDIT_SESSION sont documentées dès la version 11.2, la plus ancienne que Deynao supervise (DBA_USERS, DBA_PROFILES, DBA_AUDIT_SESSION) ; UNIFIED_AUDIT_TRAIL existe depuis 12c. Remplacez APP_PAIE par le compte refusé.

-- 1. L'état du compte avant tout nouvel essai : statut, date de verrouillage,
--    expiration, profil, et les versions de vérificateur du mot de passe
SELECT username,
       account_status,
       lock_date,
       expiry_date,
       profile,
       password_versions
FROM dba_users
WHERE username = 'APP_PAIE';

Comment le lire. Le nom se compare tel qu'il est stocké, en majuscules sauf si le compte a été créé entre guillemets. OPEN : le compte est ouvert, le refus vient du mot de passe, du conteneur visé par le client ou du vérificateur. LOCKED(TIMED) avec sa lock_date : le compteur a débordé, le compte se rouvrira seul à la fin de PASSWORD_LOCK_TIME, et chaque essai d'ici là répond ORA-28000. LOCKED sans limite de temps, EXPIRED, EXPIRED(GRACE) et leurs combinaisons sont décrits un à un dans la référence de la vue. Un password_versions sans 11G ni 12C désigne le cas du vérificateur 10G. Aucune ligne veut dire que ce nom n'existe pas dans le conteneur où vous êtes connecté, et c'est déjà une réponse : vérifiez le service de connexion avant le mot de passe. Une erreur ORA-00942 veut dire que ce compte n'a pas accès à la vue.

-- 2. Les refus de connexion des dernières vingt-quatre heures sur ce compte, par poste
--    et programme : ce sont les colonnes qui nomment le client fautif (12c et plus)
SELECT dbusername,
       os_username,
       userhost,
       client_program_name,
       return_code,
       COUNT(*)             AS refus,
       MAX(event_timestamp) AS dernier_refus
FROM unified_audit_trail
WHERE action_name = 'LOGON'
  AND dbusername = 'APP_PAIE'
  AND return_code <> 0
  AND event_timestamp >= SYSTIMESTAMP - INTERVAL '1' DAY
GROUP BY dbusername, os_username, userhost, client_program_name, return_code
ORDER BY refus DESC;

return_code 1017 compte les refus d'identifiants ; 28000, les essais arrivés après le verrouillage ; 28001, un mot de passe expiré. Le trio utilisateur système, poste, programme désigne la machine à corriger. Retirez la ligne sur dbusername pour voir tous les comptes, au prix d'une lecture plus large de la trace. Un résultat vide sur une base calme est normal ; un résultat vide alors qu'un refus vient d'avoir lieu peut indiquer que les échecs ne sont pas enregistrés : vérifiez le mode d'audit (contrôle 3), la politique qui alimente la trace (contrôle 4) et le conteneur depuis lequel vous interrogez.

-- 3. Quel dispositif d'audit est en place : audit unifié pur (TRUE) ou mode
--    mixte (FALSE), et le paramètre de l'audit classique
SELECT 'unified_auditing' AS parametre, value
FROM v$option
WHERE parameter = 'Unified Auditing'
UNION ALL
SELECT name, value
FROM v$parameter
WHERE name = 'audit_trail';

Sur une 11.2, la première ligne n'existe pas, l'audit unifié non plus. TRUE : audit unifié pur, seule la trace unifiée reçoit des enregistrements (vérifier le mode d'audit). FALSE avec audit_trail à DB : mode mixte, le défaut d'une base fraîchement installée, où la trace unifiée reçoit ce que les politiques activées produisent et la vue classique ce que les instructions AUDIT demandent. La base de démonstration de cette page est dans ce cas : vue classique vide, refus présents dans la trace unifiée.

-- 4. Les politiques qui apparaissent dans les enregistrements de connexion réellement
--    produits, lues dans la trace : la vue des politiques actives n'est pas dans le script
SELECT unified_audit_policies, COUNT(*) AS enregistrements
FROM unified_audit_trail
WHERE action_name = 'LOGON'
  AND event_timestamp >= SYSTIMESTAMP - INTERVAL '7' DAY
GROUP BY unified_audit_policies
ORDER BY enregistrements DESC;

ORA_LOGON_FAILURES en réponse dit que les refus sont enregistrés ; en 26ai, la politique prédéfinie s'appelle ORA_LOGIN_LOGOUT (introduction à l'audit, 26ai). Ce contrôle lit ce qui a été produit, pas la configuration : aucune ligne sur sept jours alors qu'un refus vient d'avoir lieu peut indiquer qu'aucune politique n'enregistre les échecs de connexion, le cas d'une base mise à niveau ; la vue AUDIT_UNIFIED_ENABLED_POLICIES tranche, pour qui a le droit de la lire.

-- 5. Avec l'audit classique (11.2 à 19c, ou mode mixte avec AUDIT SESSION) : les
--    refus des dernières vingt-quatre heures par compte et poste
SELECT username,
       os_username,
       userhost,
       returncode,
       COUNT(*)       AS refus,
       MAX(timestamp) AS dernier_refus
FROM dba_audit_session
WHERE returncode <> 0
  AND timestamp >= SYSDATE - 1
GROUP BY username, os_username, userhost, returncode
ORDER BY refus DESC;

Cette vue existe encore en 21c, où l'audit classique est déprécié, et en 26ai, où il est désupporté mais où les réglages existants restent lus (référence 21c, référence 26ai). Cette vue ne porte pas le programme client, que seule la trace unifiée nomme. Un résultat vide ici veut dire qu'aucune instruction AUDIT SESSION n'est en place, ou que la base est en audit unifié pur ; il ne veut pas dire qu'il n'y a eu aucun refus. C'est la lecture qui trompe le plus souvent.

-- 6. La politique du profil du compte, et celle du profil DEFAULT dont il peut hériter :
--    échecs avant verrouillage, durée du verrou, vie du mot de passe, délai de grâce
SELECT profile, resource_name, limit
FROM dba_profiles
WHERE profile IN ((SELECT profile FROM dba_users WHERE username = 'APP_PAIE'), 'DEFAULT')
  AND resource_name IN ('FAILED_LOGIN_ATTEMPTS', 'PASSWORD_LOCK_TIME',
                        'PASSWORD_LIFE_TIME', 'PASSWORD_GRACE_TIME')
ORDER BY profile, resource_name;

Deux profils au plus en réponse : celui du compte et DEFAULT. Les valeurs de DEFAULT sont, sans réglage, 10 essais, 1 jour de verrou, 180 jours de vie et 7 jours de grâce (CREATE PROFILE). Dans le profil du compte, la valeur DEFAULT renvoie à la ligne correspondante du profil DEFAULT, affichée juste à côté. UNLIMITED sur la durée du verrou impose un déverrouillage manuel ; UNLIMITED sur le nombre d'essais supprime le verrouillage.

Agir

Dans l'ordre, et chaque étape peut suffire :

  1. Lire l'état du compte avant de réessayer (contrôle 1). Chaque essai compte pour le même compteur, quel que soit le client. Si le statut est LOCKED(TIMED), le prochain message sera ORA-28000 : attendre la fin de PASSWORD_LOCK_TIME, ou faire déverrouiller.
  2. Nommer le client qui échoue avant de déverrouiller (contrôle 2, ou 5 avec l'audit classique). Déverrouiller d'abord, c'est reverrouiller aussitôt. Poste, programme et utilisateur système désignent la machine à corriger : un traitement planifié, un pool, une sonde.
  3. Déverrouiller, une fois le client corrigé. Exemple à adapter, jamais à copier tel quel ; il demande le privilège ALTER USER (référence) :
ALTER USER app_paie ACCOUNT UNLOCK;
  1. Pour un mot de passe expiré, le changer (ALTER USER ... IDENTIFIED BY), puis le mettre à jour sur chaque client qui le détient, sans quoi la séquence du terrain recommence avec le nouveau.
  2. Pour un compte absent du conteneur, se connecter au service de sa base pluggable, avec une chaîne qui le nomme (hôte:port/service), et non au conteneur racine.
  3. Après une mise à niveau vers 12.2 ou plus, pour les comptes dont password_versions ne contient que 10G (en 21c, ils sont verrouillés dès la mise à niveau) : suivre la procédure documentée, mode permissif temporaire dans sqlnet.ora, expiration des mots de passe, changement par les utilisateurs qui produit les vérificateurs 11G et 12C, puis retour en mode exclusif. Exemple à adapter :
SQLNET.ALLOWED_LOGON_VERSION_SERVER=11

Votre DBA valide, adapte et décide : abaisser la version de protocole autorisée réadmet des vérificateurs anciens sur toute la base, le temps de la procédure et pas au-delà.

Prévenir

Trois mesures tiennent l'essentiel :

AUDIT POLICY ORA_LOGON_FAILURES WHENEVER NOT SUCCESSFUL;

En 11.2, l'équivalent est AUDIT SESSION WHENEVER NOT SUCCESSFUL avec un AUDIT_TRAIL autre que NONE.

Ce qu'on ne fait pas : passer FAILED_LOGIN_ATTEMPTS à UNLIMITED pour faire cesser les verrouillages. On échange un verrou visible contre une force brute silencieuse. Deynao pénalise ce réglage dans le score du domaine Sécurité et recommande cinq essais et un jour de verrou ; ce sont ses seuils, pas ceux du constructeur, dont les défauts sont dix et un. La règle « Sécurité perfectible » et les autres sont publiées : règles d'alerte et temporisations.

Ce que Deynao en fait

Deynao se connecte à vos bases avec le compte de supervision que vous lui confiez. Ce compte est exposé au mécanisme décrit plus haut comme n'importe quel client, et un outil qui se reconnecte à chaque cycle serait le premier candidat pour verrouiller son propre compte. La règle du produit est l'inverse : au premier refus d'authentification, un disjoncteur s'arme pour ce couple compte et base, et plus aucune connexion automatique n'est tentée, ni le rafraîchissement, ni la reconnexion, ni le collecteur du parc, ni la restauration des sessions au démarrage, qui charge les connexions sans les ouvrir. Il couvre les refus ORA-01017, ORA-01005, ORA-28000 et ORA-28001 ; ORA-28002, qui n'est pas un refus mais l'avertissement de fin de vie du mot de passe, figure dans sa liste par précaution. Il se désarme quand vous ressaisissez ou retestez le mot de passe et que cet essai réussit ; cette action explicite de votre part tente toujours. L'état vit en mémoire du serveur Deynao : un redémarrage l'efface, sans rafale au démarrage puisque les connexions se font à la demande. Une base injoignable, écoute absente, instance arrêtée ou délai dépassé, n'arme pas ce disjoncteur : ces échecs surviennent avant l'authentification et ne comptent pas comme des refus. Ils déclenchent un espacement des tentatives, d'environ une minute jusqu'à cinq, pour ne pas marteler l'écoute de la base. Le principe est décrit dans sécurité et confiance : il réduit fortement le risque de verrouillage, il ne l'annule pas, l'essai qui verrouille pouvant être le vôtre si d'autres clients ont déjà consommé le compteur.

À l'écran, la base passe en « Action requise » avec la cause, identifiants refusés ou compte verrouillé, et le code reçu, qui dit par exemple si le mot de passe est expiré. La règle « Authentification bloquée » émet une alerte critique immédiate, et c'est la seule alerte émise pour cette base tant que le disjoncteur est armé : une base dont on ne peut plus lire l'état n'a pas besoin d'alertes de score (règles d'alerte et temporisations). En amont, le domaine Sécurité compte les comptes verrouillés et expirés, lit la politique du profil DEFAULT, vérifie qu'une politique enregistre les refus de connexion et compte les échecs de connexion sur la fenêtre d'audit collectée. Si ce code apparaît dans le journal d'alertes de la base, Deynao le classe en Vigilance ; il n'entre pas dans la règle « Alertes Oracle critiques », réservée aux codes critiques.

Erreurs liées

Sources

Écrit par Omar Sall, DBA Oracle · publié le 28 septembre 2026 · deynao.fr/erreurs-oracle/ora-01017.html

Relu contre Deynao 1.0.3 le 28 septembre 2026 (empreinte de l'entrée de la base de connaissances : dd14ca353229). Les recommandations sont expliquées et priorisées, jamais exécutées par Deynao : votre DBA valide, adapte et décide.