We have a monetdb database which we can no longer get in to. The password we have recorded and also stored in the user's SQL client no longer works. Is there any way to bypass this and recover the password or the data?
You can reset your password by executing following MAL commands in mserver prompt:
oldp:=clients.getPasswordHash("username");
newp:=clients.backendsum("newpassword");
clients.changePassword(oldp, newp);
Related
So a long time ago i made an sqldeveloper connection called 'proiect'. I didnt get to work on it for a while so when i got back on it, i got this error
I tried this right here https://docs.oracle.com/en/database/oracle/oracle-database/12.2/axdbi/using-sql-plus-to-unlock-accounts-and-reset-passwords.html#GUID-1147D2B9-8FFC-4F91-A774-E97066B4E9C5,the exact same steps with the exact same lines; i altered the user and modified the password, but then when i try again in sqldeveloper, i get the same error.
I dont have any idea, tried a lot of different things but can't figure it out, i tried for like 2 hours now. I know there are some questions asking the same thing but it really doesnt work for me
EDIT:
When i changed the password of the user using alter user identified by password, i can connect via command line in sql plus and do queries and things, but i can not connect via sql developer. Why is that?
So i read your question, try it like this it might work:
Open command prompt as admin and then connect to system by typing
1.sqlplus/nolog and press enter
2.conn /as sysdba and press enter again
then you have connected to the system.
now you can edit the password by typing alter user identified by password
and after it you will be able to connect to the sql developer.
Below is the oracle fixed user private dblink "create statement" as it is defined in the server. This is working fine. Now my question is, does the password mentioned in the statement PWD mean that it fetches the password from ldap or from oracle vault or it is the actual password itself?
For fixed user database links, the passwords are stored in the data dictionary. In former Oracle versions the password was stored unencrypted, but this has changed now.
I have a pluggable database in Oracle 12c named PDBORCL.
After a server restart something changed in how to connect to it.
I created a user in that pluggable DB, for the example the user is PETER and the password is also PETER. Before the restart I used to be able to open a Command Prompt, run sqlplus, which would in turn ask for my username and then its password, and it would sign in. Now this does not work, it says invalid username/password. When I log in with SYS and check:
SELECT * FROM dba_users WHERE username = 'PETER';
I get no results.
However, if I sign in using the following from a command prompt, it works:
sqlplus PETER/PETER#PDBORCL
So, the DB is up and running, but it seems to be connecting by default to the wrong pluggable DB. I need to change it to the way it was before the restart, so that it connects by default to that specific pluggable DB.
How can I achieve this?
I found the solution. Change or create the environment variable LOCAL (in Windows) to PDBORCL. I think I read in linux the variable is TWO_TASK. After changing it, the following works:
sqlplus PETER/PETER
Also, just calling sqlplus and waiting to be prompted for username and password works.
You have created a user in pluggableDB and this user is not visible beyond the pluggable DB hence the reason you dont see user PETER when running the above query as sys..
If you want to connect to your pluggable DB directly what you have done above is right else you to connect to sys and the use CONNECT command.
We are cleaning up servers for a customer and have stumbled upon an old application using an H2 database. While the accessing applications have credentials in their configuration files, none of them seem to work.
Even the "sa" user access is not known. As far as I can see, the password for "sa" defaults to an empty string, but access with "sa"/"" is denied (Wrong user name or password [28000-182] 28000/28000 (Help)).
As said, the database is not encrypted. Looking at the file, I can see the SQL statements for the tables, even some table contents.
Is there any way to gain access to that database? As far as my searches have shown it's only possible using the "sa" user. I'm looking for something along the lines of "--skip-grant-tables" from MySQL.
The easiest solution is probably:
Try to login to the database without password. This will fail (wrong user name or password), but it will run transaction log recovery so that the database is in a consistent state.
Then, use the Recover tool (org.h2.tools.Recover) to generate a SQL script.
Edit the script: Change the password for the default user.
Run the script. That way you get a new database.
We are connecting to Oracle using KornShell (ksh) scripts, which use SQL*Plus to connect to Oracle. The Oracle database is on the same Solaris box. Currently, we are storing Oracle user id and password (plain text) in a file in the .ssh folder of the connecting user, with 400 permission bits.
The DBAs are objecting to this way of working, citing the fact that we are using plain text password for authentication. When we offered that we would encode the password using base64, they still did not like the idea, citing that we would still decrypt the password in the shell script and transmit the password over network.
Now, I want to understand this-
I have been reading that Oracle encrypts/hashes the password string, before transmitting it. I can not find the reference right now though, however, I still want to confirm my understanding. Is it really like this? We are on 11g r2, would that make a difference?
Would I be able to login to SQL*Plus without decrypting the password hash? e.g., DBAs set a password, pass on the hash to me. I put that in a file, and supply to SQL*Plus as a parameter. Is there some way by which this kind of authentication work? I know some tools do allow that, if you encode using their tool, they are able to decrypt the value and use it for authentication. Does Oracle?
Help me fellas.
Its been a while since doing this (and I don't have a linux box handy atm), but you can try this to hide details from ps:
echo password | sqlplus -s username#database #myscript.sql
Note that -s is silent mode for sqlplus. I believe you can also put the password in a "protected" file (I use the term loosely, but set bits to 400) and cat the file, piping to sqlplus as above.
Edit:
If the DBAs are really concerned with passwords, then how about using NO passwords. You can try OS authentication, but you need some setup first. For example:
--in Oracle, create new user
create user ops$batch_user IDENTIFIED EXTERNALLY;
grant connect to ops$batch_user;
-- in Unix (login as batch_user, or use su command)
export ORACLE_HOME=/app/oracle/product/11.2
export PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_SID=DEV
sqlplus /
Note that no passwords are used since the user is authenticated by the os. This is less complicated than Oracle wallet imo, but not perfect either.
How exactly are you connecting to the db? If you use sqlplus user/password#database from your commandline/script then you indeeed have a problem. The reason is, that you can easily see the password with the ps command.
Obfuscating it with Base64 is not really an encryption, because Base64 is a known algorithm for transfering binary data over the wire. This might baffle some, but certainly is not a safe way of sending a password.
What I do in this case, to avoid the password being shown int he process list, is that I write the password to a textfile with read only permission for the local user. Then I run sqlplus with nohup or in the background sqlplus user#db < pwdfile and immediately delete the file again.
You can use Oracle Wallets for DB authentication.
Example of tuning may be found here.