Discussions
Categories
- 17.9K All Categories
- 3.4K Industry Applications
- 3.3K Intelligent Advisor
- 63 Insurance
- 536.4K On-Premises Infrastructure
- 138.3K Analytics Software
- 38.6K Application Development Software
- 5.8K Cloud Platform
- 109.5K Database Software
- 17.5K Enterprise Manager
- 8.8K Hardware
- 71.1K Infrastructure Software
- 105.3K Integration
- 41.6K Security Software
Working users then invalid username/password 6 days after database created.

I have a new Oracle 19c installation on Windows 10.
I created a new non-container database and created various users and imported database exports.
User logins work fine for a number of days.
Then after what appears to be a random number of days, I get "ORA-01017: invalid username/password; logon denied" errors.
I can only connect to the database using sysdba.
I can't find anything obviously wrong in the user info or DEFAULT profile.
I am having to recreate the database, user, schemas etc. to get things running again.
This has happened three times now since I did the original install.
I have even reinstated Oracle 19c.
The most recent occurrence happened 6 days after everything was reinstated.
My machine is being rebooted on a daily basis.
It has been many years since I last asked a question online re Oracle problems so not sure where best to ask for help now.
Could someone please point me in the right direction?
Thanks.
Answers
-
Sounds like something or someone is changing the passwords.
Did you check dba_users and/or sys.user$ for account_status, when the password was changed?
You can switch on auditing of password changes too.
-
This is an instant of Oracle on my personal machine so it is extremely unlikely someone else is changing the passwords.
I did check the various tables and nothing looked untoward. There were no signs of passwords having been changed, accounts being locked etc.
Changing passwords myself made no difference.
I had to recreate the database yesterday.
I'm waiting to see if this problem occurs a fourth time.
One day in and things are okay.
-
-
First of all, I want to mention if nothing changes the above behaviour is not expected.
1. What are versions of the passwords of your users?
SQL> select distinct password_versions from dba_users;
2. What is the value for parameter sec_case_sensitive_logon?
SQL> show parameter sec_case_sensitive_logon
3. What is the connection string you are using while connecting to the database?
-
Password versions are 11G 12C.
Now the point about the sec_case_sensitive_log setting is interesting.
In my latest incarnation of the database it is TRUE.
However, it may have been FALSE in the previous failed incarnations.
I work on a product that has been around for a while. We have a script that should be run whenever we create a database that sets numbers of processes, sessions, password life time to unlimited etc.
There was a time when we set sec_case_sensitive_log to FALSE but this line was subsequently commented out from the script.
However, it looks like the version I was using was applying this update hence it has been FALSE in the previous incarnations.
I have checked with colleagues and they have not been running this script at all.
As a result I didn't run this script after recreated my latest incarnation.
Two days in and I can still log in to the database using accounts other than sysdba.
Is there any know issue with setting sec_case_sensitive_log to FALSE?
-
Hi,
Check this out:
If/when the accounts lock you could see what the ACCOUNT_STATUS column reads. That may give you some help.
Also - just (temporarily even) audit account connections to see what's going on with the accounts. You don't need to audit all of them but the more info you have the better.
Hope this helps.
-
I am having to recreate the database, user, schemas etc. to get things running again.
That's like tearing your house down and rebuilding it, simply because you lost the key to the front door.
Why can't you simply reset the password, until you figure out what's really going on?