At 10:01 AM 3/06/2008, Luke Tigaris wrote:

>I do not understand what you mean when you say "Administrative
>authority should resolve to SYSDBA". Should windows user with
>Administrator rights on the local computer resolve to SYSDBA for
>service api calls or not? Because, if yes, this is not working.

Yes, sorry, I meant Administrator. But with your Authentication parameter set to trusted, you will get caught up in a conflict if you have the isc_user and isc_password environment variables set.

>Please explain the purpose of the isc_spb_trusted_auth parameter if
>Trusted Authentication cannot be used with the Services API.

<quote>
For the situation where trusted authentication is needed and there is a likelihood that the ISC_USER and ISC_PASSWORD variables are set, there is a new DPB parameter that you can add to the DPB—isc_dpb_trusted_auth.

Most of the Firebird command-line utilities support this parameter by means of the switch -tru[sted] (the abbreviated form is available, according to the usual rules for abbreviating switches).
Example
C:\Pr~\bin>isql srv:db -- log in using trusted authentication
C:\Pr~\bin>set ISC_USER=user1
C:\Pr~\bin>set ISC_PASSWORD=12345
C:\Pr~\bin>isql srv:db -- log in as 'user1' from environment
C:\Pr~\bin>isql -trust srv:db -- log in using trusted authentication
The qli and nbackup utilities do not follow the pattern: they use single-letter switches that are somewhat arcane. The switch of interest for qli is -K). The facility to force trusted authentication is yet to be implemented for nbackup
</quote>

>Also what is the purpose of the undocumented string block required by
>this parameter?

I don't know about any required "undocumented string block", sorry. I don't know what the command-line switches resolve to in the DPB but I'm assuming they cause the two environment variables to be read and then apply the results to the username and password fields of the DPB structure.Hopefully Dmitry will clarify this for you if/when he notices this (or you could ask directly on firebird-devel).

>I was hopeful that Firebird had taken a step forward to match the
>integrated security features of both MS SQL and Oracle (which have no
>such limitations), but this partial implementation of trusted
>authentication is very dissapointing.

I don't know if it's a factor in your problems but trusted authentication won't work if your OS user names pan out with a length exceeding Firebird's max user name length (31 characters). So look at the combination of domain + '\' + OS user name and see whether this is the issue that is interfering with your SYSDBA resolution.

e.g., here,
select current_user from rdb$database
gives me 'minion\Administrator' (20 characters)
and I'm logged in with SYSDBA privileges.

./heLen