【数据库管理】ORA-01017错误及部分的常见典型案例

$ oerr ora 1017
01017, 00000, "invalid username/password; logon denied"
// *Cause:
// *Action:

即用户名/口令无效从而登录被拒绝，一般的解决方法为修改密码，用正确的密码登录。

如：用系统用户登录系统，修改用户的密码。

sqlplus / as sysdba
alter user <UserName> identified by <NewPassword>;

除了一般的情况外，在数据库登录时还会有很多情况也报这个错误，本文将介绍对于ORA-01017错误问题的基本对应思路和一些典型的案例。

##解决ORA-01017错误的基本思路

解决ORA-01017错误的基本思路如下：

・用户名和密码是否是真的正确
・注意用户的特点，如是否是特权用户或一些特殊性
・注意数据库的版本，是否是由于某些版本的新特性导致的无法登录
・查看是否使用了Listener监听登陆，在BEQ登陆的方式下是否有同样的问题
・确认验证密码时使用的是数据库中存储的密码还是密码文件（password file）中的密码
・查看网络相关的配置文件sqlnet.ora、listener.ora、tnsnames.ora的配置
・查看告警日志alert和trace中，发生问题时是否有其他的错误或异常发生
・通过设定errorstack来进一步查看问题发生时的详细信息，诊断由于Bug等导致的问题

##一般需要查看的文件和信息

我们可以通过取得下面的信息，来确认相关的设定：

・以下视图的内容	
	select * from v$pwfile_users;
	select * from dba_profiles;
	select * from dba_users order by username;

・相关初期化参数的设定
	show parameter sec_case_sensitive_logon
	show parameter remote
	
・服务器和客户端的下列文件
	$ORACLE_HOME/network/admin
	sqlnet.ora、listener.ora、tnsnames.ora
	
・服务器环境的设定情况

	SQL> conn /as sysdba
	SQL> ho set
	
・设定errorstack来进一步查看问题发生时的详细信息
	
	例：
	SQL> conn /as sysdba
	SQL> set time on
	SQL> alter system set events '1017 trace name errorstack level 3';
	SQL> conn TEST/TEST@NGYTEST5

・警日志alert和相关的trace

##案例1：由于密码强化导致到ORA-01017错误（11g Case Sensitive）

在Oracle 数据库11g版本之前，对于密码的验证是不区分大小写的，从11g开始，对于用户密码的安全性进行了强化，引进了Case Sensitive Passwords（大小写敏感）功能。

因此，Oracle 11g开始新做成或者变更用户密码时，默认是大小有效的。

为了兼容以前的版本，对于Case Sensitive Passwords功能，可以由初始化参数SEC_CASE_SENSITIVE_LOGON进行控制（11g以后的版本默认该功能有效）。

例：

--大小写敏感有效
SQL> alter system set sec_case_sensitive_logon = true;
--大小写敏感无效
SQL> alter system set sec_case_sensitive_logon = false;

在前面的版本能够正常运行但是升级到11g版本后，发生ORA-01017错误无法登录时，需要注意这个参数的设置。

如果是由于这个功能引起的ORA-01017错误无法登录，可以考虑修改应用程序的密码或者将该功能禁用。

参考：（MOS文档）

ORA-1017 When Connecting to an 11g Oracle Database (Doc ID 462713.1)
[11g新機能] Case Sensitive Passwords について(KROWN:127696) (Doc ID 1741990.1)
11gR1 New Feature: Case-Sensitive Passwords and Strong User Authentication (Doc ID 429465.1)
How To Enforce Mixed Case Passwords When sec_case_sensitive_logon = true? (Doc ID 1307555.1)

##案例2：密码文件（password file）的大小写导致的ORA-01017

在过去的案例中，有用户报告，虽然把初始化参数SEC_CASE_SENSITIVE_LOGON设为FALSE,但是依然无法禁用大小写敏感的功能。
针对这种情况我们需要考虑，用户是否通过Linstener监听访问的，是否是使用的密码文件进行验证的？

初始化参数SEC_CASE_SENSITIVE_LOGON不会影响密码文件（password file）的大小写敏感设定（默认有效），要想控制密码文件（password file）的大小写敏感设定，我们需要通过ORAPWD 工具的ignorecase 参数进行控制。

例：

	--大小写敏感禁用 ignorecase=y
$orapwd file=<ORACLE_HOME>\database\PWD<ORACLE_SID>.ora ignorecase=y password=<password> force=y

	--大小写敏感有效 ignorecase=n
$orapwd file=<ORACLE_HOME>\database\PWD<ORACLE_SID>.ora ignorecase=n password=<password> force=y

※其中<ORACLE_HOME>指定ORACLE_HOME
 <ORACLE_SID>指定ORACLE_SID
 <password>指定新的密码

参考：

Database Administrator’s Guide
http://docs.oracle.com/database/121/ADMIN/dba.htm#GUID-1333CAF4-BA95-4C01-BC61-BB3949FF965F
>1.7.1 ORAPWD Syntax and Command Line Argument Descriptions

##案例3：由于密码强化导致到ORA-01017错误（12.1/12.2 Password Version Exclusively）

数据库登录用户的密码生成时，会根据sqlnet.ora 文件中SQLNET.ALLOWED_LOGON_VERSION_SERVER配置而不同。

例：如果SQLNET.ALLOWED_LOGON_VERSION_SERVER配置为12时，这时的密码认证协议为独家模式（Exclusive Mode），在这种情况下生成的Password Version为11G, 12C。
如果SQLNET.ALLOWED_LOGON_VERSION_SERVER配置为12a时，生成的Password Version会更为严格，为12C。

※Password Version：即在进行密码验证时，可以进行匹配的密码Hash值列表，可以通过DBA_USERS.PASSWORD_VERSIONS进行查看。

而当初期化参数sec_case_sensitive_logon设定为false 时，用户的密码验证只能使用Password Version版本为10g的密码Has值。

所以，如果SQLNET.ALLOWED_LOGON_VERSION_SERVER=12（或者12C）和SEC_CASE_SENSITIVE_LOGON=FALSE 同时设定时，会由于设置的密码和验证密码时的密码值不兼容，导致无法正确验证密码，从而发生ORA-01017错误。

※注意：

12.1的环境中SQLNET.ALLOWED_LOGON_VERSION_SERVER的默认值为11，
默认可以和SEC_CASE_SENSITIVE_LOGON=FALSE的设定兼容.
12.2的环境中SQLNET.ALLOWED_LOGON_VERSION_SERVER的默认值为12，
默认与SEC_CASE_SENSITIVE_LOGON=FALSE的设定不兼容.

因此，在前面的版本能够正常运行但是升级到12.1/12.2版本后，发生ORA-01017错误无法登录时，需要注意这两个参数的设置。

对于这个问题的解决方法：

1.SEC_CASE_SENSITIVE_LOGON=FALSE的设定不变的情况下，sqlnet.ora 文件中SQLNET.ALLOWED_LOGON_VERSION_SERVER的设定值设为10或者11.（出于安全级别考虑不推荐）
例：
	SQLNET.ALLOWED_LOGON_VERSION_SERVER=11
	SQLNET.ALLOWED_LOGON_VERSION_SERVER=10

或者

2.SEC_CASE_SENSITIVE_LOGON设为TRUE.
例：
	ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON=TRUE;

参考：

Database Security Guide
http://docs.oracle.com/database/122/DBSEG/release-changes.htm#GUID-CFD9CD67-9253-409B-A387-38CF515D86F3
>Better Security for Password Versions

Database Net Services Reference(12.1)
http://docs.oracle.com/database/121/NETRF/sqlnet.htm#NETRF2016
>SQLNET.ALLOWED_LOGON_VERSION_SERVER
...
>11 for Oracle Database 11g authentication protocols (default)

Database Net Services Reference(12.2)
https://docs.oracle.com/database/122/NETRF/parameters-for-the-sqlnet-ora-file.htm#NETRF2016
>5.2.18 SQLNET.ALLOWED_LOGON_VERSION_SERVER
... 
>12 for Oracle Database 12c release 12.1 authentication protocols (default and recommended value)

Lockout of all database authenticated users getting error ORA-01017: invalid username/password; logon denied (Doc ID 2040705.1)
The new Exclusive Mode default for password-based authentication in Oracle 12.2 conflicts with case-insensitive password configurations. (Doc ID 2075401.1)

##案例4：某些特殊用户无法通过Listener登录（AS SYSRAC 12.2 ）

在数据库中，有一类用于分离sysdba职责的用户，称为SOD users（Separation Of Duties），如赋予SYSDG、SYSBACKUP和SYSKM角色用户。

在12.2版本后又新追加了一个SYSRAC角色用于管理RAC相关的功能。
由于处于安全性的考虑，SYSRAC角色用户不能够追加到密码文件中，所以是不可以通过Listener登录进行登录的。这个是期望的动作，无法改变。

在12.2.0.1：

$ sqlplus sysrac/sysrac@cdb1 as sysrac

 SQL*Plus: Release 12.2.0.1.0 Production on Tue Jun 20 01:07:21 2017
 Copyright (c) 1982, 2016, Oracle.  All rights reserved.

 ERROR:
 ORA-01017: "invalid username/password; logon denied 
 
 ※事实上，这种情况本来应该报ORA-1031 错误，但是由于内部的bug导致报了ORA-01017错误，在以后的版本应该能够得到修正。

参考：

Administrator's Reference for Linux and UNIX-Based Operating Systems
http://docs.oracle.com/database/122/UNXAR/release-changes.htm#GUID-3ABF7DDF-9F7B-4A4F-9DA3-6B748B91CBC1
>New Administrator Role

Database Administrator’s Guide
http://docs.oracle.com/database/122/ADMIN/getting-started-with-database-administration.htm#ADMIN-GUID-79AB6187-1522-4EB7-8FAD-E4322262AC65
>SYSRAC facilitates Oracle Real Application Clusters (Oracle RAC) operations by connecting to the database by the Clusterware agent on behalf of Oracle RAC utilities such as SRVCTL.
>The SYSRAC administrative privilege cannot be granted to database users and is not supported in a password file. ★
>The SYSRAC administrative privilege is used only by the Oracle agent of Oracle Clusterware to connect to the database using operating system authentication.★

版权声明：本文为博主原创文章，转载必须注明出处，本人保留一切相关权力！http://blog.csdn.net/lukeunique

欢迎关注微信订阅号：TeacherWhat