Migration from Firebird 1.5 to Firebird 4 Security.fdb

[jez-smxi]

Backed up and restored from 1.5 > 2 > 2.5 >3.0 > 4 (SuperServer)

Following the upgrade instructions in the misc/upgrade folder:

_In firebird 2.5 backup security database:
gbak -user sysdba -pas masterkey -b {host/path}security2.fdb security.fbk

In firebird 3 restore copy of 2.5 security database:
gbak -user sysdba -pas masterkey -c security.fbk {host/path}security2.5
And run users upgrade sql script:
isql -user sysdba -pas masterkey -i security_database.sql {host/path}security2.5_

There are no PLG$USERS or PLG$SRP tables created when restoring from 2.5 to 3.0. There is only the RDB$USERS table.

[aafemt]

Tables belonging to SRP user manager are created only when first SRP user is created. By design.

[jez-smxi]

But isnt that what the security_database.sql is supposed to do?

sql = 'create or alter user "' || usr || '" password ''' || passwd || '''';
if (frst is not null) then sql = sql || ' firstname ''' || frst || '''';
if (mddl is not null) then sql = sql || ' middlename ''' || mddl || '''';
if (lst is not null) then sql = sql || ' lastname ''' || lst || '''';
sql = sql || ' active';

[mrotteveel]

Only if Srp is the first entry in UserManager, otherwise you must explicitly include the using plugin Srp clause.

[jez-smxi]

conf:

Per-database configurable.

UserManager = Srp

Still no PLG$USERS /SRP tables

I am following the guide from here: https://ib-aid.com/download/docs/fb4migrationguide.html

What am i missing?

[mrotteveel]

Also, for support questions, please use firebird-support or create a discussion instead of an issue. Issues are for bug reports and feature requests. I'll convert this issue to a discussion shortly.

[jez-smxi]

Thanks, but is this is an issue or a discussion? I have followed the official migration documentation to the letter.

The top Security 3 database is the restored 1.5 database with the update script security_database.sql ran after restoring (still with RDB$USERS) and the sec3orig is the vanilla security.fdb taken from a new install of firebird 3.

Should they not be the same structure?

[aafemt]

No. Structure of security database in Firebird3 depends on used user manager plugin(s). Your migration process most likely included changes of UserManager and *Auth settings in firebird.conf to allow usage of legacy security database.

[jez-smxi]

Yes, it would have done. The SRP plugin didn't exist before Firebird 3.0.
Does that then mean that any migration from firebird 1.5 to anything greater than Firebird 3 will be stuck with using Legacy_auth?

[aafemt]

It depends on your migration plan.

If you want to preserve users with passwords - yes, you are stuck with legacy auth.

If you want to use the security_database.sql which replaces passwords with random strings - no, SRP will work perfectly but old users won't know new passwords and thus won't be able to connect without you explicitly assign passwords to them. (Which is good in the case if you want to drop dead users during migration.)

If you want old users still have old passwords but new users to use more secure SRP - also no, you just need to make SRP auth preferable and do not use security_database.sql.

[jez-smxi]

Aye, that's the way I read it. But I was expecting to replace the passwords (the second option you listed) but in doing so I also expected the PLG$USERS /SRP tables to be created and the and the ID and PASSWD domains, not the RDB$USERS table when the usermanager is SRP. Although there's no mention of it in the documents, I was just assuming this was the case. Am I wrong?

[mrotteveel]

Which setting do you have for UserManager in firebird.conf?

[jez-smxi]

I had it set to SRP. However the user now wants to keep legacy auth so I guess I don't need the PLG users /srp or any of those domains.

[aafemt]

Generally you shouldn't care about content of security database at all.

[jez-smxi]

I probably wouldn't if I didn't keep getting this error:

MEDC-VMINK-01  Thu Feb 20 10:58:02 2025
  Authentication error
  cannot attach to password database
  Error in isc_compile_request() API call when working with legacy security database
  table PLG$USERS is not defined