[MXS-3526] GSSAPI authenticator supports only one principal and only the default location for the keytab Created: 2021-04-29 Updated: 2021-10-22 Resolved: 2021-09-22 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Authenticator |
| Affects Version/s: | 2.5.10 |
| Fix Version/s: | 6.2.0 |
| Type: | New Feature | Priority: | Critical |
| Reporter: | Jim Parks (Inactive) | Assignee: | Esa Korhonen |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Environment: |
All |
||
| Issue Links: |
|
||||||||
| Sprint: | MXS-SPRINT-137, MXS-SPRINT-138, MXS-SPRINT-139 | ||||||||
| Description |
|
GSSAPI authenticator documentation says: "The keytab file must be placed in the configured default location which almost always is /etc/krb5.keytab. To take GSSAPI authentication into use, add the following to the listener. authenticator=GSSAPIAuth After the listeners are configured, add the following to all servers that use GSSAPI users. authenticator=GSSAPIBackendAuth" I'm no expert on GSSAPI, but it seems like the principal_name should be set on a per-server basis rather than in the listener, since each of the backend MariaDB servers uses a different principal_name in its gssapi_principal_name variable for the GSSAPI plugin. Additionally, I think that we should be able to specify a separate keytab file for each server, since each of the backend servers has its own keytab, and the keytab location can be set via the gssapi_keytab_path variable on the DB server. The default keytab in /etc/krb5.keytab may be used by some other app. Even though it's possible to add principals to the default keytab, messing with the customer's non-MariaDB keytab files is probably not a great idea, because if we accidentally overwrite it, that could break something else. We currently have a customer who wants to set this up on MaxScale and three backend DB servers, but I can't figure out any way to make it work with the current options available. |
| Comments |
| Comment by markus makela [ 2021-04-30 ] |
|
I'll change this to a New Feature since this is the way it's currently expected to work. |
| Comment by Jim Parks (Inactive) [ 2021-04-30 ] |
|
Looking at older MaxScale docs, I notice that 2.1 had different instructions entirely. From https://mariadb.com/kb/en/mariadb-maxscale-21-gssapi-client-authenticator/ : "The first step is to create a new principal for MaxScale. This can be done with the kadmin or kadmin.local tools. kadmin.local -q "addprinc -nokey mariadb/example.com@EXAMPLE.COM" The next step is to export this principal into the Kerberos keytab file. kadmin.local -q "ktadd -k /etc/krb5.keytab -norandkey mariadb/example.com@EXAMPLE.COM" That all seems to make more sense than what the current docs for 2.5 are telling me. I'm wondering if the product actually changed, or if the docs are off. It's not trivial to test both ways, because I'd need to set up a working Kerberos GSSAPI setup with forward and reverse DNS, etc., and I don't have anything like that handy. |
| Comment by Esa Korhonen [ 2021-09-16 ] |
|
Custom location for keytab file is in MaxScale 6.2. MaxScale and all servers must still use the same keytab, as that allows MaxScale to forward the client token to servers when authenticating. |