I set a new password and unblocked all Oracle database users.
Then I used the following rows in SQL developer under System user:
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;
ALTER PROFILE DEFAULT LIMIT PASSWORD_LOCK_TIME UNLIMITED;
ALTER PROFILE DEFAULT LIMIT PASSWORD_GRACE_TIME UNLIMITED;
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED;
Everything seemed fine but after a few weeks, I opened the USERS tab in Enterprise Manager and all users had an expired password and were locked out.
The same problem on the following databases: Oracle 11g, 12c, 18c, 19c
It is a database for testing only.
Can you advise me how to set it once and for all, please?
Please, write me a step-by-step manual on how to do it.
Thank you very much in advance.
Changing the profile does not change any existing passwords parameters. If a password has an expiry date set, then that will still be in effect until such time as the password is changed. The profile is only consulted at the time that a password is changed. So here's the sequence you observed:
profile had a password lifetime of 'n' days.
password for user SCOTT is created or changed; at that time the profile is consulted, and the users 'password expiry date' is set to sysdate + n.
you changed the profile to set password unlimited. This does NOT change any existing user attributes. SCOTT still has the password expiry date as set in step 2.
Reset SCOTT'S password. At this time the profile is consulted, and it is seen that the password lifetime is set to unlimited, so SCOTT's expiry date is set to null.
Read more here.
But I will concur with the others. Even if this is a test system, what you propose (unlocking all accounts) is an astoundingly bad idea.
Related
I have problem logging in to one of the accounts in our database. The situation is like this.
The user has already logged in to his account environment on Linux, for example from his personal account
su - projectA
The user tries to run SQL*Plus using
[projectA#myDB2]$ sqlplus /
We are getting the message:
ORA-01017: invalid username/password: logon denied
I ran this command below and it has a missing prefix.
SQL> SHOW PARAMETER os_authent_prefix
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
os_authent_prefix string
SQL>
How do I set a prefix on os_authent_prefix?
You're allowed to have no value set for OS_AUTHENT_PREFIX, but if you do then the database account needs to be the same as the operating system account - i.e. projectA instead of OPS$projectA.
If you do want the account to have the OPS$ prefix then the initialisation parameter has to match. You can set it as #kfinity said in a comment:
alter system set OS_AUTHENT_PREFIX='OPS$' scope=spfile;
followed by a DB bounce. But as that is the default value (still, I think!) it's likely someone has intentionally cleared it, so proceed with caution.
The main thing is to be consistent. If you have other user accounts with OPS$ then you probably should have it set (and you can check the old DB you mentioned to see if the users and settings are the same). If you don't have any others then you need to verify whether any of the un-prefixed account names are identified externally via the dba_users.authentication_type column. If there are any then changing the initialisation parameter would break those.
Read more in the documentation:
I am facing a very unique situation here in Oracle DB.
I am facing "ORA-01017: invalid username/password; logon denied" error while logging in to my Oracle user using sqlplus.
Basic information about the system:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production.
2 database servers in cluster environment using Oracle clustering.
Please note that while using TOAD the user logs in perfectly however. The DB is accessible from toad using the connection details to login an individual db. It fails from TOAD while using the Cluster Scan-IP.
Following steps were performed before i started getting this issue.
I was getting a warning message from the Oracle for my user to change the password as it is expiring. Usually in situations like this i will reuse the same password however in this case it was not allowing me to reuse the same password. So I followed this link.
Now I am not able to login my user and I am even not able to completely change the password of my user and login.
Please advise with what went wrong.
Hi I am not sure exactly what your problem is, but these are the steps we follow to reuse a password:
get user profile
change profile to default
ALTER PROFILE "DEFAULT" LIMIT PASSWORD_REUSE_TIME UNLIMITED;
ALTER PROFILE "DEFAULT" LIMIT PASSWORD_REUSE_MAX UNLIMITED;
change password
ALTER PROFILE "DEFAULT" LIMIT PASSWORD_REUSE_TIME 120;
change profile back
Good luck!
The issue was caused because of special characters. I didn't imagine that "$" would be such a big deal in passwords. Anyway please find a work around for it here.
Basicly i have an java application that uses oracle as a data source. Now my application connects with a user and uses connected user's schema for table creation and etc...
Now i have a requirment that my application also should work under another schema.
So i have to alternatives.
1 - Change my table names with a prefix like
select * from other_schema.table
2 - Altering the session before running any query like
alter session set current_schema=other_schema
I am curios about is there any possibilty that alter session privilege can be revoked by dba's.
Oracle documentation says that
You do not need any privileges to perform the other operations of this statement unless otherwise indicated.
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_2012.htm
Please note that my app user will have all privileges for other_schema.
My application will be running many envoriments.
So going with first appoach, it looks like more safe but it can take long time.
Second one is faster but seems like tricky.
Yes they do. There is a role called CONNECT. This role usually (depending on version) gives you two system privileges:
create session
alter session
when your user has only create session privilege granted directly then you can not use any alter session ... statement.
Se Oracle docs:
Addressing The CONNECT Role Change
Note that the ALTER SESSION privilege is required for setting events.
Very few database users should require the alter session privilege.
SQL> ALTER SESSION SET EVENTS ........
The alter session privilege is not required for other alter session
commands.
SQL> ALTER SESSION SET NLS_TERRITORY = FRANCE;
So it really depends on Oracle version.
The CONNECT role was changed in 10gR2. It used to have most of the permissions of RESOURCE, but these were revoked in 10gR2.
I just tried ALTER SESSION with a user that only had CREATE SESSION and much to my surprise it worked, at least in 11.2.0.4.
I have an application storing it's data in an Oracle 11g Express Edition database. When the Oracle user password is starting to expire (entering grace period), the application is throwing an exception (ORA-28002) and just stops working. I need to find a way to keep the application running during that period and inform an administrator, so the password can be changed before it expires.
However my real problem is, I need to set my database user in that grace period so I can program and test my application and see if my code works. I tried to change the expiry date in dba_users, but I do not have the required privileges to do so. I'm not even sure this is the correct approach.
What could I do to make the database server think my user account will expire soon so I can write code to handle that event?
You'll need privileges to do so at the database level. A normal user cannot even explicitly lock or expire his own account. (You can lock it by purposely using the wrong password if your profile is setup so)
The only other way I know to expire your user (without a database level command) is to fool the database by setting the clock forward.
If you don't have DBA privs, it is unlikely that you have privs to change the system clock.
I tried to change the expiry date in dba_users, but I do not have the
required privileges to do so. I'm not even sure this is the correct
approach.
No, don't make changes to DBA_USERS. You would need to alter the PASSWORD_GRACE_TIME for the DEFAULT profile using "ALTER PROFILE" command. All associated changes require ALTER PROFILE system priv to do so. So, without DBA privs, you can't do it.
Look in USER_USERS
It will give you the logged in user's own expiry date so that your application can warn the user ahead of the account expiring.
Solved:
Somehow my database admin changed the user profile from DEFAULT to EXPIREPROFILE. Then I modified the password life time and grace period of the profile:
ALTER PROFILE EXPIREPROFILE LIMIT PASSWORD_LIFE_TIME 1;
ALTER PROFILE EXPIREPROFILE LIMIT PASSWORD_GRACE_TIME 21;
I expired the account and changed the password. When I looked into dba_users the password expiry date was tomorrow. But after that the account didn't expire right away, it entered the 21 days grace period.
Now I can write code to handle this specific situation and test it. Thanks everyone for your help :)
From time to time, Oracle is changing the password for my account. My project has one database pooling for each 60 seconds and another for each 600 seconds.
I don't believe this is the cause, but it abruptlies changes the password causing my code to try to login with wrong username or password that leads to an account lock.
The password is always the same and there's no way the program is trying to connect with a different username/password than the valid ones.
ORA-28000 is not a password change, it is an account lock either by the DBA or because the wrong password has been entered more than FAILED_LOGIN_ATTEMPTS times.
I have to wonder if there isn't one chunck of code somewhere that has a hardcoded, incorrect password that is being run. That or you just get too many people mis-typeing a password in a given time span.
If you want to track failed logins to try and identify what is causing this, check this link: http://www.dba-oracle.com/t_tracking_counting_failed_logon_signon_attempts.htm
Note that, from ORacle 10.2 on, the default for FAILED_LOGIN_ATTEMPTS in profiles is 10, not the unlimited that it used to be. for the default profile, check it with:
SELECT *
FROM DBA_PROFILES
WHERE profile = 'DEFAULT' AND resource_name = 'FAILED_LOGIN_ATTEMPTS';
Bet you get 10 back, and that this is the issue. You can update to a higher value, or backl to unlimited e.g.
ALTER PROFILE default LIMIT failed_login_attempts UNLIMITED;
(I think that is the right syntax - I'm away from my DB at the moment)
Well, it turns out that it was a configuration in the company lib that I was not aware of... sorry for all the mess....