Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
The GSSAPI plugin only accepts user if username matches, which for some use might be too restrictive.
Here https://mariadb.com/kb/en/the-community-is-chaining-upns-via-authentication_options-when-using-the-gs/ a user struggles to move from MySQL Windows authentication (which is GSSAPI, under the hood, mostly), and what he actually needs is a plugin supporting Active Directory group membership. This is easily done since on the server side we will get a user's token, and group membership is easily derived from the token.
The proposed syntax
GROUP prefix
CREATE USER root IDENTIFIED VIA gssapi as 'GROUP:Administrators' |
CREATE USER root IDENTIFIED VIA gssapi as 'GROUP:BUILTIN\\Administrators' |
SID prefix
CREATE USER root IDENTIFIED VIA gssapi as 'SID:S-1-5-32-544' # usual SID form) |
CREATE USER everyone IDENTIFIED VIA gssapi as 'SID:WD' #well-known SID 2 letter prefix (WD=world, Everyone) |
The lookup by SID was suggested by users in the above mentioned KB discussion, will perform slightly better, performance-wise, and won't need lookups in the AD. SID potentially can also be used with Unix kerberos, in case AD is used (i.e Linux or Mac join Windows domain) , there will be membership data in kerberos ticket in this case.
The GROUP: or SID: prefixes are case-sensitive, and there should not be any extra spaces in the string.
Implementation
The GROUP: prefix will cause need group name to SID transation (LookupAccountName, which can cause roundtrip to AD)
the SID: prefix will cause string SID to binary SID translation (ConvertSidStringToSid)
Once the SID is here, server impersonates the SSPI context,checks membership via CheckTokenMembership() API, then impersonation is reverted, and the returns result of the check as CR_OK or CR_ERROR
Note , that neither GROUP name nor SID need to be actual group in AD or local computer. It can be the name or SID of the user (this is just how CheckTokenMembership() works)
Note also, that CheckTokenMembership checks for ENABLED flags in current token groups. The practical implication is that to use "GROUP:Administrators in the UAC environment, client process must run elevated ("as Administrator")
Attachments
Activity
Hi @vlad, I think it would also be useful, if one could authenticate with more than one group, like for instance:
CREATE USER root IDENTIFIED VIA gssapi as 'GROUP:Administrators' OR gssapi as 'GROUP:OtherGroup'
CREATE USER root IDENTIFIED VIA gssapi as 'GROUP:Administrators,GROUP:OtherGroup'
I definitely could make use of this – just as additional input/idea. I know that MySQL supports defining multiple groups this way.
Kunde I thought the first of your proposals would already work , or would not it? With 2 Kerberos handshakes, admittedly, this would be somewhat slower.
The second of your proposals, would not it be simple/preferable to handle things on the AD site, e.g create a group contains both Administrators and OtherGroup, call it MariaDBRootGroup?
I mean, now you're satisfied with groups separated by "," meaning OR, but tomorrow you might want an AND (member of both groups), and next day NOT (member of one group, but not another one), so we could end up creating own full-featured domain specific language just for "IDENTIFIED VIA gssapi AS" 
The first proposal (see it as two syntax options) already works with UPNs, correct – I only wanted to mention it here as possible use case. It can be useful if two user-groups should access one service, but in general you're right that this can be done on AD site as well.
From a logical perspective it always means OR, of course neither AND nor NOT – I get your point.
@serg , I understand that most of the Windows internal stuff might be uninteresting, but I'd like to have a feedback on functionality, as well as on suggested syntax with GROUP: and SID: prefixes.