Comments - Is chaining UPNs via "authentication_options" when using the GSSAPI Plugin considered safe?

3 years, 5 months ago jo_ku_ Kunde

Hi folks,

I made a little progress on that one. The permission object containing the required user information is stored in the form of a JSON object in the table "mysql.global_priv" within a field named "Priv" [1]. Starting with MariaDB v10.4 "mysql.user" has been replaced with "mysql.global_priv" and "mysql.user" now is just a database view and not a regular table at all (I was not aware of that fact, under MySQL v5.7.28 it is a table) [2][3]. The last "authentication_option" from the create user statement is stored under the key "authentication_string" in the mentioned JSON object, which is why this one is returned in the column "authentication_string" when querying the "user" view. The content of the "Priv" field to the above shown create user statement looks as follows:

{ "access":0, "version_id":100505, "plugin":"gssapi", "authentication_string":"username_3@MY_DOMAIN", "auth_or":[ { "plugin":"gssapi", "authentication_string":"username_1@MY_DOMAIN" }, { "plugin":"gssapi", "authentication_string":"username_2@MY_DOMAIN" }, {

} ], "password_last_changed":1602144036 }

Anyway, I'm still interested in any feedback from the community.

Best regards Johannes

[1] https://mariadb.com/kb/en/mysqlglobal_priv-table/ [2] https://mariadb.com/kb/en/mysqluser-table/ [3] https://dev.mysql.com/doc/refman/5.7/en/connection-access.html

 
3 years, 5 months ago Vladislav Vaintroub

Do you want GSSAPI to support group names on Windows on server side? I think this is a no brainer for implementation, and that it is a good feature, even if not portable outside of Windows.

 
3 years, 5 months ago Vladislav Vaintroub

I created MDEV-23959 to track "support groups in GSSAPI plugin on Windows".

 
3 years, 5 months ago jo_ku_ Kunde

Hi Vlad,

yes, we'd like to use AD groups to authorize Kerberos-authenticated users. I will split my elaboration for SSPI and GSS-API because they need to be treated differently, but both can make use of AD groups out of the box with some effort.

SSPI: I believe the best spot is here [1]. When the username does not match, retrieve all AD groups of the user via Windows API and match a string representation of it against the auth_string provided in a loop. You'll know even better where to look for sure.

GSS-API: Luckily, all Kerberos tickets from AD contain full group memberships embedded in the PAC data. MIT Kerberos offers to extract name attributes [2] after the context has been established. It will already break up the PAC data structure in sub blobs for you and make it available (sample code is in mod_gssapi for the retrieval). You will need to parse this structure [3] which is available via the 'urn:mspac:logon-info"' attribute (see src/lib/krb5/krb/pac.c). A complete Java impl can be found here [4] for reference.

With that both worlds can easily make use of the same AD groups.

A word on group name formats: As you can see PAC data provides the group SIDs only which need to be converted/formatted to its string representation 'S-1-...'. Windows API provides various output formats. I would highly recommend, for consistency reasons, to make it configurable on Windows (SSPI) what the group name format is: downlevel name or SID. This would make it consistent on both platforms to use. We use SIDs exclusively in our Java webapps.

Many thanks in advance!

Best regards,

Johannes

[1] https://github.com/MariaDB/server/blob/cccfa9dcfe2c161779824c01a84edfa64fc4378a/plugin/auth_gssapi/sspi_server.cc#L265-L271

[2] https://web.mit.edu/kerberos/krb5-latest/doc/appdev/gssapi.html#name-attributes

[3] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/69e86ccc-85e3-41b9-b514-7d969cd0ed73

[4] https://github.com/cbsit/JaasLounge

 
3 years, 5 months ago Vladislav Vaintroub

Thanks a lot for this information, this is helpful. I think supporting both SIDs and names on Windows is a relatively easy thing, and natural on Windows. although SIDs might be less natural for application than group names, it is easy to figure out that string is a SID.

Now on Unixen, groups could be handled as an ActiveDirectory specific extension, for boxes than join Windows domain. The pure MIT kerberos KDC has no groups, an no LDAP, to my knowlegde. This is something I'm a little less familiar with, and might need some more time. SID-only option seems a little user-unfriendly.

 
3 years, 5 months ago Michael -O

Hi Vlad,

I was involved in the analysis for/with Johannes.

although SIDs might be less natural for application than group names, it is easy to figure out that string is a SID.

Microsoft's approach is to test for 'S-' prefix.

Now on Unixen, groups could be handled as an ActiveDirectory specific extension, for boxes than join Windows domain. The pure MIT kerberos KDC has no groups, an no LDAP, to my knowlegde.

Correct. But I don't see to add any configure/compile time option for this. It could be simply a module option "use PAC groups" or similar. If the attribute name value is present, read it otherwise fail the authnz.

This is something I'm a little less familiar with, and might need some more time.

I will happily support and can provide plenty PAC data privately if necessary.

SID-only option seems a little user-unfriendly.

There is no other option on Unix. Consider that this is not for users, but for admins. From my point of view, I see little difference because in our huge (and likely others) environment our groups are DOMAIN\cryptic-very-long-name vs. S-1-5-21-<group-sid>-<rid>. I treat them as opaque strings because I don't memorize the 100 gorups I have anyway. See also here a justification why SIDs are better than names in large environments [1].

What one could do is to map SIDs to app specific friendly names like I do in Java [1], but that would require more code in MariaDB and I don't see a need for now.

[1] http://tomcatspnegoad.sourceforge.net/realms.html#Using_Security_Groups_from_Active_Directory.

 
3 years, 4 months ago Vladislav Vaintroub

Hi Michael-O and Johannes, I updated https://jira.mariadb.org/browse/MDEV-23959, group and SID support on Windows, with details. Feel free to discuss comment in the JIRA ticket.

 
3 years, 4 months ago jo_ku_ Kunde

Hi Vlad, I just checked your updates in the JIRA ticket. I think the proposed solution covers my needs perfectly and will make the switch over to MariaDB possible. Also the suggested prefixes GROUP and SID make sense and implementing it that way would pull Unix users in as well. Thanks for your support!

 
3 years, 5 months ago Vladislav Vaintroub

Hi Michael, I see, but again, given the first request was concerned about migration from Oracle Windows auth plugin, I assume the importance of Windows here is higher.

It is not that I mind having some AD option for Unixen, SID or not-SID, but it seems to be entering an uncharted territory with unknown effort to be spent . See, for the most part, on Unixen this plugin currently is just plain GSSAPI, and apart from get_default_principal_name(), there are even no krb5_ functions in there.

So, it operates on in the Unix plugin, is gss_cred_id_t cred, gss_ctx_id_t ctxt and gss_name_t client_name Those are initialized whenever the handshake is finished.

I presume there is something in ctxt that can be extracted in some way, but I'm not really sure how :) And once it is extracted, I did not find any krb5_pac function that would allow to iterate over SIDs. If it would require parsing like JAASLounge is doing it, this would be a larger effort. I did not find any OSS C++ code that can be reused, I'm sure SAMBA will be doing something like that, somewhere, but I'm unfamiliar with their code either.

If that is important, you can create a JIRA ticket asking for supporting AD SID on Unix , nd we can discuss it there. Larger discussions on KB are rather seldom, JIRA can be a better place.

 
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.