Dépannage de l'erreur ORA-1031: Insufficient Privileges lors d'une connexion AS SYSDBA
S'applique à
Oracle Database - Enterprise Edition - Version 9.2.0.1 à 11.2.0.3 [Release 9.2 à 11.2]
Les informations de ce document s'appliquent à toutes les plateformes.
Objet
Ce document présente des étapes couramment utilisées pour diagnostiquer l'erreur ORA-1031 rencontrée lors d'une connexion en tant que sysdba.
RENAPS offre des services gérés Oracle Database et Middleware. Découvrez comment nous pouvons aider votre entreprise
Concepts généraux
Un utilisateur peut se connecter AS SYSDBA depuis la machine hôte du serveur Oracle avec l'une des méthodes suivantes :
- l'authentification par le système d'exploitation (OS)
- l'authentification par fichier de mots de passe
Depuis une machine distante, un utilisateur ne doit se connecter à la base de données AS SYSDBA qu'au moyen de l'authentification par fichier de mots de passe. Lorsque le serveur Oracle fonctionne sous Windows, il est possible de se connecter à distance en tant que sysdba sans fournir de nom d'utilisateur ni de mot de passe, car la connexion peut alors être sécurisée.
À partir d'Oracle 11g, il est également possible d'utiliser une authentification forte pour SYSDBA. Consultez la Note 457083.1 pour plus de détails.
Authentification SYSDBA par l'OS
L'authentification par l'OS consiste à vérifier l'identité de l'utilisateur qui se connecte à la base de données à l'aide des informations gérées par le système d'exploitation. Un utilisateur de l'OS peut utiliser cette méthode d'authentification si les conditions suivantes sont remplies :
1. l'utilisateur est membre d'un groupe particulier.
2. l'authentification par l'OS est autorisée par les paramètres du serveur (sqlnet.authentication_services est correctement défini)
L'utilisateur de l'OS doit appartenir au groupe OSDBA pour se connecter en tant que sysdba. Sous Unix, le nom par défaut de ce groupe est dba. Sous Windows, le groupe se nomme ORA_DBA.
Sous Unix, le paramètre sqlnet.authentication_services doit être défini à (ALL) ou à (BEQ, <autres valeurs>) pour que cela fonctionne. Sous Windows, ce paramètre doit être défini à (NTS).
Authentification SYSDBA par fichier de mots de passe
Les identifiants fournis lors d'une connexion à distance en tant que sysdba sont comparés au contenu du fichier de mots de passe (password file).
L'authentification par fichier de mots de passe s'active en définissant le paramètre de base de données remote_login_password file à "shared" ou "exclusive".
SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;
Remarque : lorsque l'authentification par l'OS et l'authentification par fichier de mots de passe sont toutes deux activées, c'est l'authentification par l'OS qui est utilisée. Vous pouvez donc vous connecter avec n'importe quelle combinaison nom d'utilisateur/mot de passe. Consultez la Note 242258.1 pour plus de détails.
Dépanner ORA-1031 en AS SYSDBA avec l'authentification par l'OS
1. Vérifiez que l'utilisateur de l'OS fait partie du groupe OSDBA.
Sous Unix
A. Affichez les groupes de l'utilisateur :
[oracle@seclin4 ~]$ id
uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba) context=user_u:system_r:unconfined_t
B. Vérifiez quel groupe OSDBA est défini dans le fichier $ORACLE_HOME/rdbms/lib/config.[cs]
Exemple pour Linux :
[oracle@seclin4 ~]$ cat $ORACLE_HOME/rdbms/lib/config.c
/* SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access. */
/* Refer to the Installation and User's Guide for further information. */
/* IMPORTANT: this file needs to be in sync with
rdbms/src/server/osds/config.c, specifically regarding the
number of elements in the ss_dba_grp array.
*/
#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "dba"
#define SS_ASM_GRP ""
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};
Exemple pour AIX :
[celcaix3]/grdbms/64bit/app/oracle/product/1120/rdbms/lib> cat config.s
# SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access.
# Refer to the Installation and User's Guide for further information.
.rename H.10.NO_SYMBOL{TC},""
.rename H.11.NO_SYMBOL{TC},""
.rename H.12.NO_SYMBOL{TC},""
.rename H.13.NO_SYMBOL{RO},""
.rename H.14.NO_SYMBOL{RO},""
.rename H.15.NO_SYMBOL{RO},""
.rename H.16.ss_dba_grp{TC},"ss_dba_grp"
.lglobl H.13.NO_SYMBOL{RO}
.lglobl H.14.NO_SYMBOL{RO}
.lglobl H.15.NO_SYMBOL{RO}
.globl ss_dba_grp{RW}
# .text section
# .data section
.toc
T.16.ss_dba_grp:
.tc H.16.ss_dba_grp{TC},ss_dba_grp{RW}
T.10.NO_SYMBOL:
.tc H.10.NO_SYMBOL{TC},H.13.NO_SYMBOL{RO}
T.11.NO_SYMBOL:
.tc H.11.NO_SYMBOL{TC},H.14.NO_SYMBOL{RO}
T.12.NO_SYMBOL:
.tc H.12.NO_SYMBOL{TC},H.15.NO_SYMBOL{RO}
.csect ss_dba_grp{RW}, 3
.llong H.13.NO_SYMBOL{RO}
.llong H.14.NO_SYMBOL{RO}
.llong H.15.NO_SYMBOL{RO}
# End csect ss_dba_grp{RW}
.csect H.13.NO_SYMBOL{RO}, 3
.string "dba"
# End csect H.13.NO_SYMBOL{RO}
.csect H.14.NO_SYMBOL{RO}, 3
.string "dba"
# End csect H.14.NO_SYMBOL{RO}
.csect H.15.NO_SYMBOL{RO}, 3
.string ""
# End csect H.15.NO_SYMBOL{RO}
.llong 0x00000000
# .bss section
Exemple pour Solaris :
.section ".text",#alloc,#execinstr
/* 0x0000 7 */ .file "x.c"
.section ".data",#alloc,#write
/* 0x0000 9 */ .global ss_dba_grp
/* 0x0000 10 */ .align 8
.global ss_dba_grp
ss_dba_grp:
/* 0x0000 17 */ .align 8
/* 0x0000 18 */ .xword (.L12+0)
/* 0x0004 24 */ .align 8
/* 0x0004 25 */ .xword (.L13+0)
/* 0x0008 26 */ .type ss_dba_grp,#object
/* 0x0008 27 */ .size ss_dba_grp,16
.section ".rodata1",#alloc
/* 0x0008 13 */ .align 8
.L12:
/* 0x0008 15 */ .ascii "dba\0"
/* 0x0014 20 */ .align 8
.L13:
/* 0x0014 22 */ .ascii "dba\0"
Dans les exemples ci-dessus, on voit que l'utilisateur est membre du groupe "dba", qui correspond à la valeur de SS_DBA_GRP dans config.c. Si les groupes semblent correctement configurés mais que la connexion échoue toujours, utilisez le script de la Note 67984.1 pour vérifier si Oracle évalue correctement l'appartenance aux groupes.
Des erreurs ora-1031 intermittentes avec l'authentification sysdba par l'OS peuvent être causées par le service nscd, qui met en cache les informations de /etc/passwd et de /etc/group selon la configuration de /etc/nscd.conf. Si l'arrêt de ce service fait disparaître le problème, adressez-vous au fournisseur de l'OS.
Sous Windows
Avec l'authentification par l'OS sous Windows, l'utilisateur de l'OS doit être membre de l'un des deux groupes suivants :
- ORA_DBA
- ORA_<%ORACLE_SID%>_DBA
L'appartenance au second groupe permet à l'utilisateur de l'OS d'utiliser l'authentification par l'OS uniquement pour se connecter à l'instance nommée %ORACLE_SID%>.
Vérifiez si l'utilisateur de l'OS est membre de l'un de ces deux groupes locaux :
Obtenez le nom de l'utilisateur de l'OS :
D:\oracle\product\10.2.0\db_1\NETWORK\ADMIN>echo %username%
dbadmin
Obtenez la liste des membres du groupe local :
D:\oracle\product\10.2.0\db_1\NETWORK\ADMIN>NET LOCALGROUP ORA_DBA
Alias name ORA_DBA
Comment Members can connect to the Oracle database as a DBA without a password
Members
-------------------------------------------------------------------------------
dbadmin
NT AUTHORITY\SYSTEM
The command completed successfully.
D:\oracle\product\10.2.0\db_1\NETWORK\ADMIN>set oracle_sid=d1v10204
D:\oracle\product\10.2.0\db_1\NETWORK\ADMIN>NET LOCALGROUP ORA_%ORACLE_SID%_DBA
Alias name ORA_d1v10204_DBA
Comment Members can connect to instance d1v10204 as a DBA without a password
Members
-------------------------------------------------------------------------------
dbadmin
The command completed successfully.
Si l'utilisateur est membre de ces groupes mais que la connexion échoue toujours, compilez le programme C de la page suivante, puis lancez l'exécutable pour vérifier si Oracle évalue correctement l'appartenance aux groupes :
http://msdn.microsoft.com/en-us/library/aa370655(VS.85).aspx
2. Vérifiez SQLNET.AUTHENTICATION_SERVICES dans SQLNET.ORA
Ce paramètre est défini dans le fichier $ORACLE_HOME/network/admin/SQLNET.ORA.
Sous Unix
Ce paramètre ne doit pas être défini si aucune méthode d'authentification forte n'est utilisée. Si une telle méthode est utilisée, donnez au paramètre l'une des valeurs suivantes :
SQLNET.AUTHENTICATION_SERVICES = (ALL)
ou
SQLNET.AUTHENTICATION_SERVICES = (BEQ,)
où peut être n'importe quelle combinaison des valeurs suivantes : TCPS, KERBEROS5, RADIUS
REMARQUE : si la définition de SQLNET.AUTHENTICATION_SERVICES est précédée d'une espace, une erreur ORA-1031 peut se produire
Sous Windows
Ce paramètre doit être défini à NTS :
SQLNET.AUTHENTICATION_SERVICES = (NTS)
Au besoin, vous pouvez ajouter d'autres méthodes d'authentification forte en plus de NTS :
SQLNET.AUTHENTICATION_SERVICES = (NTS,TCPS)
Remarque : si le paramètre est défini à NONE, l'authentification par l'OS est désactivée et l'utilisateur doit fournir une combinaison nom d'utilisateur/mot de passe valide pour pouvoir se connecter à la base de données.
Comme ci-dessus, si la définition de SQLNET.AUTHENTICATION_SERVICES est précédée d'une espace, une erreur ORA-1031 peut se produire
Remarque :
Sous Windows, l'utilisateur qui ne parvient pas à se connecter en tant que sysdba avec l'authentification par l'OS est peut-être un utilisateur de domaine. Si c'est votre cas, vérifiez les points suivants :
- Cet utilisateur doit absolument être membre direct du groupe local ORA_DBA (consultez la Note 1065023.1 pour plus de détails).
- Le service Oracle doit être démarré par un utilisateur capable de vérifier l'appartenance aux groupes de tout utilisateur de domaine susceptible de se connecter localement en tant que sysdba (consultez la Note 1071638.1 pour plus de détails).
- Vérifiez que les horloges du serveur SGBDR et du serveur Active Directory sont parfaitement synchronisées. Même un léger décalage d'horloge peut perturber le mécanisme d'authentification kerberos sous-jacent, utilisé par défaut sous Windows. Dans ce cas, l'erreur ORA-1031 est le plus souvent intermittente.
- Vérifiez si le service Oracle est démarré par un utilisateur dont le nom contient des caractères non ASCII. Consultez la Note 1280996.1 pour plus de détails
L'erreur ORA-12638 peut apparaître lorsque l'utilisateur est géré dans Active Directory plutôt qu'en local
Sous Windows, lorsque l'utilisateur de l'OS est un utilisateur de domaine, l'erreur obtenue peut être ORA-12638. Dans ce cas, il est important d'obtenir un fichier de trace SQL*Net côté client et d'analyser les erreurs MS Windows rencontrées par la fonction naun5authent :
A) Ajoutez les lignes suivantes au fichier sqlnet.ora du client (le client peut être le serveur SGBDR lui-même) :
trace_level_client = 16
trace_directory_client = c:\temp\newsqlnet
B) Relancez la connexion SYSDBA et récupérez le fichier de trace SQL*Net. Recherchez la chaîne "SSPI" dans ce fichier. Vous verrez quelque chose de semblable à ceci :
[02-OCT-2011 09:21:02:076] naun5authent: SSPI: 0x8009030c error in InitializeSecurityContext
[02-OCT-2011 09:21:02:076] naun5authent: exit
[02-OCT-2011 09:21:02:076] naunauthent: exit
[02-OCT-2011 09:21:02:076] nau_ccn: get credentials function failed
[02-OCT-2011 09:21:02:076] nau_ccn: failed with error 12638
[02-OCT-2011 09:21:02:076] nacomsd: entry
[02-OCT-2011 09:21:02:076] nacomfsd: entry
[02-OCT-2011 09:21:02:076] nacomfsd: exit
[02-OCT-2011 09:21:02:076] nacomsd: exit
[02-OCT-2011 09:21:02:076] nau_ccn: exit
[02-OCT-2011 09:21:02:076] na_csrd: failed with error 12638
[02-OCT-2011 09:21:02:076] na_csrd: exit
[02-OCT-2011 09:21:02:076] nacomer: error 12638 received from authentication service
C) Recherchez l'erreur MS (0x8009030c dans l'exemple ci-dessus) dans la page suivante :
http://technet.microsoft.com/en-us/library/cc786775%28WS.10%29.aspx
D) Communiquez avec les administrateurs AD pour qu'ils effectuent les actions recommandées par Microsoft. Pour l'erreur SSPI ci-dessus, la solution est la suivante :
"Logon Denied. La stratégie de groupe (Group Policy) emprunte l'identité de l'ordinateur et de l'utilisateur lorsqu'elle détermine l'étendue de la stratégie : elle agit donc au nom de l'utilisateur. Il peut s'agir d'un compte d'ordinateur dont le mot de passe doit être réinitialisé ou d'un compte d'utilisateur qui présente un problème. Vérifiez dans Active Directory que le compte d'utilisateur est correctement configuré. Utilisez un utilitaire comme netdom ou nltest pour tester le mot de passe du compte d'ordinateur."
3. Passez en revue les problèmes décrits dans les notes suivantes
Faites-le après avoir vérifié la configuration selon les étapes 1) et 2).
Note 69642.1 - UNIX : liste de vérification pour résoudre les problèmes de connexion AS SYSDBA
Note 114384.1 - WIN : liste de vérification pour résoudre les problèmes de CONNECT AS SYSDBA (INTERNAL)
4. Ouvrez une demande de service auprès d'Oracle Support
Si le problème persiste après la lecture de ces notes, ouvrez une demande de service en fournissant les informations suivantes.
Pour Unix
A) Le fichier $ORACLE_HOME/network/admin/sqlnet.ora
B) Le fichier $ORACLE_HOME/rdbms/lib/config.c (ou config.s)
C) La sortie de la commande "id"
D) Un fichier de trace obtenu avec les commandes suivantes :
Linux:
strace -o /tmp/strace_sysdba.output -cfT sqlplus / as sysdba
AIX, Solaris:
truss -fea -o /tmp/truss_sysdba.output sqlplus / as sysdba
HP-UX:
tusc -afpo /tmp/tusc_sysdba.output -aef sqlplus / as sysdba
Pour Windows
A) Le fichier %ORACLE_HOME%/network/admin/sqlnet.ora
B) La sortie des commandes "echo %username% et "NET LOCALGROUP ORA_DBA"
C) Une paire de traces SQL*Net client/serveur obtenues en reproduisant le problème selon la Note 395525.1 et la Note 374116.1.
Dépanner ORA-1031 avec l'authentification par fichier de mots de passe
1. Vérifiez la valeur du paramètre remote_login_passwordfile
Elle doit être EXCLUSIVE ou SHARED.
SQL> show parameter remote_login_passwordfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
remote_login_passwordfile string EXCLUSIVE
Si le paramètre n'est pas correctement défini, modifiez-le, puis redémarrez la base de données :
SQL> ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;
2. Vérifiez le fichier de mots de passe et ses permissions
Le fichier de mots de passe portant le bon nom doit exister dans le bon répertoire/dossier, avec le bon propriétaire et les bonnes permissions.
Sous Unix
Le fichier de mots de passe nommé orapw<ORACLE_SID> doit exister dans le répertoire $ORACLE_HOME/dbs. S'il n'existe pas, recréez-le avec la commande orapwd
$ > orapwd file=$ORACLE_HOME/dbs/orapw<sid> password=<password> force=y ignorecase=n
Les permissions du fichier doivent être les suivantes :
-rw-r----- 1 oracle oinstall 1536 Jul 21 13:50 orapwdv11201
Vous trouverez plus d'informations sur l'utilisation de la commande orapwd dans la Note 1029539.6.
Sous Windows
Sous Windows, l'emplacement par défaut du fichier de mots de passe est le dossier %ORACLE_HOME%/database, et ce fichier doit se nommer pwd<%ORACLE_SID%>.ora. Lorsque l'authentification par fichier de mots de passe est utilisée, Oracle recherche le fichier de mots de passe aux emplacements suivants (dans cet ordre précis) :
- Le dossier indiqué par la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HomeXX\ORA_<%ORACLE_SID%>_PWFILE
- Le dossier indiqué par la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HomeXX\ORA_PWFILE
- L'emplacement par défaut ( %ORACLE_HOME%/database)
Remarque : si ces clés de registre sont définies, assurez-vous que le fichier de mots de passe existe dans le dossier qu'elles indiquent.
Si le fichier de mots de passe n'existe pas dans le bon dossier, créez-le avec la commande orapwd :
D:\> cd %ORACLE_HOME/database
D:\> orapwd file=pwd<sid>.ora password=<password> force=y nosysdba=n
Vous trouverez plus d'informations sur l'utilisation de la commande orapwd dans la Note 1029539.6.
3. Vérifiez que le privilège SYSDBA a été accordé à l'utilisateur
SQL> select * from v$pwfile_users;
USERNAME SYSDB SYSOP SYSAS
------------------------------ ----- ----- -----
SYS TRUE TRUE FALSE
Si le privilège n'a pas été accordé à l'utilisateur, exécutez :
grant SYSDBA to myadminuser;
où myadminuser est l'utilisateur avec lequel vous voulez vous connecter en tant que sysdba.
4. Vérifiez la configuration du listener de la base de données.
La valeur du paramètre ORACLE_HOME dans la définition du listener doit être correctement indiquée :
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = d1v11203)
(ORACLE_HOME = /oracle/product/11203)
(SID_NAME = d1v11203)
)
)
La casse du SID dans la définition du listener doit correspondre à celle du nom d'instance indiqué par ORACLE_SID :
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = d1v11203)
(ORACLE_HOME = /oracle/product/11203)
(SID_NAME = d1v11203)
)
)
Problèmes fréquents d'authentification par fichier de mots de passe
1) ORA-1031 intermittente en SYSDBA avec équilibrage de charge TNS
Une connexion à distance AS SYSDBA à un alias TNS défini avec plusieurs adresses TNS et l'équilibrage de charge échoue de façon intermittente avec ORA-1031.
L'alias TNS est défini ainsi dans tnsnames.ora :
CLIENT_load_balance=
(DESCRIPTION =
(LOAD_BALANCE = yes)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ro-rac1.ro.oracle.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = ro-rac2.ro.oracle.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = service.idc.oracle.com)
)
)
Si au moins un nœud a un fichier de mots de passe mal configuré, cette erreur apparaîtra de façon intermittente. Assurez-vous que le fichier de mots de passe est correctement configuré sur tous les nœuds.
2) Les connexions auxiliaires RMAN échouent avec l'erreur suivante
RMAN-04006: error from auxiliary database: ORA-01031: insufficient privileges
Avant d'exécuter la commande RMAN, assurez-vous que le fichier de mots de passe est correctement configuré pour la base de données auxiliaire distante.
3) EM dépend des connexions à distance en SYSDBA
La configuration et le bon fonctionnement d'EM dépendent de la capacité à se connecter à distance en tant que sysdba. Par exemple, lors de l'installation d'EM, ces erreurs peuvent apparaître dans le fichier emca_repos_config_yyyy_mm_dd_hh_mm_ss.log.
Caused by: oracle.sysman.emdrep.config.ConfigurationException:
Cannot Create Connection:(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=testemconfig.us.oracle.com)(PORT=1553)))(CONNECT_DATA=(SERVICE_NAME=TESTDB)))
SYS
sysdba
ORA-01031: insufficient privileges
Ce problème peut être reproduit dans sqlplus :
[oracle@test dbs]$ sqlplus sys/oracle@r01 as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jun 7 16:02:39 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
Pour y remédier, suivez les étapes de dépannage de l'authentification sysdba par fichier de mots de passe.