Forum Stats

  • 3,836,735 Users
  • 2,262,175 Discussions
  • 7,900,088 Comments

Discussions

Working users then invalid username/password 6 days after database created.

Mathew Bosher
Mathew Bosher Member Posts: 3 Red Ribbon
edited Aug 20, 2020 2:19AM in Database Security - General

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

  • Gaz in Oz
    Gaz in Oz Member Posts: 3,785 Bronze Crown
    edited Aug 18, 2020 11:29PM

    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.

  • Mathew Bosher
    Mathew Bosher Member Posts: 3 Red Ribbon
    edited Aug 19, 2020 1:52AM

    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.

  • Gaz in Oz
    Gaz in Oz Member Posts: 3,785 Bronze Crown
    edited Aug 19, 2020 11:04AM

    You may get more responses if you "Move" this thread to here:

  • mariam.kupa
    mariam.kupa Member Posts: 240 Bronze Badge
    edited Aug 19, 2020 12:03PM

    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?

  • Mathew Bosher
    Mathew Bosher Member Posts: 3 Red Ribbon
    edited Aug 20, 2020 2:19AM

    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?

  • User_BH897
    User_BH897 Member Posts: 9 Green Ribbon

    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.

  • EdStevens
    EdStevens Member Posts: 28,778 Gold Crown

    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?