What happens to PASSWORD_VERSIONS during an upgrade to Oracle 12.2?

I did blog a day ago about ORA-1017 connection issues in Oracle Database 12.2 once you would like to use the deprecated init.ora/spfile parameter SEC_CASE_SENSITIVE_LOGON=FALSE:

But how can this change actually happen?

Let’s check how the PASSWORD_VERSIONS is set in a fresh Oracle Database 12.1.0.2 database with the January 2017 Proactive Bundle Patch applied to it:

SQL> select username, password_versions from dba_users order by 1;

USERNAME		       PASSWORD_VERSIONS
------------------------------ -----------------
ANONYMOUS
APPQOSSYS		       10G 11G 12C
AUDSYS			       10G 11G 12C
DBSNMP			       10G 11G 12C
DIP			       10G 11G 12C
GSMADMIN_INTERNAL	       10G 11G 12C
GSMCATUSER		       10G 11G 12C
GSMUSER 		       10G 11G 12C
ORACLE_OCM		       10G 11G 12C
OUTLN			       10G 11G 12C
SYS			       10G 11G 12C
SYSBACKUP		       10G 11G 12C
SYSDG			       10G 11G 12C
SYSKM			       10G 11G 12C
SYSTEM			       10G 11G 12C
WMSYS			       10G 11G 12C
XDB			       10G 11G 12C
XS$NULL

18 rows selected.

As I haven’t touched SEC_CASE_SENSITIVE_LOGON it will will default to TRUE. In my environment I use an Oracle 12.2 listener  therefore the default for the sqlnet.ora parameter SQLNET.ALLOWED_LOGON_VERSION_SERVER is 12 already.

After the successful upgrade to Oracle Database 12.2 my DBA_USER’s PASSWORD_VERSIONS looks like this:

SQL> select USERNAME, PASSWORD_VERSIONS from DBA_USERS order by 1

USERNAME		       PASSWORD_VERSIONS
------------------------------ -----------------
ANONYMOUS
APPQOSSYS		       10G 11G 12C
AUDSYS			       10G 11G 12C
DBSFWUSER		       11G 12C
DBSNMP			       10G 11G 12C
DIP			       10G 11G 12C
GGSYS			       11G 12C
GSMADMIN_INTERNAL	       10G 11G 12C
GSMCATUSER		       10G 11G 12C
GSMUSER 		       10G 11G 12C
ORACLE_OCM		       10G 11G 12C
OUTLN			       10G 11G 12C
REMOTE_SCHEDULER_AGENT
SYS			       10G 11G 12C
SYS$UMF 		       11G 12C
SYSBACKUP		       10G 11G 12C
SYSDG			       10G 11G 12C
SYSKM			       10G 11G 12C
SYSRAC			       11G 12C
SYSTEM			       10G 11G 12C
WMSYS			       10G 11G 12C
XDB			       10G 11G 12C
XS$NULL

23 rows selected.

None of the existing user account’s PASSWORD_VERSIONS get changed. Only new users will be created with either PASSWORD_VERSIONS11G 12C” or locked.

Upgrading with SEC_CASE_SENSITIVE_LOGON=FALSE

What happens if you have set SEC_CASE_SENSITIVE_LOGON=FALSE in your source database prior to an upgrade to Oracle Database 12.2?

First of all you will receive a preupgrade warning when you execute preupgrade.jar:

  RECOMMENDED ACTIONS
  ===================
   + Consider removing the following DEPRECATED initialization parameters.
     They are not OBSOLETE in version 12.2.0.1.0
     but probably will be OBSOLETE in a future release.

     Parameter
     ------------------------------
     sec_case_sensitive_logon

My users in my current – in this case Oracle 11.2.0.4 database – look like this before upgrade:

SQL> select username, password_versions from dba_users

USERNAME		       PASSWORD
------------------------------ --------
SYSTEM			       10G 11G
SYS			       10G 11G
LBACSYS 		       10G 11G
OUTLN			       10G 11G
DBSNMP			       10G 11G
APPQOSSYS		       10G 11G
ANONYMOUS
XDB			       10G 11G
WMSYS			       10G 11G
XS$NULL 		       11G
DIP			       10G 11G
ORACLE_OCM		       10G 11G

12 rows selected.

And the result is “as expected” – no changes to the PASSWORD_VERSIONS when you upgrade to Oracle Database 12.2:

USERNAME		       PASSWORD_VERSIONS
------------------------------ -----------------
ANONYMOUS
APPQOSSYS		       10G 11G
AUDSYS			       11G 12C
DBSFWUSER		       11G 12C
DBSNMP			       10G 11G
DIP			       10G 11G
GGSYS			       11G 12C
GSMADMIN_INTERNAL	       11G 12C
GSMCATUSER		       11G 12C
GSMUSER 		       11G 12C
LBACSYS 		       10G 11G
ORACLE_OCM		       10G 11G
OUTLN			       10G 11G
REMOTE_SCHEDULER_AGENT
SYS			       10G 11G
SYS$UMF 		       11G 12C
SYSBACKUP		       11G 12C
SYSDG			       11G 12C
SYSKM			       11G 12C
SYSRAC			       11G 12C
SYSTEM			       10G 11G
WMSYS			       10G 11G
XDB			       10G 11G
XS$NULL

24 rows selected.

But what happens when you try to connect now with user SYSTEM? SYSTEM has the PASSWORD_VERSIONS="10G 11G" as only the new users will get created with PASSWORD_VERSIONS="11G 12C".

SQL> connect system/oracle
ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

Even if you ALTER now SYSTEM‘s password you can’t login as the SEC_CASE_SENSITIVE_LOGON=FALSE setting collides with the default SQL*Net authentication protocol (SQLNET.ALLOWED_LOGON_VERSION_SERVER=12).

SQL> alter user system identified by system;
User altered.

SQL> connect system/system
ERROR:
ORA-01017: invalid username/password; logon denied

SYSTEM‘s password is now "11G 12C" – but still you can’t connect because of the SEC_CASE_SENSITIVE_LOGON=FALSE setting:

SQL> select USERNAME, PASSWORD_VERSIONS from DBA_USERS where USERNAME='SYSTEM';

USERNAME		       PASSWORD_VERSIONS
------------------------------ -----------------
SYSTEM			       11G 12C

Simple solution: You change SEC_CASE_SENSITIVE_LOGON=TRUE, the default.

SQL> alter system set sec_case_sensitive_logon=true;
System altered.

SQL> alter user system identified by oracle;
User altered.

SQL> connect system/oracle
Connected.

Or you use the workaround from my previous blog post:

What happens during export/import?

Next question I’ve had: What happens if I export and import a user, let’s say from Oracle Database 11.2.0.4 into Oracle Database 12.2.0.1. Quick test again:

SQL> grant connect, resource, dba to hugo identified by hugo;
Grant succeeded.

SQL>  select USERNAME, PASSWORD_VERSIONS from DBA_USERS where username='HUGO';

USERNAME		       PASSWORD
------------------------------ --------
HUGO			       10G 11G

SQL> alter user hugo default tablespace users;
User altered.

SQL> create table hugo.tab1 as select * from tab$;
Table created.

Then over to my destination database:

SQL> create directory mydir as '/u02/oradata/DB12/mydir';
Directory created.

SQL> grant read, write on directory mydir to system;
Grant succeeded.

SQL> create public database link SOURCEDB connect to system identified by oracle using 'UPGR';
Database link created.

SQL> select instance from v$thread@SOURCEDB;

INSTANCE
--------------------------------------------------------------------------------
UPGR

Now let’s move HUGO over to the DB12 database using the database link:

$ impdp system/oracle network_link=sourcedb schemas=hugo metrics=y logtime=all exclude=statistics directory=mydir logfile=hugo.log 

Import: Release 12.2.0.1.0 - Production on Mon Apr 24 15:34:48 2017

Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
24-APR-17 15:34:54.082: Starting "SYSTEM"."SYS_IMPORT_SCHEMA_01":  system/******** network_link=sourcedb schemas=hugo metrics=y logtime=all exclude=statistics directory=mydir logfile=hugo.log 
24-APR-17 15:34:55.181: W-1 Startup took 2 seconds
24-APR-17 15:34:55.299: W-1 Estimate in progress using BLOCKS method...
24-APR-17 15:34:56.428: W-1 Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
24-APR-17 15:34:56.485: W-1      Estimated 1 TABLE_DATA objects in 1 seconds
24-APR-17 15:34:56.490: W-1 Total estimation using BLOCKS method: 256 KB
24-APR-17 15:34:56.807: W-1 Processing object type SCHEMA_EXPORT/USER
24-APR-17 15:34:56.975: W-1      Completed 1 USER objects in 0 seconds
24-APR-17 15:34:56.975: W-1 Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
24-APR-17 15:34:57.014: W-1      Completed 1 SYSTEM_GRANT objects in 1 seconds
24-APR-17 15:34:57.014: W-1 Processing object type SCHEMA_EXPORT/ROLE_GRANT
24-APR-17 15:34:57.095: W-1      Completed 3 ROLE_GRANT objects in 1 seconds
24-APR-17 15:34:57.095: W-1 Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
24-APR-17 15:34:57.385: W-1      Completed 1 DEFAULT_ROLE objects in 0 seconds
24-APR-17 15:34:57.385: W-1 Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
24-APR-17 15:35:00.257: W-1      Completed 1 PROCACT_SCHEMA objects in 3 seconds
24-APR-17 15:35:00.257: W-1 Processing object type SCHEMA_EXPORT/TABLE/TABLE
24-APR-17 15:35:01.646: W-1      Completed 1 TABLE objects in 4 seconds
24-APR-17 15:35:01.841: W-1 . . imported "HUGO"."TAB1"                                 1325 rows in 0 seconds using network link
24-APR-17 15:35:02.015: W-1 Processing object type SCHEMA_EXPORT/POST_SCHEMA/PROCACT_SCHEMA
24-APR-17 15:35:02.106: W-1      Completed 1 PROCACT_SCHEMA objects in 0 seconds
24-APR-17 15:35:02.495: W-1      Completed 1 SCHEMA_EXPORT/TABLE/TABLE_DATA objects in 0 seconds
24-APR-17 15:35:02.609: Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully completed at Mon Apr 24 15:35:02 2017 elapsed 0 00:00:10

Check how the user got created:

SQL>  select USERNAME, PASSWORD_VERSIONS from DBA_USERS where username='HUGO';

USERNAME                     PASSWORD_VERSIONS
---------------------------- --------------------
HUGO                         10G 11G

No worries – Data Pump creates the user exactly as it did exist before.

But what happens if a mandatory password change happens to HUGO?

SQL> alter user hugo identified by hugo;
User altered.

SQL> select USERNAME, PASSWORD_VERSIONS from DBA_USERS where username='HUGO';

USERNAME		       PASSWORD_VERSIONS
------------------------------ -----------------
HUGO			       11G 12C

If you change SQLNET.ALLOWED_LOGON_VERSION_SERVER to 12a, the currently highest and most secure setting, and then ALTER the user within a new session, you’ll receive:

SQL> select USERNAME, PASSWORD_VERSIONS from DBA_USERS where username='HUGO'

USERNAME		       PASSWORD_VERSIONS
------------------------------ -----------------
HUGO			       12C

This leads now to the situation that a below-Oracle-12c client can’t connect to this database anymore. I tried to use my SQL*Plus from the Oracle 11.2.0.4 installation:

$ sqlplus "hugo/hugo@DB12"

SQL*Plus: Release 11.2.0.4.0 Production on Mon Apr 24 15:51:08 2017
Copyright (c) 1982, 2013, Oracle.  All rights reserved.

ERROR:
ORA-28040: No matching authentication protocol

So be aware of keepin your client environment in good shape when enforcing higher security standards – which we highly recommend of course.

–Mike

Share this: