Recently, the user has become very often locked. I suspect this is due to the erroneous input of the username and password, but I don’t know how to find out from which computer this happens. Is it possible to get any information about this (for example, IP or username) due to which the user was blocked?
Oracle Database 10g Release 10.2.0.3.0 - Production
It may not be that the user has blocked themselves. This question gives several reasons including:
An appropriately privileged user could issue the command:
ALTER USER user_name ACCOUNT LOCK;
An appropriately privileged user could issue the command:
REVOKE CONNECT FROM user_name;
If could be that the PASSWORD_LIFE_TIME is exceeded, or both that and PASSWORD_GRACE_TIME is exceeded.
User exceeds FAILED_LOGIN_ATTEMPTS
Only 1 of those 4 reasons would have been initiated by the (now) locked user.
The accepted answer to that question states:
Provided audit trail is turned on, then I prefer to use the following to help track down login failures (which is usually the cause of locked accounts):
select * from dba_audit_trail where returncode in (1017, 28000) order by timestamp desc;
returncode is the ORA- error that would be returned from the database: 1017 is "invalid usercode or password" and 28000 is "account is locked".
And then goes on to give more details of how to activate the audit trail if it is not already turned on.
Related
I am trying to create a database and each time I run the createdb [databasename], and enter the "incorrect" password, command I get the following error, createdb: error: could not connect to database template1: FATAL: password authentication failed for user "[username]".
However, the user that says the authentication has failed for doesn't exist. I can run psql -U postgres and enter the password I provided previously and log in just fine. Once logged in as Postgres user I run \du and only see the Postgres user in the table. Any reason this would be happening? I uninstalled and reinstalled and still have the same issue. Why is the default user something other than the original postgres user?
Here is the result of the \du command
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
The error message does not tell you the exact reason why authentication failed on purpose, to give attackers as little information as possible.
The cause of your problem might be that your username contains upper case letters on the operating system, but you created the database user without using double quotes, so that the upper case letters got translated to lower case.
If you want more than guessing, you have to tell us the exact command line and the output from \du.
I guess I had to add the username from my OS because that is what Postgresql defaults to, as well as add a DB with the same name.
I want to create a new profile in SQL plus.
I started off by creating a user, this worked:
create user myuser
identified by password;
Then I tried to create a profile, this didn't work:
create profile myuserprofile limit
sessions_per_user 2
connect_time 120
idle_time 30
failed_login_attempts 3
password_life_time 365;
This is the errors i received:
ORA-65048: error encountered when processing the current DDL statement in pluggable database XEPDB1
ORA-01435: user does not exist
I tried it on my laptop, the same result.
the next step would be to alter the user to have the profile.
Edit:
I connected as the system and was able to get rid of both the errors:
ORA-65048: error encountered when processing the current DDL statement in pluggable database XEPDB1
ORA-01435: user does not exist
However, the error still arises when I try and create the profile on my user
Edit2:
FIXED
I realised i did not have DBA privileges on my user.
GRANT DBA TO XYZ;
Thanks
How I can make a trigger that a user connect to database check if user System is connected in this moment. Is correct? Then error message and user no connect to database.
Thanks guys.
First, I want to point out that it sounds like you're trying to recreate the functionality of the command ALTER SYSTEM ENABLE RESTRICTED SESSION. You might consider just using that instead.
On the topic of your question, there's an easy answer, but it isn't very good.
CREATE OR REPLACE TRIGGER logon_system_maintenance
AFTER LOGON on DATABASE
IS
system_is_connected varchar2(1) := 'N';
BEGIN
select 'Y' into system_is_connected
from v$session
where username = 'SYSTEM' and status = 'ACTIVE';
-- this will not prevent users with ADMINISTER DATABASE TRIGGER privilege from connecting
RAISE_APPLICATION_ERROR (-20001, 'SYSTEM user is performing maintenance, please try again later');
EXCEPTION
WHEN NO_DATA_FOUND THEN
null; -- system not connected, OK
WHEN OTHERS THEN
null; -- probably the user doesn't have permission to view V$SESSION!
-- should they be able to connect, or not?
END;
/
The problem here is that in order to check if SYSTEM is connected, the user connecting has to be able to view the V$SESSION view, which means they need the SELECT_CATALOG_ROLE role. Probably most of your users don't have this role, which means they don't have permission to even check if SYSTEM is connected or not!
In my experience, what most applications do is create a table to hold various system parameters (e.g. MY_PARAM_TABLE), and add a parameter which controls whether users can log in or not (e.g. SYSTEM_MAINTENANCE = 'N'). Then when you log on as SYSTEM, you set that flag to Y, and the trigger checks that table (which all users should be able to access) and denies access until you set it back to N.
Also keep in mind that you can't prevent DBA users from logging in this way.
In spite of unlocking several times, my account on oracle database is getting locked each time I try to connect to another user.
I type the following command while I am on root account:
sql> connect hr/hr
And then, I get the following error.
ERROR: ORA-28000: the account is locked
WARNING: You are no longer connected to ORACLE
You are attempting to connect to a locked account:this is not permitted. However, issuing a connect logs you out of your root account (whatever means in an Oracle context).
In order to connect to hr you need to unlock that account. This needs DBA privileges:
alter user hr account unlock;
You can change PASSWORD_LIFE_TIME parameter by using below command.
alter profile default limit PASSWORD_LIFE_TIME unlimited;
I created a simple page with HTML/PHP for the sole purpose of getting unsanitized user input.
It is located here: http://109.201.140.29/mssql/
I did this just for fun, I use this windows server for nothing else currently.
Is there any risk when the user ONLY has (readonly) access to the database test_db?
It also logs failed/successful queries, sample of error log (as you can see, drop table does not work):
[2014-07-08 14:27:41] (query) Execution of query: "DROP TABLE users;" Failed.
src IP: <snip>
err: SQLSTATE[42S02]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot drop the table 'users', because it does not exist or you do not have permission.
sample from successful queries log:
[2014-07-08 14:17:38] (query) Executed: "select * from users;".
src IP: <snip>.
Returned rows: 100.
[2014-07-08 14:17:45] (query) Executed: "select ##version;".
src IP: <snip>.
Returned rows: 1.
[2014-07-08 14:19:12] (query) Executed: "SELECT * FROM information_schema.tables".
src IP: <snip>.
Returned rows: 1.
Simple question I suppose; but is there any risk here? Besides the obvious flaw of taking user input as queries..
The user has as I said read-only access and is not a owner of any databases.
I ask because this is my first experience with SQL Server, but from my testing at least the queries seem to only allow reading (SELECT) which is OK for this purpose.
Feel free to test queries of course - as there may be some queries possible that I am not aware of.
Security is built from confidentiality, availability and integrity.
Confidentiality is obviously compromised as you just give any access.
Availability is compromised as Damien showed, and other methods can be also used.
Integrity is the only thing the the "read-only" permissions actually helps to protect, but it is also limited.
Your DB Version is Microsoft SQL Server 2012 - 11.0.2100.60, there are always new exploits that can give total server takeover, and if you give direct access to the DB an attacker can always perform brute force attack to guess and impersonate another stronger user or even admin user (EXECUTE AS LOGIN... for example).
You can never close all of the potential vulnerabilities and you should never allow any direct access to your DB.