Subject | Re: [firebird-support] Looking for detailed documentation on the new Firebird 3 security authentication process. |
---|---|
Author | Dalton Calford |
Post date | 2016-10-21T13:17:04Z |
Hi Alain,
For roles and trusted authentication (which is what I am discussing here) you use the "set trusted role" command.
With trusted authentication (when you use the OS/network to authenticate the user) you are not passing role information and the dba needs to apply trusted roles which work in the same way that you can automatically have members of the windows administrator/superuser group, log on as the RDB$ADMIN role without needing to specify it or having it granted explicitly.
You can even change your current role within the context of a connection via the set role command.
With earlier versions of firebird, we had to manipulate user rights using example user groups and default users. The current security enhancements in version 3 remove that need and now we want to take it to the next step and merge the user authentication methods on the domain, reducing the IT management and DBA user management tasks.
best regards
Dalton
Sent: October 21, 2016 4:32:10 AM
To: Dalton Calford
Cc: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Looking for detailed documentation on the new Firebird 3 security authentication process.
34 Dr Ross Avenue
Rose Hill 72102
Mauritius
Mobile Tel: +230 5 719 30 30
Hi Alain,
We use full user authentication at our company, so everyone logs into the database using their own credentials. Currently, each user has an account in the firebird security database. Each user also has a windows domain account. This means each user has, at a minimum, two separate usernames and passwords to maintain, while IT staff have to be diligent to clean up users from the firebird security database, after a staff member has left the company.
When I log onto a Firebird Database, without providing username or password, on a linux host, the Firebird engine uses my local linux username as my Firebird username and I have any rights that the SYSDBA has granted to my linux username, even though, my linux user name is not in the firebird security database.
Firebird on windows, starting with the 2.x version, started to allow this behaviour and new security grant commands where created to allow for default rights (such as someone with administrative rights on the local machine automatically logging in as themselves with sysdba role access rights). So, if you logged into your windows machine as "MY_COMPANY_DOMAIN\MY_DOMAIN_ WINDOWS_USER_NAME" and opened a firebird connection as yourself, then you would see the above when you did a select current_user ..... in the database.
With Firebird 3.0, this has been extended so that trusted rights are passed from windows machine to windows machine in the same domain. This is accomplished by the client, who verified the user via the domain authentication/password, sending a time/domain sensitive token to the server, which the server then uses to get the details about the user and provides the user ID to any software that requests it. This means you only administrate one set of user accounts for all your databases and those are the same accounts used for machine login and OS/network rights.
So a user changes their domain password and immediately their firebird password changes as well.
This works on a windows to windows basis, but, when a windows client, tries to attach to a linux server using the same mechanism, the connection fails. This is true even is the linux box is a full member of the domain via samba.
So, that is why Samba is important - it means the Linux User Authentication Method is linked to the Windows User Authentication Method and that means that the firebird database server does not need to maintain a separate security database for authentication as the OS handles that. Of coarse, SQL rights are still managed and maintained within the database itself.
For people who are not familiar with domain trusts, linux or plugin authentication modules, could be confused by this. It also is not needed by users who only use the SYSDBA account.
I am looking for as much infomation as I can get, in order to either write a module that queries the linux PAM system, by providing the user provided USERNAME/PASSWORD or, better yet, have it take care of the handshake with the domain for the use of the windows token.
I hope this explains why Samba is needed, why this is different from actual grants and what my questions where about.
I am asking here as I am trying to determine if this is already available but the documentation is hard to find, or, barring that, I will in turn ask on the development list.
best regards
Dalton
From: Alain Bastien <alainbastien@...>
Sent: October 20, 2016 4:50:34 AM
To: Dalton Calford
Subject: Fwd: [firebird-support] Looking for detailed documentation on the new Firebird 3 security authentication process.Is that your issue ?May I reply ?
are enough. SAMBA access has nothing to do with.
As far as I know and performed the same experience, Only the Grant function SYSDBA gives to the user to a DATABASE and/or specific VIEWS and/or TABLES
Kind RegardsAlain Bastien
34 Dr Ross Avenue
Rose Hill 72102
Mauritius
Mobile Tel: +230 5 719 30 30
Skype:alainbastien
Viber: 7320143
---------- Forwarded message ----------
From: Dalton Calford dcalford@... [firebird-support] <firebird-support@yahoogroups. com>
Date: Wed, Oct 19, 2016 at 10:03 PM
Subject: [firebird-support] Looking for detailed documentation on the new Firebird 3 security authentication process.
To: "firebird-support@yahoogroups. com" <firebird-support@yahoogroups. com>
Hi Everyone.
I have a linux machine (Ubuntu 16.04 64bit Server) with Firebird 3.01 64 bit installed.
That machine is a member of our corporate domain and authenticates via PAM/Samba4 for all user access.
I want to have Firebird client applications on remote windows machines to use the linux user authentication (PAM/DOMAIN) instead of a security database.
Is this currently possible? Is this theorectically possible? Where can I find documentation for this?
best regards
Dalton