I am trying connect to firebird 3.0 throught latest version of ADO.NET provider 5.0.5.0 from my simple test .net application. When i used sysdba user connection is made OK, but if i used other user then connection failed with classic FBException :
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
"initial catalog=c:\\Database\\Data.fdb;data source=localhost;user id=sysdba;password=sysPass;port number=3050" = OK
"initial catalog=c:\\Database\\Data.fdb;data source=localhost;user id=michal;password=micPass;port number=3050" = failed
But if i am trying connect throught IBExpert or isql , then connection is made OK and i can get data from tables.
Previously i used Firebird 2.1 and then i upgraded to Firebird 3.0 superclassic and get ADO.NET provieder from nuget.Actually i do not need SRP ecryption so I disabled WireCrypt etc. and use Legacy authentication (Firebird 3.0 release notes page 117). Then i created my new user via IBExpert (sysdba was created during installation firebird server).
I do not need migrate users from previous firebird version so I skiped Upgrading a v.2.x Security Database steps.
It is strange that i can connect myUser via IBExpert or isql, but not via ADO.NET provider.
It seems to me unlikely that ADO.NET provider has bug of this type (everyone needed connect via user), so I guess that i have some bad configuration.
I had some bad configurations and I need set correctly:
In firebird.conf, there has to be: WireCrypt = Enabled (not disabled)
Create user account older way (in my case via IBExpert)
The password have to max. length 8 chars (previously you can have more chars and Firebird is omit)
Related
Is it possible to open a Firebird database file also with a Firebird Embedded of the same Firebird version? Sure, I am aware I can't keep the same file open via FB Embedded and FB at the same time. But after closing the Firebird connection it should be possible to connect with FB Embedded, right? Are there any restrictions when connecting over FB Embedded. My question concerns Firebird Version 3.0 or higher.
I expect that this is possible without any restriction.
The Firebird Embedded library uses the exact same database engine as the full blown Firebird server (plugins\engine12.dll in the case of Firebird 3.0). The difference is that a Firebird server accepts remote connections over TCP/IP (and NetBEUI), and - on Windows - connections from other processes using XNET and uses authentication, while Firebird Embedded is an in-process database engine which can only be used from within that process, and relies only on filesystem permissions to decide if you're allowed to open a database.
In other words, it uses the exact same database file format.
As an aside, it is possible to use a Firebird server and Firebird Embedded together on the same database concurrently, if ServerMode is configured appropriately in the firebird.conf of both (to SuperClassic/ThreadedShared or Classic/MultiProcess), and both use the same lock-directory (which would be the default situation).
A Firebird 3.0 server can only open databases with On-Disk Structure (ODS) 12.x, while Firebird 4.0 can - by default - only open databases with ODS 13.0. It is possible to include the engine12.dll of Firebird 3.0 in Firebird 4.0, and configure Firebird 4.0 to open a Firebird 3.0 database with that specific plugin.
I need to create users in Firebird 3.0 embedded databases, but using with standard command returns error.
command:
CREATE USER miusuario
PASSWORD 'miclave';
return:
Engine Error (code = 335544382): Missing user management plugin.
SQL Error (code = -901): Unsuccessful execution caused by system error that does not preclude
successful execution of subsequent statements
I need to create the users on both in runtime and in development.
Any idea how to solve this problem? I've looked in the Firebird documentation and can't get anything to help me.
I do not use the Firebird in server mode, only embedded.
Firebird Embedded does not perform authentication1, and it will accept any username you specify at connect. Creating users is unnecessary, and in your case impossible because it looks like the user management plugin is not configured or available (setting UserManager in firebird.conf). However, even if that plugin was configured, it would be pointless to create users if you only use Firebird Embedded, because Firebird Embedded won't actually use the data of that user.
In Firebird, privileges are granted to usernames not to user records in a security database2. So, even though there exists no user with that username, you can grant it rights (in fact, that is also possible in Firebird server).
You can login (password is ignored) with any username when using Firebird Embedded. The logged in user will then assume any rights granted to that username.
1: This has always been the case on Windows, on Linux this is only the case since Firebird 3, in earlier versions on Linux, Firebird Embedded did perform actual authentication using the security database
2: Except for a small set of privileges like admin in security database and database creation privileges
I have a firebird database in a .fdb file, but the database do not have the SYSDBA user and I don't remember the credentials to login into the database. Are there any way that could reset the database credentials?
Like said by Mark, it is not that the database "does not have SYSDBA user" - databases in Firebird 2.x never have users - but that old trick was used to create SYSDBA named role in order to trigger names collision on login.
After scanning through 2007 Security presentation I have two suggestions for you.
You can try some tool that opens Firebird databases without using Firebird itself to learn what username can pull you out of the deadlock.
One such tool is Database Explorer in the IBExpert. Full IBExpert is paid for non-USSR states and free IBExpert Personal probably does not have the tool. But I hope the tool works in IBExpert Trial. Another tool is IBSurgeon FirstAID. And probably there are more tools featuring data extraction from corrupt databases. You only need to find and read one specific row.
The query to create the blocking role is given on the 23rd page of the presentation.
INSERT INTO RDB$ROLES(RDB$ROLE_NAME, RDB$OWNER_NAME)
VALUES (‘SYSDBA’, ‘LOCKSMITH’);
So you would have to look into the said table, find the row with the said role, and learn the username that has authority over that role (in the example it was LOCKSMITH).
After that you connect to any other database on the same server and you create the user with the name you learnt. Then you use that name to login into the problematic database and to DROP ROLE SYSDBA; COMMIT;.
You also can use Firebird Embedded. All server-coded security checks are bypassed in the Embedded edition of FB 2.x (but if DB designer added some ad hoc security checks in triggers - they will work). So you login into the problematic database using Firebird Embedded edition, any username and any password, and after that you drop the access blocking role.
In Firebird database doesn't contain password (until v3.0 as mentioned by #Arioch'The). The password is used only for server. Another words, you can copy database file from existed server to another (with known password) and open the database file.
I migrated from firebird 2.5.x to 3.0
i have changed firebird.conf :
WireCrypt = Enabled
AuthServer = Legacy_Auth, Srp, Win_Sspi
after that here you are what happened:
I can connect from Netbeans IDE using SYSDBA masterkey.
I can connect from FlameRobin (database admin. tool) using SYSDBA with other password.
I can not connect from Wild-Fly server using SYSDBA with that other password.
I am really wondering.!!
I assume you are using Jaybird 2.2.x (or earlier) when connecting from Netbeans and Wildfly. With Firebird 3 a new authentication model was introduced called SRP (Secure Remote Password). Jaybird 2.2.x doesn't support this new authentication model (support will be added in Jaybird 3.0), so you need to use the Legacy_Auth plugin.
Users have a separate identity per plugin, this means that you (can) have two users with the name SYSDBA, one for SRP and one for Legacy_Auth. These users have their own passwords.
So when you connect from Netbeans and Wildfly, you need to specify the password of the legacy authentication user. This password appears to be masterkey, or actually: masterke as legacy passwords are only 8 characters.
When you connect from flamerobin, you can use the 'other' password (of the SRP sysdba user) as flamerobin uses the Firebird 3 fbclient.dll/libfbclient.so and therefor supports the new SRP authentication model.
As far as I know flamerobin should also be able to authenticate with the password of the legacy sysdba user (when login fails, it should try the next plugin). I will test that tomorrow.
I installed firebird database for the first time in my life (version 1.5.6 on Windows 7), after installation I can not connect to the sample database (employee.fdb exists), or create a database. This gives the following error in ISQL Tool:
C:\Program Files\Firebird\Firebird_1_5\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> CONNECT "C:\Program Files\Firebird\Firebird_1_5\examples\employee.fdb"
CON> user 'SYSDBA' password 'masterkey';
Statement failed, SQLCODE = -904
unavailable database
SQL> create database 'C:\test.fdb'
CON> user 'SYSDBA' password 'masterkey';
Statement failed, SQLCODE = -904
unavailable database
Firebird 1.5 was written (long) before Windows 7, and before things like UAC existed. It may simply be that Firebird 1.5 doesn't work correctly with Windows 7, or that it requires additional effort to work. I'd suggest to install Firebird 2.5.2 (update 1) as that is the latest version and is known to work with Windows 7.
Another problem might be that local system connections don't work as I seem to remember that Firebird 1.5 uses an older local protocol which doesn't work on newer Windows versions. This protocol was replaced in Firebird 2.0. To workaround that you need to include the hostname in the CREATE DATABASE or CONNECT statement, so for example:
create database 'localhost:C:\test.fdb' user 'SYSDBA' password 'masterkey';
Windows 7+ breaks the local api protocol. You have to use Tcpip protocol to connect to the database, even for local connections.