When I try anything in isql, I get the message:
Your user name and password are not defined. Ask your database
administrator to set up a Firebird login.
unable to open database
When I try to create the user I still get the message:
C:\Program Files\Firebird\Firebird_3_0>gsec -user sysdba -password masterkey
use gsec -? to get help
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
unable to open database
But I am the administrator, and I installed it.
How do I create the user SYSDBA in Firebird?
The combination of the "Your user name and password are not defined. Ask your database administrator to set up a Firebird login." with "unable to open database" does not mean the SYSDBA account does not exist, it means that the Firebird process was unable to open the security database to perform authentication.
This can happen if you installed Firebird in C:\Program Files, and you are running the Firebird server as an application (instead of as a service) and UAC is enabled, or you are running as a service, but the user account running the service has insufficient rights to read and write to the security3.fdb file.
You either need to run Firebird as a service (e.g. as configured by the installer), or - if you really want to run Firebird as an application - install Firebird outside of C:\Program Files.
How do I create the user SYSDBA in Firebird?
Connect to any database (security.db or employee) in embedded mode using user name SYSDBA (password is not needed in this mode) and issue SQL command "CREATE USER" as described in Firebird Language Reference.
You can learn more about embedded mode from Firebird 3.0 Release Notes.
Related
I have Firebird 2.5 and I need to extract all user and privileges as DDL to export to another Firebird database.
For example, I need get the script for user max
"Create user max FIRSTNAME 'Max' LASTNAME 'Power' Grant admin option";
I use IB Expert, but did not find this option to extract the DDL.
Tools -> Grants/Rights Manager -> Toolbar -> Save -> To Script Executive
Alternatively, go to the Tools -> Extract Metadata -> Settings and down there check the "extract grants" checkbox.
You also have to remember that users themselves do not exist in the database (only grants do), users they exist in the server, not the database.
See how to display and set user rights in firebird database
Also see GSEC documentation:
http://www.destructor.de/firebird/gsec.htm
https://www.firebirdsql.org/file/documentation/html/en/firebirddocs/gsec/firebird-gsec.html#gsec-batch
gsec -user sysdba -password <password> -database <databasename> -display - a command like that should display all the users registered with the server used to connect to the database. It would be trivial to take the user list and add the create user command to every one.
There is one more niche case that Firebird might have no any users, borrowing them from the host operating system. It is called "Trusted Authentication" mode. If GSEC would show no users or too few ones - check authentication settings in the relevant firebird.conf, maybe you would have to dump users list from Windows, not from Firebird.
https://www.firebirdsql.org/rlsnotesh/rnfb210-wintrusted.html
https://github.com/FirebirdSQL/firebird/blob/master/doc/README.trusted_authentication
I'd like to learn how to use postgres, so I just installed it, set my password, and added the \bin and \lib directories to my system path. I then ran psql in the command line, typed the password that I just set when I was prompted, and now I receive this error:
psql: error: FATAL: password authentication failed for user "me"
I don't understand why that happened. Any ideas? I am using windows 10.
The windows installer asks you to specify the password for the super user named "postgres". But if you just type psql, you are trying to log in as the PostgreSQL which has the same name as your windows OS user. But that PostgreSQL user probably doesn't even exist, much less have the same password as you specified upon installation.
So the first time you log in, you have to tell it to log in as the initial superuser, with -U postgres. Once logged in, you can create a user named 'me' (create it with a password--possibly the same as the first password you assigned, although generally they would be different), and a database named 'me'. From them on, you could log in as this new user to this new database, just by typing psql and then giving the password when it asks.
In general, the initial user and the initial database are only used for maintenance operations. Other tasks should be done with the users and in the databases you set up after the first time you log in. This isn't "the law" of course, it is just "a good idea".
I am unable to make Firebird forget the old password for default user. I have installed Firebird version 3.0.4 on my local computer. I have tried to change the default password masterkey to another one via gsec tool. First I have logged in into this tool with command:
gsec -user sysdba -password masterkey -database "C:\Program Files\Firebird\Firebird_3_0\security3.fdb"
And then with command modify I have set next password:
modify sysdba -pw qwerty12
The issue is that now I can login into sysdba account with both passwords, the old masterkey password and the new one qwerty12 password. How can I make the Firebird to forget the old default password?
The problem is not that Firebird remembers the default password, the problem is that Firebird stores a password per authentication plugin, and SYSDBA happens to exist for two (or possibly more) authentication plugins.
To fix this, you must either drop the SYSDBA account for one of the authentication plugins, or change its password. Dropping the SYSDBA account is, unfortunately, rather hard to do for the Legacy_Auth plugin (you need to manually delete it from the security database, see at the end of this answer).
Assuming the standard Firebird install (which has authentication plugins Srp and Legacy_Auth), you need to do the following to change the password (note: I'm assuming that the problematic account is the one for Legacy_Auth, not Srp):
In firebird.conf, setting UserManager ensure both user managers are listed:
UserManager = Srp, Legacy_UserManager
Restart Firebird
Change the password for both plugins
alter user SYSDBA password '<new password>' using plugin Srp;
alter user SYSDBA password '<new password>' using plugin Legacy_UserManager;
Keep in mind: the legacy authentication plugin truncates passwords at 8 characters.
If you want to prevent authentication using the Legacy_Auth plugin entirely, then edit the firebird.conf and remove Legacy_Auth from the AuthServer setting (also check databases.conf if the database has a custom configuration).
I have asked a question on the firebird-devel mailing list about the inability to drop the Legacy_Auth SYSDBA account. The answer I got was that historically it was impossible to delete the SYSDBA account in older Firebird versions, so the Legacy_UserManager plugin explicitly disallows deleting SYSDBA (while Srp allows it). The workaround is to connect directly to the security database, and delete the user manually from the PLG$USERS table (which contains the Legacy_Auth users, Srp users are in PLG$SRP):
delete from plg$users where plg$user_name = 'SYSDBA';
You can connect to the security database using isql -user sysdba -password <yourpassword> security.db (assuming the security.db alias is defined in databases.conf, otherwise use the full path to your security3.fdb).
A slightly more obscure alternative would be to define a mapping that maps an authentication as SYSDBA using Legacy_Auth to a different (unprivileged) user (eg GUEST):
create global mapping NO_LEGACY_SYSDBA
using plugin Legacy_Auth
from user sysdba to user guest;
To drop the SYSDBA account for the Srp plugin, you only need to execute (as admin):
drop user SYSDBA using plugin Srp;
I'm trying to connect to employee.fdb in Firebird3.0 (localhost) using FlameRobin 0.9.3 on a Ubuntu OS.
The connection to Firebird using isql has no issues. I can create users, roles, etc all from the terminal. However, when I attempt to make a connection using FlameRobin I receive a 335544344 "Error while trying to open file Permission denied" response.
This occurs with the SYSDBA profile and any other new user profiles that I create in isql. I can even create new users in FlameRobin but I cannot connect to any database. I've verified in /etc/firebird/3.0/firebird.conf that DatabaseAccess = Full and have attempted to access the db from a couple different folders in case this is a read/write issue. No success.
I feel like I'm missing something obvious. Any thoughts?
Added info in response to Mark (4/26):
The db is stored in /var/lib/firebird/3.0/data/. I have assumed this to be the default location for Firebird DBs and that the server automatically has access to it, but I suppose that might not be the case. Is there a way to confirm server permissions to this directory and/or is this the customary spot to store work?
Terminal Connection with ISQL:
daniel#daniel-desktop:~$ isql-fb
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect '/var/lib/firebird/3.0/data/employee.fdb' user sysdba password 'xxxxxxx';
Database: '/var/lib/firebird/3.0/data/employee.fdb', User: SYSDBA
SQL>
FlameRobin Database Registration Info:
FlameRobin Error:
This is a permissions issue as #MarkRotteveel suggested. Problem was that I installed the server as a user and not as root. Problem solved by removing and reinstalling both Firebird and FlameRobin as root.
I am using win Vista, and I am trying to backup some Database under DB2.
I am logged in using the Administrator user, and whenever I try to issue the backup command in the "command line processor", I get the following message:
SQL1092N "ADMINISTRATOR" does not have the authority to perform the requested command. SQLSTATE=00000
BTW, I have created a username/password pair (db2admin) while installing the DB2 server.
So, Will this problem will be get solved if I use the db2admin user? And how to connect to the server (local server BTW) using the db2admin user ?
I had this problem recently and this seemed to do the job:
Attach to your [local] node. (the value of your DB2INSTANCE environ variable, mine was 'DB2'):
attach to DB2 user db2admin using mypassword;
If this isn't enough (it didn't seem to be with me), you can also specify the user and password with backup and restore commands:
restore database mydbname user db2admin using mypassword from C:\BACKUPS taken at 20100823132457;
Or manually create the db2admin user with a password on Windows. But I'm not sure if that's the correct option here.