11g client, 10g database
A reader, March 12, 2008 - 10:51 am UTC
Tom,
If I have a user running 11g client and connecting to a 10g database, the passwords will not be case sensitive. Is this correct?
Thanks
March 12, 2008 - 5:38 pm UTC
10g was not case sensitive, correct.
A reader, March 12, 2008 - 11:34 am UTC
no it won't be case sesitive- but it is unusual to connect from higher version client to a db of lower version
March 12, 2008 - 5:41 pm UTC
no, not today - not with application servers wanting the newest jdbc drivers and whatnot available.
I would say 10 years ago, that might have been true - as updating thousands of clients was hard, and the clients used to lag way behind.
Now that the clients are application servers - they are tending to actually start to run ahead in many cases.
11g only case sensitive
Ian Gallacher, March 12, 2008 - 11:36 am UTC
Hi
New parameter introduced in 11G release
sec_case_sensitive_logon
which defaults to TRUE when you install the database!
simply
alter system set sec_case_sensitive_logon=False
to return to normal !
Ian
Not available in previous releases
11g client, 10g database
A reader, March 13, 2008 - 1:03 pm UTC
Tom,
You hit the nail right on the head. The reason we want to connect to a 10g database from 11g client is that we want latest version of .Net drivers on the application servers. The drivers are available with 11g client.
There was a time when we used to follow the "client has to be lesser or equal version to the database" rule. Now Oracle provides so many new features which allow co-hosting of different client versions, allows applications to use different driver versions on the same host and provides backward client compatibility with database versions.
I guess it is part of the evolving technology that we have to change the rules with time.
Thanks...
What case will existing passwords be after upgrade?
Mike, May 01, 2009 - 3:34 pm UTC
Is there any way to know whether passwords will be upgraded as uppercase, lowercase, or 'however it was originally typed'?
Suppose I know that I am currently be able to use
MYPASSWORD
mypassword
MyPassWord
and they are all accepted when connecting to a 10g database. It is certainly possible that the password was originally typed as mYpASSwORD, even, but I really don't have any way to find out.
What will the the password be after upgrading the database to 11g?
May 02, 2009 - 12:01 pm UTC
they were always rolled to uppercase in the past
Passwords after migrating to 11g
Mike, May 06, 2009 - 9:35 pm UTC
I found the following in the 11g Upgrade Companion:
In Oracle Database 11g password are case sensitive. In previous versions the passwords are not
case sensitive. This feature is enabled by the initialization parameter sec_case_sensitive_logon
that is TRUE by default. Setting sec_case_sensitive_logon to FALSE disables the case sensitive
feature. After migrating the Oracle database from previous versions the existing user passwords are
case-insensitive until users change it.
So it sounds like this scenario has already been planned for. It also describes a new column DBA_USERS.PASSWORD_VERSIONS to show under which database versions the password has been set (and, therefore, to indicate whether case-sensitivity is appropriate).
sec_case_sensitive not working properly
KC, June 30, 2011 - 1:49 am UTC
the sec_case_sensitive parameter seems not to work on one of our databases.
SQL> conn MYUSER/MYPASSWORD@MYDB101
Connected.
SQL> conn myuser/mypassword@mydb101
Connected.
SQL> sho parameter case_sensitive
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon boolean TRUE
is there any other parameter that i should set?
July 01, 2011 - 8:18 am UTC
http://docs.oracle.com/docs/cd/E11882_01/network.112/e16543/authentication.htm#DBSEG3225 <quote>
In previous releases of Oracle Database, passwords were not case sensitive. If you import user accounts from a previous release, for example, Release 10g, into the current database release,
the case-insensitive passwords in these accounts remain case insensitive until the user changes his or her password. </quote>
sounds like a legacy account that hasn't changed their password yet.
sec_case_sensitive not working properly
KC, June 30, 2011 - 2:00 am UTC
by the way, this is the version of my database
SQL> select * from v$version
2 /
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for HPUX: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
Logins failing, but only from Forms running under OC4J
Chuck, September 21, 2011 - 10:50 am UTC
We just migrated to database version 11.1.0.7 fom 10.1.0.4, and newly added employees were having trouble running their Forms under OC4J. While they are able to connect to the database within Forms Builder, when they try to run the form they received an "invalid username/password" error, and then they receive a popup asking for username/password (pre-filled with their username, and database instance).
By setting the SEC_CASE_SENSITIVE_LOGON parameter to FALSE, everything starts working for them. Since the production database has been running with SEC_CASE_SENSITIVE_LOGON set to TRUE without problem, I'd like to keep it in place. So that means trying to figure out how to get OC4J to work for newly added users (or, for people who change their passwords). Any suggestions?
September 21, 2011 - 12:31 pm UTC
I'd try quoted identifiers quick to see if that fixes it - that would confirm that the forms app is rolling things to upper case by default..
"myusername"/"mypassword"
(sorry, I don't have any forms installs or anything to play with...)
Forms Patch
Stephen, September 21, 2011 - 3:38 pm UTC
There is an oracle patch to fix this problem.
Forms Bundle Patch 9593176 for forms 10.1.2.3.
September 21, 2011 - 10:46 pm UTC
thanks much, i just don't work with forms at all - not really at all since about 1995 when this "internet" thingy started to catch on myself...
SYS password is still case sensitive
Gary, March 07, 2012 - 9:53 am UTC
I have just installed Oracle 11g R2 and took care of setting sec_case_sensitive_login as FALSE. It seems to have applied to all but my SYS user's password. Is SYS an exception or is it any user that connects as SYSDBA?
March 07, 2012 - 7:06 pm UTC
you'd have to sync up the external password file.
the password file is used to verify remote sysdba logins, it is maintained when you "alter user identified by". the next time you alter the user to change the password, this will take place.
Case-only PWD Change
Russ Cannon, April 22, 2013 - 5:50 pm UTC
We have noticed that changing a password only by swapping the case of the letters is rejected as changing to the same password under 11g with case sensitive passwords enabled.
sqlplus /nolog
SQL*Plus: Release 11.2.0.3.0 Production on Mon Apr 22 17:36:16 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
SQL> conn /as sysdba
Connected.
sho parameter sec_case
NAME TYPE VALUE
------------------------ ------- -----
sec_case_sensitive_logon boolean TRUE
SQL> create user u1 identified by Ab1$;
User created.
SQL> alter user u1 identified by aB1$;
alter user u1 identified by aB1$
*
ERROR at line 1:
ORA-28007: the password cannot be reused
SQL> alter user u1 identified by Ab1#;
User altered.
The password changes successfully when changing $ to # but not when swapping the case of 'A' to 'a' and 'b' to 'B'. Changing just the case of letters creates a valid new password--'a' is not equal to 'A'--but this is not accepted by Oracle even with case sensitive passwords enabled.
We are guessing that this is because the 10g hash (sys.user$.password) doesn't change even though the 11g (sys.user$.spare4) would. If this is the case, is there any way of suppressing the generation of the 10g hash so that such a password change would be accepted? Is anything like this even possible?
Cheers,
Russ
April 22, 2013 - 8:26 pm UTC
Not that I am aware of...
Michael Kutz, April 22, 2013 - 9:10 pm UTC
I can't reproduce Russ Cannon's error.
I suspect because I don't have a 'password verify function' set in my profile on my dev database.
SQL*Plus: Release 11.2.0.3.0 Production on Mon Apr 22 17:02:50 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
SQL> connect / as sysdba;
Connected.
SQL> select profile, limit
2 from dba_profiles
3 where resource_name='PASSWORD_VERIFY_FUNCTION';
PROFILE LIMIT
------------------------------ ----------------------------------------
DEFAULT NULL
SQL> alter user joeblack identified by abc123;
User altered.
SQL> alter user joeblack identified by abc123;
User altered.
SQL>connect joeblack/abc123;
Connected.
SQL> alter user joeblack identified by abc123;
User altered.
SQL>
Michael Kutz, April 22, 2013 - 9:18 pm UTC
I take that back.
I had 'password_reuse_max' set to unlimited.