Subject Trusted Authentication working with the Services API?
Author Luke Tigaris
I have some code I have been using for quite some time to perform
backups and restores using the services API. I spent the better part
of the day trying to get my code to work with the new Windows Trusted
Authentication mode available in 2.1, with no success.

Note that I've had no problems attaching to databases using the
trusted authentication, it is specifically the services api I am
having problems with. My firebird.conf file is configured with
Authentication = mixed.

So the shorthand series of api calls for a backup/restore is
isc_service_attach (svc_name = service_mgr)
isc_service_start
poll isc_service_query until done
isc_service_detach

The first time it hits isc_service_query I get an error back that my
User Name and Password is undefined.

I have tried using the new isc_spb_trusted_auth parameter, with no
success. Note that it appears to be undocumented that the
isc_spb_trusted_auth parameter requires a string block, but as to
what I should stick in there I am at a loss. I have tried (blank),
SYSDBA, and my Windows User Name.

I have also discovered a much simpler way to represent the problem.
Note the following gbak command line:
gbak.exe -r -p 16384 -
v "C:\Test\test_database.fbk" "C:\Test\test_database.fdb" -
y "C:\Test\test_database.log"

This command line will not work (no user name/password) in
Authentication = native, but will work just fine if Authentication =
mixed.

If I change the command line to:
gbak.exe -r -se service_mgr -p 16384 -
v "C:\Test\test_database.fbk" "C:\Test\test_database.fdb" -
y "C:\Test\test_database.log"

it will no longer work in Authentication = mixed (no user name /
password). The "-se service_mgr" parameter just tells gbak to use
the service api calls and the local protocol, which gbak appears to
be unable to do in trusted mode. Note that adding the parameter "-
trusted" does not affect this.

I am curious to know if the services api is broken in trusted
authentication mode, and whether this is a bug or intentional design,
as I was hoping to move away from using explicit database users and
passwords in the next version of our application, and this limitation
would make that impossible.

Thank you for your time,

Luke Tigaris
Chief Software Architect
PowerLaw, Inc.