Update FB 3.0.7 to 3.0.10 suddenly User Name and Password not accepted

[Chuck Belanger]

Hello:

Typically when updating FB for use with my 32 bit app, I simply copy the
latest 32 bit fbclient.dll to the same directory as the app. This
accesses the FB 64 bit server just fine.

With this update, I did the above and was getting the error, "user name
and password" not defined.

In IBExpert:

If I point to the fbclient.dll within the zip extracted 3.0.10 Firebird
x86 directory, the DB opens with the assigned password, not "masterkey",
just fine. If I point to the fbclient.dll (I just copied it to the app
directory), I get the user name/password error. The fbclient.dll is the
same file in both cases.

The server itself is in the Program Files directory and is 64 bit.

But, if I change the password to "masterkey", the DB connects properly
to the server via the app directory located fbclient.dll.

Somehow, the app directory fbclient.dll is not seeing the security3.fdb? Or?

Never had this issue before. What is happening here or needs to be done?

Thank you for any clarification!

Chuck Belanger


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Mark Rotteveel]

On 30-06-2022 09:59, Chuck Belanger wrote:
> Typically when updating FB for use with my 32 bit app, I simply copy the
> latest 32 bit fbclient.dll to the same directory as the app. This
> accesses the FB 64 bit server just fine.
>
> With this update, I did the above and was getting the error, "user name
> and password" not defined.
>
> In IBExpert:
>
> If I point to the fbclient.dll within the zip extracted 3.0.10 Firebird
> x86 directory, the DB opens with the assigned password, not "masterkey",
> just fine. If I point to the fbclient.dll (I just copied it to the app
> directory), I get the user name/password error. The fbclient.dll is the
> same file in both cases.
>
> The server itself is in the Program Files directory and is 64 bit.
>
> But, if I change the password to "masterkey", the DB connects properly
> to the server via the app directory located fbclient.dll.
>
> Somehow, the app directory fbclient.dll is not seeing the security3.fdb?
> Or?

Fbclient.dll does nothing with the security database, authentication is
server-side. It sounds like when you're pointing to the fbclient.dll in
the extracted Firebird, you might actually be using embedded mode to
open the database (assuming the database is on the same host), or
possibly you are missing some dependency when fbclient.dll is in your
application directory, while that dependency is picked up when pointing
to extract Firebird.

> Never had this issue before. What is happening here or needs to be done?

I would recommend trying one (or all) of the following:

- Running the vccrt10_Win32.msi from the system32 directory of the zipkit.
- performing a client-only install with the 32-bit installer to see if
that solves your problem.
- Copy the msvcp100.dll and msvcr100.dll to your application directory

Mark
--
Mark Rotteveel

[Chuck Belanger]

Thank you for your previous response. Sorry, I accidentally responded to
you personally rather than the group.

Included is that response:

Thank you, Mark for the suggestions.

Nothing worked.

I did the following:

1. - Running the vccrt10_Win32.msi from the system32 directory of the
zipkit.  NO CHANGE

2. - Copy the msvcp100.dll and msvcr100.dll to your application
directory NO CHANGE

3. - performing a client-only install with the 32-bit installer to see
if that solves your problem. NO CHANGE

Noted that in online doc that there was a client only option during the
installation process, but when running the 32 bit, Windows exe
installer, no such option was given, only "enable authorization for
legacy firebird clients."

4. Tried pointing to the FB 3.0.10 zip extraction, fbclient.dll and that
worked but it was definitely in embedded mode, since any password would
then work, including "masterkey" or the assigned password or even
"anything."

5. As long as I was trying to connect to a remote DB (i.e. I install 64
bit FB on the app's host system and am trying to use FBClient.dll to
connect to the local DB), then the connection works as expected
regarding authentication. The app has a remote authorization db that it
connects to to make sure the user is properly registered.

6. Tried to point to the fbclient.dll in the WOW64 folder of the
installed FB64 and even though engine12.dll is present, I get error
"engine12.dll is present but cannot be loaded; unknown error."

Any other suggestions?

Thank you!

Chuck

Just tried something else:

It was looking to me that based on the error response and finding that
'masterkey' worked (and no other PW worked, unlike the embedded FB),
that perhaps the fbclient in the app directory was trying to access a
blank security3.fdb.

I checked and I have multiple security3.fdb files on my developer
system. So, what I did was open the DB in IBExpert with the client
pointing to the fbclient.dll in the app directory and then look at the
file date that was changed in which security3.fdb.

In fact it was attempting to access the installed FB 3.0 64bit
security3.fdb, as expected, except for the "user/password not defined"
error.

To confirm, I used the exact same fbclient.dll, but pointing to the
directory that was the expanded/unzipped Win32 3.0.10, and that DB
required the assigned password to open. "Masterkey" did not work. And
yes, the correct, installed FB security3.fdb was accessed as determined
by the file date time change.

So now I am really confused about what is happening here.

To be clear, the user is still SYSDBA for all attempts. The fbclient.dll
file is identical in both of the above cases, except for its directory
location. But when in the app directory, ONLY 'masterkey' works  (my
point being that it is not acting as "embedded") and when using the
Win32 zip of FB 3.0.10 expanded location, ONLY the assigned password
works, as intended.

Any idea of what is going on here? Any other suggestions or detective
work you may suggest? My goal is to use fbclient.dll in the app
directory and still use another password besides 'masterkey.'

Thank you,

Chuck

[Alexey Kovyazin]

Hello,

check that you have correct authentication plugins and user managers in firebird.conf: I guess you need Srp, Legacy_UserManager.

Regards,

Alexey Kovyazin

IBSurgeon

пт, 1 июл. 2022 г., 05:30 Chuck Belanger <phyt...@lanset.com>:

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/d4979908-b902-dd75-f1fb-918aa0d4af03%40lanset.com.

[Chuck Belanger]

Thank you, Alexey, for the suggestion.

For the problem setup, i.e. fbclient.dll in the app directory, I am no longer getting "user/pw error" but "connection lost to database".

My firebird.conf: changed the authentication plugins from srp to srp, Legacy_userManager.

Any other suggestions? Again, with above changes, 'masterkey' does properly connect. When I use the assigned pw, then it causes the above error.

Thank you!

Chuck

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/CAH0_ZaR-KWN1_Yjw1b%3Dny2kp74hdSq3ZGKQ7HitxM2aDRj0P%3Dw%40mail.gmail.com.

Virus-free. www.avast.com

[Mark Rotteveel]

On 01-07-2022 04:30, Chuck Belanger wrote:
> Thank you for your previous response. Sorry, I accidentally responded to
> you personally rather than the group.
>
> Included is that response:
>
> Thank you, Mark for the suggestions.
>
> Nothing worked.
>
> I did the following:
>
> 1. - Running the vccrt10_Win32.msi from the system32 directory of the
> zipkit.  NO CHANGE
>
> 2. - Copy the msvcp100.dll and msvcr100.dll to your application
> directory NO CHANGE
>
> 3. - performing a client-only install with the 32-bit installer to see
> if that solves your problem. NO CHANGE
>
> Noted that in online doc that there was a client only option during the
> installation process, but when running the 32 bit, Windows exe
> installer, no such option was given, only "enable authorization for
> legacy firebird clients."

That is an entirely different option that is unrelated to my suggestion.

I am talking about the "Select components" window that shows the options
"Full installation [..]", "Installation of Client tools [..]", "Minimum
client install [..]" and "Custom installation", with checkboxes for
"Server components", "Developer and admin tools components", and "Client
components". (see attached screenshot of
"Firebird-3.0.10.33601_0_Win32.exe" on my machine)

However, it is possible that it is skipped for an existing install (not
sure about that).

> 4. Tried pointing to the FB 3.0.10 zip extraction, fbclient.dll and that
> worked but it was definitely in embedded mode, since any password would
> then work, including "masterkey" or the assigned password or even
> "anything."
>
> 5. As long as I was trying to connect to a remote DB (i.e. I install 64
> bit FB on the app's host system and am trying to use FBClient.dll to
> connect to the local DB), then the connection works as expected
> regarding authentication. The app has a remote authorization db that it
> connects to to make sure the user is properly registered.
>
> 6. Tried to point to the fbclient.dll in the WOW64 folder of the
> installed FB64 and even though engine12.dll is present, I get error
> "engine12.dll is present but cannot be loaded; unknown error."

If your app is 32-bit, it can't use the engine12.dll of a 64-bit
Firebird (and even if it could, it wouldn't be able to find it, because
engine12.dll would need to be in the plugin directory relative to the
fbclient.dll). However, this suggests that you're using a connection
string that prefers using embedded instead of a server connection. What
is the connection string used by your application? Does it contain only
a filename?

> Any other suggestions?
>
> Thank you!
>
> Chuck
>
> Just tried something else:
>
> It was looking to me that based on the error response and finding that
> 'masterkey' worked (and no other PW worked, unlike the embedded FB),
> that perhaps the fbclient in the app directory was trying to access a
> blank security3.fdb.

Fbclient doesn't do anything with the security database, it is the
server that checks authentication against the security database.

However, it could suggest a problem with the authentication plugin used
(e.g. your users are setup with Legacy_Auth, but after the install, you
only have Srp/Srp256 enabled, or vice versa.

So the important thing is, what are the settings in firebird.conf for
AuthServer, AuthClient, and UserManager?

To check for which authentication plugin users are created, make sure to
configure UserManager = Srp, Legacy_UserManager (and restart Firebird),
make sure to edit with elevated admin privileges. You can then execute -
as SYSDBA - select sec$user_name, sec$plugin from sec$users; to see
under which plugin your users are created.

To check which authentication plugin is used, check MON$CONNECTIONS.

> I checked and I have multiple security3.fdb files on my developer
> system. So, what I did was open the DB in IBExpert with the client
> pointing to the fbclient.dll in the app directory and then look at the
> file date that was changed in which security3.fdb.
>
> In fact it was attempting to access the installed FB 3.0 64bit
> security3.fdb, as expected, except for the "user/password not defined"
> error.
>
> To confirm, I used the exact same fbclient.dll, but pointing to the
> directory that was the expanded/unzipped Win32 3.0.10, and that DB
> required the assigned password to open. "Masterkey" did not work. And
> yes, the correct, installed FB security3.fdb was accessed as determined
> by the file date time change.
>
> So now I am really confused about what is happening here.
>
> To be clear, the user is still SYSDBA for all attempts. The fbclient.dll
> file is identical in both of the above cases, except for its directory
> location. But when in the app directory, ONLY 'masterkey' works  (my
> point being that it is not acting as "embedded") and when using the
> Win32 zip of FB 3.0.10 expanded location, ONLY the assigned password
> works, as intended.

Does your application have a firebird.conf in the same directory as its
fbclient.dll? If so, what value is configured for AuthClient?

This suggests that in one situation you're authenticating with a Srp
SYSDBA (likely with a non-default password), and in the other with a
Legacy_Auth SYSDBA (with the default password).

> Any idea of what is going on here? Any other suggestions or detective
> work you may suggest? My goal is to use fbclient.dll in the app
> directory and still use another password besides 'masterkey.'

Mark
--
Mark Rotteveel

[Chuck Belanger]

Hi, Mark:

Thank you for your detailed response. It got me on the eventual correct
path: turns out everything works fine if I copy the FB/Plugin folder to
my app folder.

I am still not sure why this is necessary, when in the past this has
never been the case.

Anyway, it's fixed and I appreciate your help.

Chuck

[Mark Rotteveel]

On 05-07-2022 12:22, Chuck Belanger wrote:
> Thank you for your detailed response. It got me on the eventual correct
> path: turns out everything works fine if I copy the FB/Plugin folder to
> my app folder.
>
> I am still not sure why this is necessary, when in the past this has
> never been the case.
>
> Anyway, it's fixed and I appreciate your help.

That would suggest legacy_auth and/or srp are not linked in
fbclient.dll, or you're connecting in a way that strongly prefers using
embedded, and by including the plugins/engine12.dll, you're now using
embedded (which means: no authentication, and not connecting through a
Firebird server).

Mark
--
Mark Rotteveel

[Chuck Belanger]

Thank you, again, Mark.

Turns out I was too eager to accept a connection without testing whether
it was acting as embedded. You are correct, copying the plugins folder
to the app directory merely sets up the connection as embedded.

Turns out the critical plugin was the x86 engine12.dll and as you noted
any password works.

The connection is Local, Default. I have been using IBExpert (x86 app
and requires 32bit fbclient.dll) test connection to check all this. On
changing to Local, Loopback and adding the assigned port, then it too
acted as embedded.

We are talking about the local DB for the app. There is also a remote DB
which the fbclient.dll in the app directory does connect properly with
the assigned password.

This is new behavior though for version 3.0.10. Not sure if having the
local DB accessed by embedded means is critical or not. What do you think?

Thank you,

Chuck

[Chuck Belanger]

Here's something from the manual
(https://firebirdsql.org/manual/qsg25-classic-or-super.html) and
(http://www.ibphoenix.com/files/Embedded_fb3.pdf) that might be an issue.

Right now I have the servers set up as SuperServer, but with embedded
that could be a problem when the app tries to connect with the remote DB
and others are either connected or try to connect, too. Right?

Thus, it sounds like if I can't get the app to connect to the local FB
server via the fbclient.dll, but use embedded, then I may need to change
the connection to SuperClassic (the local and remote server is 64 bit,
while the app and local embedded is 32 bit).

Is that about right?

Still wondering why this issue is popping up with the new FB version 3.0.10.

One advantage I noticed is that SuperClassic will automatically use all
the CPU cores.

Thank you again,

Chuck

[Karol Bieniaszewski]

>>Thus, it sounds like if I can't get the app to connect to the local FB

>>server via the fbclient.dll, but use embedded, then I may need to change

>>the connection to SuperClassic (the local and remote server is 64 bit,

>>while the app and local embedded is 32 bit).

 

>>Is that about right?

 

Always bitness of your application (client) determine bitness of the libraries used, here fbclient.dll, and if you use embeded, all other libraries like e.g. plugins.

Remote server bitness can be either 32 or 64, this does not metter.

You must know that remote server is when you specify IP or the DNS name of the server. It can be also LocalHost or 127.0.0.1.

 

Regards,

Karol Bieniaszewski

--

You received this message because you are subscribed to the Google Groups "firebird-support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/c0511649-7fec-6230-73e6-024f87bebdab%40lanset.com.

 

[Mark Rotteveel]

On 06-07-2022 00:25, Chuck Belanger wrote:
> Thank you, again, Mark.
>
> Turns out I was too eager to accept a connection without testing whether
> it was acting as embedded. You are correct, copying the plugins folder
> to the app directory merely sets up the connection as embedded.
>
> Turns out the critical plugin was the x86 engine12.dll and as you noted
> any password works.
>
> The connection is Local, Default. I have been using IBExpert (x86 app
> and requires 32bit fbclient.dll) test connection to check all this. On
> changing to Local, Loopback and adding the assigned port, then it too
> acted as embedded.
>
> We are talking about the local DB for the app. There is also a remote DB
> which the fbclient.dll in the app directory does connect properly with
> the assigned password.
>
> This is new behavior though for version 3.0.10. Not sure if having the
> local DB accessed by embedded means is critical or not. What do you think?

As far as I'm aware, this behaviour to prefer embedded was introduced
with Firebird 3.0.0, though it should fall back to XNET when there is no
engine12.dll present, IIRC. If you want a local connection, you need to
use a connection that explicitly starts with xnet:// (or with
localhost:, or with inet://localhost/).

I'll try to find some time to experiment to see if I can reproduce it.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Mark Rotteveel wrote 06.07.2022 15:43:
> As far as I'm aware, this behaviour to prefer embedded was introduced with
> Firebird 3.0.0, though it should fall back to XNET when there is no engine12.dll
> present, IIRC.

The preferences are controlled by order in which providers are listed in
firebird.conf. Engine is the first by default to improve server performance
eliminating wait for possible network name resolution and connect attempts (that
may last up to 1,5 minutes).

--
WBR, SD.

[Chuck Belanger]

Thank you, Mark and Dimitry:

Mark, your proper connection string helped.

In my program I am using IBObjects which has cpLocal, cpTCP_IP. I have
been using cpLocal. If I use cpTCP_IP and localhost as the server then
it works as expected.

IBExpert which I was using to see if things worked properly before
transferring things over to my program, has the option for local, inet,
tcp_ip, and several Xnet options. Not so with IBObjects, but as I
mentioned the cpTCP_ID protocol worked fine.

I did have to re-set the SYSDBA password, even though the FB installer
left the previous security3.fdb. Not sure why I had to do that, but it
eliminated the taking of only "masterkey" pw but not the assigned pw
(unlike when in embedded mode which could accept any pw). Once I
reassigned a new pw to SYSDBA, that pw and only that pw was accepted.

Also, and this is new, I cannot simply put fbclient.dll (x86) into my 32
bit app folder. Now requires the folders and contents of the intl,
plugins; I still need to confirm whether or not I need a local 32 bit
UDF folder.

Seems to require a separate client firebird.conf file. As Dimitry
pointed out the providers need to include engine12, remote.

I checked and this configuration definitely uses the 64 bit FB
directory's security3.fdb as it should.

I still have to make all the changes in my program's datamodules and
references and test that. Hoping that the above fixes everything.

Chuck

[Mark Rotteveel]

On 07-07-2022 12:39, Chuck Belanger wrote:
> Thank you, Mark and Dimitry:
>
> Mark, your proper connection string helped.
>
> In my program I am using IBObjects which has cpLocal, cpTCP_IP. I have
> been using cpLocal. If I use cpTCP_IP and localhost as the server then
> it works as expected.
>
> IBExpert which I was using to see if things worked properly before
> transferring things over to my program, has the option for local, inet,
> tcp_ip, and several Xnet options. Not so with IBObjects, but as I
> mentioned the cpTCP_ID protocol worked fine.

The problem is, local was - as far as I'm aware - never really a thing,
at least not on Windows, depending on the deployment and version, it
will use embedded or XNET (or maybe something else).

> I did have to re-set the SYSDBA password, even though the FB installer
> left the previous security3.fdb. Not sure why I had to do that, but it
> eliminated the taking of only "masterkey" pw but not the assigned pw
> (unlike when in embedded mode which could accept any pw). Once I
> reassigned a new pw to SYSDBA, that pw and only that pw was accepted.

Likely your previous install had a different configuration for
AuthServer and UserManager than your current install.

> Also, and this is new, I cannot simply put fbclient.dll (x86) into my 32
> bit app folder. Now requires the folders and contents of the intl,
> plugins; I still need to confirm whether or not I need a local 32 bit
> UDF folder.

That really should not be necessary for a straightforward client-only
deployment. Either this is a bug, or something weird is going on in your
setup.

> Seems to require a separate client firebird.conf file. As Dimitry
> pointed out the providers need to include engine12, remote.

If an fbclient.dll doesn't have a firebird.conf, it will use the default
settings (those listed in the default firebird.conf as commented out),
and that default is Remote,Engine12,Loopback. If it only works after
explicitly adding a firebird.conf, you might have a custom firebird.conf
in a location like the virtual-store or something like that.

Mark

--
Mark Rotteveel