案例：12.2环境用户登录错误ORA-01017
案例：12.2环境用户登录错误ORA-01017
Keyword: ORA-01017 12.2 authentication SQLNET.AUTHENTICATION_SERVICES sec_case_sensitive_logon
客户的问题
某客户报告在登录数据库时发生ORA-01017错误，无法登录数据库； 而且即使修改密码后用正确的密码也无法登录。
SQL> alter user system identified by manager;
SQL> conn system/manager@IDENTISTRING
ERROR:
ORA-01017: invalid username/password; logon denied
用户的数据库环境信息如下：
Microsoft Windows x64 (64-bit) 2012 R2
Oracle Database 12.2
Single Instance
澄清问题和核实问题
首先通过用户的描述，我们可以明确本次问题关键是解决ORA-01017错误的问题。 我们可以从用户提供的应用程序日志和提供的日志文件中确认到如下的输出：
SQL> alter user system identified by manager;
SQL> conn system/manager@IDENTISTRING
ERROR:
ORA-01017: invalid username/password; logon denied
即刚刚修改密码后用正确的密码也无法登录。
从何着手？
根据用户描述，本次发生问题时错误号为ORA-01017, 对于出现Oracle错误号的问题，首先的关注点应该是错误号。
了解ORA-01017错误的含义，和一般的解决方法。
$ oerr ora 1017
01017, 00000, "invalid username/password; logon denied"
// *Cause:
// *Action:
根据上面的输出，我们可以了解到该错误通常是用户的密码错误导致的, 但是因为用户刚刚修改过密码，用户的密码是不可能有问题的， 所以我们需要考虑其他的一些因素。
理清问题后的调查和探究（Research ）
现在我们面临着以下的一些问题：
本次用户发生问题的特点是什么？
还需要确认什么有用的信息？
有什么异常的点？
所有的信息有什么关联？
都有哪些可能原因能够引起本次问题？
我们可以看到这次问题有如下的特点：
1.用户使用的是Listener登录
2.登录用户名使用的是system,没有使用as sysdba 或者其他as ..特殊用户登录
3.用户的环境是Windows，并且使用的数据库是最新的12.2
根据上面的特点，结合数据库相关的知识，我们可以做出以下的推论：
1.当使用Listener登录时候，没有使用as sysdba 或者其他as ..特殊用户登录时，
用户使用的应该是存储在字典表（Dictionary）中的密码
2.因为是最新的12.2版本，所以有可能是某些新特性或者改变导致问题发生。
3.为了查看存储密码的特点和用户的特点，我们需要查看下字典表中信息以及通过Listener登录时用到的网络配置相关的文件。
信息收集(Data Collection)
为了进一步确认发生的事件详细，我们需要进一步去查看相关的配置。
・确认以下的内容：
・普通用户是否也出现相同的问题？
・BEQ 的方式（不利用Listener）是否能够正常连接？
・最近对于服务器是否有什么变更操作？
・以下视图的内容
SQL> select * from v$pwfile_users;
SQL> select * from dba_profiles;
SQL> select * from dba_users order by username;
・相关初期化参数的设定
SQL> show parameter sec_case_sensitive_logon
SQL> show parameter remote
・服务器和客户端的下列文件
$ORACLE_HOME/network/admin
sqlnet.ora、listener.ora、tnsnames.ora
根据用户提供的信息和数据我们确认到：
・这个问题是在用户升级到12.2版本后发生的。
・变更操作是为了
・<服务器sqlnet.ora的配置如下>
▼sqlnet.ora
# SQLNET.AUTHENTICATION_SERVICES = (NTS)
即没有添加什么特别的配置，都是用的默认值。
・查看相关视图：
SQL> select * from dba_users order by username;
USERNAME USER_ID PASSWORD ACCOUNT_STATUS LOCK_DAT EXPIRY_D DEFAULT_TABLESPACE TEMPORARY_TABLESPACE LOCAL_TEMP_TABLESPACE CREATED PROFILE
INITIAL_RSRC_CONSUMER_GROUP EXTERNAL_NAME PASSWORD_VERSIONS E AUTHENTI P COM LAST_LOGIN O INH DEFAULT_COLLATION IMP ALL
SYSTEM 9 OPEN 2017/10/21 SYSTEM TEMP TEMP 2017/4/20 DEFAULT
SYS_GROUP 11G 12C N PASSWORD N YES 17-04-22 12:25:53.000000000 +09:00★
根据dba_users视图的输出，可以看到PASSWORD_VERSIONS为11G 12C，并且过去有过正常登陆的记录（17-04-22 12:25:53）。
・查看sec_case_sensitive_logon和remote_login_passwordfile的设置
sec_case_sensitive_logon = FALSE
remote_login_passwordfile= "EXCLUSIVE"
・查看告警日志的正常登陆的记录（17-04-22 12:25:53）前后的内容
▼alert_XXX.log
...
2017-04-22T12:28:33.366072+09:00
ALTER SYSTEM SET sec_case_sensitive_logon=FALSE SCOPE=SPFILE; ★
...
2017-04-22T12:32:45.703621+09:00
Starting ORACLE instance (normal) (OS id: 2512)
...
System parameters with non-default values:
...
sec_case_sensitive_logon = FALSE
...
Deprecated system parameters with specified values: ★
sec_case_sensitive_logon
我们发现4/22 12:28用户对sec_case_sensitive_logon参数进行了变更，之后数据库就无法用密码登录了。
理清问题后的调查和探究（Research ）
根据收集的信息，我们可以推论：
・这次现象和sec_case_sensitive_logon的变更有很大的关系
・有可能和12.2有关系，貌似也可能和PASSWORD_VERSIONS有关系
对于sec_case_sensitive_logon参数，通过Research ，我们知道：
在Oracle 数据库11g版本之前，对于密码的验证是不区分大小写的。
从11g开始，对于用户密码的安全性进行了强化，引进了Case Sensitive Passwords（大小写敏感）功能。
因此，Oracle 11g开始新做成或者变更用户密码时，默认是大小有效的。
为了兼容以前的版本，对于Case Sensitive Passwords功能，可以由初始化参数SEC_CASE_SENSITIVE_LOGON进行控制（11g以后的版本默认该功能有效）
关键的一点是，当初期化参数sec_case_sensitive_logon设定为false 时，用户的密码验证只能使用PASSWORD_VERSIONS版本为10g的密码Has值。
问题基本已经明确，但是有一点，在以前的版本即使修改sec_case_sensitive_logon=false都能够登录，为什么升级12.2才会有这个问题？
查看Online 文档，我们可以知道：
数据库登录用户的密码生成时，会根据sqlnet.ora 文件中SQLNET.ALLOWED_LOGON_VERSION_SERVER配置而不同。
・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的设定不兼容.
参考：
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)
原因认定和原因认定的理由（CD & CJ）
根据上面的调查结果，我们可以判断本次现象的原因是由于12.2版本上SQLNET.ALLOWED_LOGON_VERSION_SERVER和SEC_CASE_SENSITIVE_LOGON=FALSE的设定不兼容导致的。
推荐的解决方案和推荐的理由（PS & PJ）
我们知道在12c以后的版本为了更强的密码安全性，SEC_CASE_SENSITIVE_LOGON参数只是为了以前版本的兼容性而残留，已经不再推荐使用。
Oracle Database Online Documentation 12c Release 1 (12.1)
Database Upgrade Guide
https://docs.oracle.com/database/121/UPGRD/deprecated.htm#UPGRD60000
>8.1.5.2 SEC_CASE_SENSITIVE_LOGON
>The SEC_CASE_SENSITIVE_LOGON initialization parameter is deprecated in this release.
所以最推荐的解决方案是，不要设定SEC_CASE_SENSITIVE_LOGON=FALSE。
但是由于用户的业务特殊性，不想区分密码的大小写，为了能够正常登陆，可以sqlnet.ora 文件中SQLNET.ALLOWED_LOGON_VERSION_SERVER配置值为10或者11，以生成PASSWORD_VERSIONS版本为10g的密码Has值供认证使用。
例：
▼sqlnet.ora
SQLNET.ALLOWED_LOGON_VERSION_SERVER=11
需要注意的是，在修改sqlnet.ora 文件中SQLNET.ALLOWED_LOGON_VERSION_SERVER配置后，需要再变更一次密码以便生成新的密码。
例：
SQL> alter user <UserName> identified by <NewPassword>;
对于这个问题，在MOS中Doc ID 2040705.1中也有类似的记述。
参考：
Lockout of all database authenticated users getting error ORA-01017: invalid username/password; logon denied (Doc ID 2040705.1)
知识点总结（KM）
通过本次案例， 我们详细描述了解决问题的思路和过程，并介绍了以下的知识点。
・11g 大小写敏感功能和sec_case_sensitive_logon参数
・12c之后的密码强化（Password Version Exclusively）
通过上面我们也可以知道MOS上的文档，不是凭空写出来的，也是对用户的问题以及基础的数据库技术知识的理解和推理写出来的。 拥有坚实的基础知识和良好的推理能力才是结局问题的根本。