I downloaded Oracle 12c from website and installed it. In gave Sys password as "admin", all the setup was done successfully.
now, on the command prompt, i issue the following commands..
SQLPlus /nolog
I get the SQL>
i then say "connect sys/nimda#orcl as sysdba and it gets connected successfully.
I try to connect to 12c will all sorts of invalid passwords and it still works.
Funny, isn't it?
When you log on to the database server and that user is member of the operating system's DBA group, then - when connecting to that (local) database - you're authenticated at the operating system level and you can connect just as you tried it - with an invalid password.
You could also try, for example, sqlplus littlefoot/mukesh as sysdba, and it should work.
Related
I'm trying setup Firebird 2.5 with FlameRobin 0.9.3, installed on Windows 10 64bit. The .fdb files are on the same disk of the Firebird machine and the FlameRobin program.
I'm trying to connect EMPLOYEE.FDB file with FlameRobin getting this error.
My settings for this database file below.
I never changed my sysdba password. Is it due to this error ODBC driver?
Edit: I've created a new database on ISQL to try. Username: SYSDBA Password: 31202333
But I am getting same error on FlameRobin.
The error means that your username does not exist (unlikely for SYSDBA), or the password is incorrect*. In Firebird, passwords are system wide, not per database. Check your password (default installations of Firebird on Windows use the password 'masterkey'). Otherwise try resetting the password using gsec.
The fact it might work with ISQL, is that you're using a local path, which may cause ISQL to use Firebird embedded mode, and in embedded mode on Windows, the password is ignored (on the assumption that if you have filesystem access to the database file, you are allowed to open database). I guess that, if instead of 'D:\sq\sample.fdb', you'd use 'localhost:D:\sq\sample.fdb' in ISQL, you would get the same error as in FlameRobin.
*: In Firebird 3 and later it can also mean that the user does not exist for the authentication plugins tried, even though the user may exist for a different authentication plugin.
I've installed firebird 3.0 from the package provided by firebirdsql.org.
If I try to use a local connection to a database:
isql employee -user SYSDBA
it fails with:
Can not access lock files directory /tmp/firebird/
So adding read/write/execute permissions to /tmp/firebird/
sudo chmod a+rwx /tmp/firebird/
and executing the command again yields:
Statement failed, SQLSTATE = 08001
I/O error during "open" operation for file "/tmp/firebird/fb_init"
-Error while trying to open file
-Unknown error: -1
This all will work if I sudo the calls, but is this really necessary?
What is the correct way to use a local connection to firebird database on macOS?
I found CORE-3871 issue in the firebird issue tracker, which describes the problem and it's solution. The user which tries to open the local connection must be member of the firebird user group.
So a user is added to the firebird group on mac bash with the following command:
sudo dseditgroup -o edit -a myusername -t user firebird
If you try to open the sample database employee, shipped with firebird, it's also necessary to grant the group write access to the employee.fdb:
sudo chmod g+w /Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employee.fdb
Now /Library/Frameworks/Firebird.framework/Resources/bin/isql employee -user SYSDBA should work
I only put -p and the password and it's just fine. It's working.
You current command creates the Firebird Embedded database engine to connect to the database. To be able to do that, your current OS user needs to have sufficient access to the database file. For details how to fix that, see the answer by jonjonas68.
An alternative to solution - if you have the Firebird server running - is to connect through the Firebird server process, for example using isql localhost:employee -user sysdba -password <sysdbapassword>. Then the file permissions of the user running the Firebird server process will be applied. However, in that situation, you will need to specify a password when connecting, as passwordless authentication is only applied for Firebird Embedded connections.
When I execute Firebird 3.0.x backup command:
c:\Db>"C:\Program Files\Firebird\Firebird_3_0\gbak.exe" -b c:\Db\Db1.fdb c:\Db\Db1_backup.fbk -garbage_collect -transportable -verify -user SYSDBA -pas PASSWORD
Error 1 happend:
gbak: ERROR:I/O error during "CreateFile (open)" operation for file "C:\DB\DB1.FDB"
gbak: ERROR: Error while trying to open file
gbak: ERROR: The process cannot access the file because it is being used by another process.
gbak:Exiting before completion due to errors
Example 2 with TCP/INET/localhost/remote protocols:
c:\Db>"c:\Program Files\Firebird\Firebird_3_0\gbak.exe" -backup inet://c:\Db\Db1.fdb d:\_Backups\Db1_20180702_230546.fbk -garbage_collect -transportable -verify -skip_data SOMETAB_TO_SKIP -user SYSDBA -password PASSWORD123
Error 2 happend:
gbak: ERROR:Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
First of all ... to be honest I am not sure when this started or why. I did not look at my server maybe 3 months but today my backup disk broke down so I had to. I just saw this error first time today and I lived in conviction that my backup works. But I had Firebird 2.5 before.
The question is: is this specific only for Firebird 3 SuperServer on Windows? And there is no way how to backup Firebird 3 SuperServer database when is used by FB server?
Tested and failed on Firebird server 3.0.2 and 3.0.3 on Windows Server 2016.
Firebird is running as a service
Nothing is changed in firebird.config except:
WireCompression = true
RemoteServicePort = 1234
CpuAffinityMask = 8
ServerMode = Super or SuperClassic (when I testing it)
When I execute first command on SuperClassic it works.
When I execute first command on SuperServer 2.5.x it works.
Ok, so I finally figured out where is the issue. Here is the explanation:
My password is wrong!
BUT!
When I use SuperClassic I can use WRONG password and Firebird allows access to the database. (as local user)
When I use SuperServer I can use WRONG password and Firebird allows access to the database WHEN I am the FIRST connection! (as local user with and also without remote protocols)
When I use SuperServer and I use WRONG password Firebird denied access to the database WHEN I am the second (and more) connection! (local also remote user)
With only remote protocols you can not access database with wrong password.
(By remote protocols I mean this.)
This are the reasons of the differences in behavior and why I did not see using of WRONG password. Thanks to everybody who tried to help me.
I'm trying to setup a local firebird instance to test against but am unable to connect to it with even ISQL. I have tried to following by following the quick start guide here:
CONNECT ..\examples\empbuild\employee.fdb user SYSDBA password masterkey;
Which resulted in:
Statement failed, SQLSTATE = 08001
unavailable database
After some searching I tried modifying that to:
CONNECT "localhost:C:\Program Files\Firebird\Firebird_2_5\examples\empbuild\employee.fdb" user SYSDBA password masterkey;
Which resulted in:
Statement failed, SQLSTATE = 28000
cannot attach to password database
After confirming I had the right directory path I decided to give on on connecting for now and try creating a new DB:
SQL>CREATE DATABASE 'C:\data\test.fdb' page_size 8192
CON>user 'SYSDBA' password 'masterkey';
Which also gave me the error:
Statement failed, SQLSTATE = 08001
unavailable database
Are there any common pitfalls I might be hitting? I've also tried the commands above both with and without the firebird service running. Also is there a detailed reference on the SQLSTATE codes?
As already mentioned in my comments the problem is caused by running the Firebird server as an application. Firebird has its password database (security2.fdb) in C:\Program Files\Firebird\Firebird_2_5. As this database is (almost, but not entirely) a normal Firebird database, the server requires write access to this database (for the transactions, etc).
By default (with UAC) users do not have write access to the password database, so this requires elevation to Administrator. So access to Firebird requires that you either run the application as a service with sufficient rights (eg as done by the default installer), or when running the server as application to run it 'As administrator'. Another option is to not install it in Program Files.
This BTW applies double when accessing the example employee database as this database file is also located in the Program Files folder.
This is for macOS/OSX (mine is 10.15) firebird ver 2.5 users.
The installation process here does not ask for a sysdba password. Which means: the security database 'security2.fdb' does not exist after a new installation.
This seems to be intentionally for security reasons since > ver 2.5.
To create one, we use the demo database as a helper:
open sql as su: >sudo isql (we don't have user rights on dir)
Connect to a existing db:
sql>connect
"/Library/Frameworks/Firebird.framework/Resources/examples/empbuild/employee.fdb
" user 'SYSDBA' password 'masterkey';
Now we created the missing file 'security2.fdb' in the folder:
"/Library/Frameworks/Firebird.framework/Resources/English.lproj/var/"
(jro)
I stopped my db using db2stop force. The started did a backup restarted and after that
i cannot connect to db from the a client anymore i get:
using the command
db2 connect to "dbname" using "user"
SQL30082N Security processing failed
with reason "42" ("ROOT CAPABILITY
REQUIRED"). SQLSTATE=08001
password and username are correct. When im on the server connecting using command
db2 connect to "dbname"
or
db2 connect to "dbnmae" user "user"
or
db2 connect to "dbname" user db2inst1
works just fine.
I m really confused. Any help is much appreciated
Thanks.
What i tried so far :
db2 get dbm cfg | grep -i auth GSS
Plugin for Local Authorization
(LOCAL_GSSPLUGIN) = Server
Connection Authentication
(SRVCON_AUTH) = NOT_SPECIFIED
Database manager authentication
(AUTHENTICATION) = SERVER Cataloging
allowed without authority
(CATALOG_NOAUTH) = NO Trusted client
authentication
(TRUST_CLNTAUTH) = CLIENT Bypass
federated authentication
(FED_NOAUTH) = NO
switched to client but did not using
db2 update dbm cfg using
authentication client
Update:
Despite the age of this question, it would be wonderful to have a solid answer to this question. Hi locojay, how did you manage? :-)
I'm having the SQL30082N reason code 24 issue in my Windows PC, and today we experienced the same issue in an AIX server.
I googled for a couple hours and didn't find but one happy answer, related to having users with the same name both in the server and the client.
IMO it does not apply to me, as I'm running into a VBox that´s isolated from the domain (no network).
My case: I installed DB2 as user db2admin, no security. Then I granted DBADM to VIRTUALUSR01 and gave this user a password.
db2 connect to TheBase
works fine. But
db2 connect to TheBase user VIRTUALUSR01 using TheRightPassword
returns SQL30082N with reason code 24.
Using client authentication is generally a Bad Idea(TM). That's because you now rely on machines that you may not control for authentication. If I wanted to subvert your system, I could create a new user locally, say, db2inst1 or VIRTUALUSR01 or Administrator, with a password I know, and then, use that to wreak havoc on the database. If, however, no one in your organisation has root/administrator authority over their own machines, client authentication can be made to work. But all it takes is someone plugging in their own personal laptop, and your database could be at risk.
Instead, check the permissions of the files. If you've installed as root, ~db2inst1/sqllib/security/db2c[hk]pw (assuming instance ID of db2inst1) should be setuid root. If not, run db2iupdt against your instance (./db2iupdt db2inst1) which should fix the permissions.
If you've installed without root authority ("non-root install"), which I doubt, since you seem to have had this working, you would need to read the DB2 documentation on non-root installations and their limitations - I don't use non-root installs myself, so I'm not so familiar with them. However, there should be a set-root script that you can use to enable setuid root which, of course, you have to run as root.
I had the same problem and solved with the following way.
Problem occurs because of /etc/shadow file. If the user's password hash is created with SHA then DB2 cannot authenticate or authorize that user. You need MD5 for hashing that user's password.
If you are using Fedora or RedHat Linux, first change hashing method of passwords with:
# authconfig –-passalgo md5 –-update
Then drop and recreate the user:
# userdel userName
# useradd userName
# passwd userName
If you are using AIX or any other linux distros, authconfig won't work. So instead of passwd userName, issue this command:
# usermod --password `openssl passwd desiredPassword`
After that, your password hash belonging to userName will be generated with MD5.
Now grant user privilege to that user:
# su - db2inst1
(db2inst1)$ db2 connect to databaseName
(db2inst1)$ db2 GRANT DBADM with dataaccess with accessctrl on database to user userName
I hope it works for you too.
Thanks to Honza for his solution
Solutions to specific problem causes described previously in
this message are:
1. Run DB2IUPDT <InstName> to update the instance.
2. Ensure that the username created is valid. Review the DB2
General Naming Rules.
3. Ensure that catalog information is correct.