On 09-02-2021 13:05, Tom Conlon wrote:
> Also, I was expecting that even if not on a domain, the client machine
> user would be presented to the "server" as
> machinename/windowsusername and that the another aspect of the "trusted"
> part was that the user had been trusted/able to log into the local
> windows account.
That is not how it works, because that would be very insecure, as any
John Doe could hookup a machine to the network, login as Administrator
or impersonate any user and then login to Firebird as that user.
Very simplified: Windows SSPI as used by Firebird is a protocol where
the client machine presents a token as credentials, and the server asks
its Windows host to verify that credential. The only way that the token
can be verified is if both machines are in the same domain (though maybe
federated domains could work as well, not sure), or the client and
server are the same machine.
As far as I understand it, the "trusted" in trusted authentication
doesn't mean that Firebird simply believes the client, it refers to the
fact that Firebird itself doesn't perform the authentication, but
delegates that responsibility to a third-party (it trusts the Windows host).
NOTE: I might have some details wrong, because I'm not an expert in this
> Therefore not so obvious in some ways Dmitry plus with the 2
> possibilities with VPNs & a no-go on peer-to-peer personally I would
> have thought a note about this in the trusted windows authentication
> documentation would be helpful, esp to non-networking specialists.
Yes, the documentation is not very clear in this area. To be honest,
until recently I had similar expectations as you have.