ORA-28000: account is locked error in expdp - database

I'm getting ORA-28000: account is locked error during oracle export utility. Issuing the below command:
expdp user/password tables=MY_TABLE directory=TABLE_EXPORT dumpfile=myexport.dmp CONTENT=DATA_ONLY COMPRESSION=ALL
I changed our database user account password and oracle export utility is not working ever since this password change. It locks the user account every time we try to run it.
As all my other jobs are working good with the same username and password, it has nothing to do with wrong username and password in expdp command.
It looks like some configuration or password syncs are required in some database files. Has anyone got any idea of solution to this weird situation?

Does the new password have special characters that could cause the shell script to behave differently?
May be helpful to know the account_status:
select username,account_status from dba_users;
This would tell us if the account is getting locked due to too many failed logins or is someone running "alter user account lock".

It happens due to multiple test connection or login attempts done with wrong parameters (aka user-name or password combinations).
Failure -Test failed: ORA-28000: the account is locked
Now, how to unlock that particular user in Oracle.
A privileged user (system, sysdba, or database administrator) must logon to the standby and unlock the account there.
ALTER USER locked_user_name ACCOUNT UNLOCK;
COMMIT;

Related

Why can't I create a database with my main user account with PostgreSQL?

So I have PostgreSQL installed fine, and am trying to run the createdb 'test' command in the Terminal. I am on my normal user account. When trying to create the database, I am asked for a password twice, then I get the error message createdb: error: could not connect to database template1: FATAL: password authentication failed for user "sethmarks". Does this mean I entered the incorrect password or that I do not have permission to create databases under this user? I am getting confused and frustrated by this and would like to know what is going on. I am entering the password I use for the OS user I am currently logged into.
I am able to create a database when I do sudo su - postgres and then create it when I am doing it under the Postgres user, but that is not going to work with my program. Can anybody help me figure this out?
I included a picture of the terminal to show the process and what happens when attempting to create a new db. Thank you very much.
It depends on the privileges that have been granted to your user account and which privileges have been granted to PUBLIC.
You can query some privileges with psql \du meta command for the current user.
In your case you need at least to run as superuser:
grant connect on database template1 to sethmarks;
I don't exactly why password is requested twice: this is not caused by wrong password: I have the same behaviour but I need to give the database user password not the OS user password.

Firebird database SYSDBA connection error

I just installed Firebird for Win64, and I was trying to connect to the employee database which comes pre-packaged with ISQL.
Following the steps from the Firebird official QuickStart Documentation I opened the ISQL utility and entered:
connect localhost:employee user sysdba password masterkey;
As a result I got:
Statement failed, SQLSTATE = 28000
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
Strangest thing is that if I navigate to the employee database sample itself and issue the isql command from there I can successfully connect.
The difference is that connecting directly to a database file doesn't require a password, it will even ignore the password, and just use the provided user to know which privileges to apply.
Without a hostname, ISQL will by default use Firebird embedded mode, and not the server. To compare, try using isql employee.fdb (or isql employee), it will just login with your current OS username, while isql localhost:employee will fail with a 'Your user name and password are not defined'.
It looks like you specified a different password than the default of masterkey, or somehow the sysdba account wasn't initialized. I recall there was a problem with the installer of an earlier Firebird 3 version, but I don't think 3.0.2 should be affected by this (or at least: it worked for me).
If the SYSDBA account wasn't initialized, then follow the steps of the Firebird 3 release notes, section Initializing the Security Database:
Initialization Steps
Initialization is performed in embedded mode using the isql utility.
For an embedded connection, an authentication password is not required
and will be ignored if you provide one. An embedded connection will
work fine with no login credentials and “log you in” using your host
credentials if you omit a user name. However, even though the user
name is not subject to authentication, creating or modifying anything
in the existing security database requires that the user be SYSDBA;
otherwise, isql will throw a privilege error for the CREATE USER
request.
The SQL user management commands will work with any open database.
Because the sample database employee.fdb is present in your
installation and already aliased in databases.conf, it is convenient
to use it for the user management task.
Stop the Firebird server. Firebird 3 caches connections to the security database aggressively. The presence of server connections may
prevent isql from establishing an embedded connection.
In a suitable shell, start an isql interactive session, opening the employee database via its alias:
> isql -user sysdba employee
Create the SYSDBA user:
SQL> create user SYSDBA password 'SomethingCryptic';
SQL> commit;
SQL> quit;
To complete the initialization, start the Firebird server again. Now you will be able to perform a network login to databases,
including the security database, using the password you assigned to
SYSDBA.
Where 'SomethingCryptic', should be your password.
If a SYSDBA user was created, you will need to change its password if you no longer remember what you set. Follow the same steps, but in step 3 do:
SQL> alter user SYSDBA set password '<new password>';
SQL> commit;
SQL> quit;
If this gives an error "record not found for user: SYSDBA", make sure you are really connected as SYSDBA, otherwise retry the original step 3. Not having admin access will behave as if the user doesn't exist, so the error is the same if the user really doesn't exist, or if you are connected with an unprivileged user.
CONNECT 'employee' user 'SYSDBA' password 'masterkey';
You need make sure that your alias.conf have something like this: employee=C:/examplepath/employee.fdb
make sure that the services of firebird is on

pgadmin4 allows login as admin user with wrong password

I created an admin user with password in pgadmin4:
CREATE USER admin WITH
LOGIN
SUPERUSER
CREATEDB
CREATEROLE
INHERIT
REPLICATION
CONNECTION LIMIT -1
PASSWORD 'xxxxxx';
But I can login to the respective server with the admin user and any wrong password.
I used psql command line to check if the user has been created, and it is.
# SELECT usename FROM pg_user;
usename
------------
postgres
xxxxxxxxxxx
admin
(3 rows)
I checked if I can login with the admin user and a wrong password through psql command line, and it worked...
Am I doing something wrong?
Pgadmin4 v1.1
Postgresql v9.6
Same problem on Centos 6.8 and macOSX 19.12.1
This is speculation, but it's educated speculation, as I encountered a similar issue.
If your pg_hba.conf file, I am pretty confident you have the admin user set up as "trust." This pretty much means it can log in from anywhere you specified, without a password.
If you change this to "md5," it should resolve the issue.
# TYPE DATABASE USER ADDRESS METHOD
host all admin <whatever> trust
change to
host all admin <whatever> md5
Of course some of these fields may be different, depending on how you have the server set up, but you get the idea.

Bugzilla could not connect to the mysql?

I am using C:\Bugzilla>checksetup.pl and it shows me this error message...plz tell me how i connect to mysql with bugzilla....
There was an error connecting to MySQL:
Access denied for user 'bugs'#'localhost' (using password: NO)
This might have several reasons:
MySQL is not running.
MySQL is running, but there is a problem either in the
server configuration or the database access rights. Read the Bugzilla
Guide in the doc directory. The section about database configuration
should help.
Your password for the 'bugs' user, specified in $db_pass, is
incorrect, in './localconfig'.
There is a subtle problem with Perl, DBI, or MySQL. Make
sure all settings in './localconfig' are correct. If all else fails, set
'$db_check' to 0.
You need to grant access to the user bugs from localhost to this database. Try the following, replacing the relevant parameters
GRANT ALL PRIVILEGES ON DATABASENAME.* To 'user'#'localhost' IDENTIFIED BY 'password';
More information about GRANT

alter default database for integrated user

We have a "windows integrated authentication" user whose default database was deleted.
Now when trying to login, we get an error saying, login for the user failed.
I found a solution from Microsoft to use SQLCMD. However, I am unable to issue the alter login command for that user. The error message states that the login 'mylogin' does not exist or you do not have permissions.
Unfortunately, I don't have sa credentials on that server.
Is there another way to change the default database on login?
You really need to issue the ALTER USER command from an account with sufficient privileges, or specify the Initial Catalog in the connection string when connecting, from whatever client app is being used.
Is there another way to change the default database on login?
No. Have you tried logging in to a specific database, not the default?
http://www.connectionstrings.com/
has all info about connection strings you ever need. You can set an "Initial Catalog" in the connection string. That is not "the default of the user" but it is the one to be used for THAT connection.
Sadly, if you do not have the rights to create a db or reconfigure the user, that is where it stops... need to do that on every login then. Retrieve the SA password.

Resources