Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23959

GSSAPI plugin - support AD or local group name , and SIDs on Windows




      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.

      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")




            serg Sergei Golubchik
            wlad Vladislav Vaintroub
            0 Vote for this issue
            3 Start watching this issue