[SERVER-19468] Create a flag to allow server principal realm to be specified explicitly Created: 17/Jul/15  Updated: 18/Sep/15  Resolved: 18/Sep/15

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Andre de Frere Assignee: Spencer Jackson
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Sprint: Security 8 08/28/15, Security 9 (09/18/15)
Participants:

 Description   

Add a flag to MongoDB CLI to specify server principal realm to be specified explicitly.

 --gssapiServiceRealm arg     Service realm to use when authenticating using GSSAPI/Kerberos

This would all authentication in a flexible way when Kerberos Cross-Realm is in place.



 Comments   
Comment by Spencer Jackson [ 18/Sep/15 ]

I've done some investigation into this, and I don't think this feature is feasible. It appears that the relevant call down to gss_import_name in Cyrus SASL uses GSS_C_NT_HOSTBASED_SERVICE. Per libkrb5's documentation(http://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html):

"""
GSS_C_NT_HOSTBASED_SERVICE: The value should be a string of the form service or service@hostname. This is the most common way to name target services when initiating a security context, and is the most likely name type to work across multiple mechanisms.
"""

So, libkrb5 is going to be receiving a hostname from which it will attempt to derive the realm. There doesn't seem to be a clear way to override this derivation from the shell's code. However, if DNS resolution or KDC referrals are not sufficient, it is possible to configure krb5.conf's 'domain_realm' section. For my testing on my own machine, I was able to use a statement like:

[domain_realm]
	localhost.localdomain = REALM_TWO

Given that this feature request conflicts with the current structure of third party libraries, and there is a way to achieve the desired behaviour via configuration file changes, I am closing this ticket.

Generated at Thu Feb 08 03:51:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.