[COMPASS-931] Spike: Research if/how Compass can be "kerberized" Created: 20/Mar/17  Updated: 04/Jan/19  Resolved: 15/Aug/18

Status: Closed
Project: Compass
Component/s: Connectivity
Affects Version/s: None
Fix Version/s: 1.16.0

Type: Task Priority: Major - P3
Reporter: Dinesh Chander Assignee: Durran Jordan
Resolution: Done Votes: 4
Labels: security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on NODE-1370 Update algorithm for Kerberos hostnam... Closed
Related
is related to COMPASS-851 Investigate Kerberos Authentication i... Closed
Epic Link: COMPASS-2286
Story Points: 3
Sprint: Iteration Guacamole, Iteration Halloumi

 Description   

Reported by Barclays (00430436).

When connecting to a Kerberos authenticated MongoDB deployment using Compass, we must supply the password from the Compass UI. Ideally, Compass should use the context of the logged in user and hence a password should not be needed unless a different context/user is needed to connect to the MongoDB deployment.

This is how "kerberized" applications usually behave, and while the current implementation works, it's unusual and unexpected for users used to work in a kerberos environment.



 Comments   
Comment by Sam Weaver [ 18/Jan/18 ]

emilio.scalise you can see the planned roadmap here: https://jira.mongodb.org/plugins/servlet/softwareplant-bigpicture/gantt its part of WEA: Kerberos work, which is planned currently for summer. Could be subject to change of course. That board is updated in real-time so feel free to use that for judgement.

Comment by Emilio Scalise [ 11/Jan/18 ]

Hi All,

I'm sorry if I ping you again. Is there any update on this?

Thanks,
Emilio

Comment by Sam Weaver [ 04/Oct/17 ]

emilio.scalise our current release plan is locked down for the November release. After that we will revisit this in our planning for the following few versions. I'll know more in end of Nov in terms of time frames.

Comment by Emilio Scalise [ 04/Oct/17 ]

Hi All,

Any update on this?

Thanks,
Emilio

Comment by Emilio Scalise [ 14/Jun/17 ]

Hi lucas.hrabovsky,

I have provided instructions on slack to use a Windows server AWS AMI we have with AD and Kerberos already configured. You just need to start an instance using that AMI.

Kind regards,
Emilio

Comment by Lucas Hrabovsky (Inactive) [ 14/Jun/17 ]

Moving this to blocked. Few questions to answer to unblock this:

Question #1: If we make kerberos_principal input field optional, would this just work as expected by users? Is c.driver_url below correct? [SOLVED]

var c = new Connection({
   kerberos_service_name: 'mongodb',
   kerberos_principal: 'arlo/dog@krb5.mongodb.parts',
   ns: 'bones'
 });
 console.log(c.driver_url)
 >>> 'mongodb://arlo%252Fdog%2540krb5.mongodb.parts@localhost:27017/bones?slaveOk=true&gssapiServiceName=mongodb&authMechanism=GSSAPI'

Solution

kerberos_password is already optional and confirmed is handled correctly.

Follow the docs on the wiki (make sure you are on the VPN).

☉ [master] codemirror-mongodb/ klist
Credentials cache: API:30A3D631-0EC3-4C57-9BE9-422CBE99D242
        Principal: drivers@LDAPTEST.10GEN.CC
 
  Issued                Expires               Principal
Jun 14 11:36:23 2017  Jun 14 21:36:18 2017  krbtgt/LDAPTEST.10GEN.CC@LDAPTEST.10GEN.CC
☉ [master] codemirror-mongodb/ klist
Credentials cache: API:30A3D631-0EC3-4C57-9BE9-422CBE99D242
        Principal: drivers@LDAPTEST.10GEN.CC
 
  Issued                Expires               Principal
Jun 14 11:57:26 2017  Jun 14 21:57:21 2017  krbtgt/LDAPTEST.10GEN.CC@LDAPTEST.10GEN.CC

Run the below in Compass devtools console:

var Connection = require('mongodb-connection-model');
connect = Connection.connect;
var c = new Connection({
  kerberos_principal: 'drivers@LDAPTEST.10GEN.CC',
  hostname: 'ldaptest.10gen.cc'
});
console.log('Driver URL:', c.driver_url);
connect(c, function(){}, function(err) {
  if (err) {
    return console.error('Did not work :/', err);
  }
  console.log('It worked!');
});

You see the below which confirms the behavior is correct.

>>> mongodb://drivers%40LDAPTEST.10GEN.CC:@ldaptest.10gen.cc:27017/?readPreference=primary&gssapiServiceName=mongodb&authMechanism=GSSAPI
>>> It worked!

Therefore, from the original description in the ticket ("we must supply the password from the Compass UI") there must be another problem (see new question below).

Question #2: What am I doing wrong below? [SOLVED]

I'm on a 2015 macbook pro w/ standard developer configuration, macOS Sierra, krb installed via homebrew

☉ [master] mongodb-query-parser/ cat /etc/krb5.conf
[realms]
  LDAPTEST.10GEN.CC = {
    kdc = ldaptest.10gen.cc
    admin_server = ldaptest.10gen.cc
  }
 
☉ [master] mongodb-query-parser/ kinit -p drivers@LDAPTEST.10GEN.CC
drivers@LDAPTEST.10GEN.CC's password:
☉ [master] mongodb-query-parser/ klist
Credentials cache: API:30A3D631-0EC3-4C57-9BE9-422CBE99D242
        Principal: drivers@LDAPTEST.10GEN.CC
 
  Issued                Expires               Principal
Jun 14 09:30:05 2017  Jun 14 19:29:55 2017  krbtgt/LDAPTEST.10GEN.CC@LDAPTEST.10GEN.CC
☉ [master] mongodb-query-parser/ mongo --host ldaptest.10gen.cc
MongoDB shell version v3.4.4
connecting to: mongodb://ldaptest.10gen.cc:27017/
MongoDB server version: 3.2.4
WARNING: shell and server versions do not match
Loading 0 mongorc packages...
MongoDB Enterprise > use $external;
switched to db $external
MongoDB Enterprise > db.auth({ mechanism: "GSSAPI", user: "drivers@LDAPTEST.10GEN.CC"} );
Error: SASL mechanism GSSAPI is not supported
0

SOLUTION

HT daniel.hatcher for pointing this out on Slack. I needed the enterprise distro of the shell and now this works!

Download http://downloads.mongodb.com/osx/mongodb-osx-x86_64-enterprise-3.4.5.tgz

☉ [master] mongodb-query-parser/ /Users/lucas/.mongodb/versions/mongodb-3.4.5-osx-64-enterprise/bin/mongo --host ldaptest.10gen.cc
MongoDB shell version v3.4.5
connecting to: mongodb://ldaptest.10gen.cc:27017/
MongoDB server version: 3.2.4
WARNING: shell and server versions do not match
Loading 0 mongorc packages...
MongoDB Enterprise > use $external;
switched to db $external
MongoDB Enterprise > db.auth({ mechanism: "GSSAPI", user: "drivers@LDAPTEST.10GEN.CC"} );
1

Question #3: Cross-realm?

Looking at CS-26551 ("Compass & Cross Realm Kerberos"). I also just looked at the node.js driver's functional test for Kerberos,
and it appears to have changed. I now see authMechanismProperties=SERVICE_NAME:mongodb,CANONICALIZE_HOST_NAME:false,SERVICE_REALM:windows in the URL.

Could this be the problem? Is gssapiServiceName from Question #1 above different from authMechanismProperties=SERVICE_NAME?

Question #4: Fetch the principal from the existing security context?

luke.prochazka mentioned SSPI. Looking at this issue on kerberos, this is possible per the below.

However, I don't have an ActiveDirectory to test this against or explore.

var kerberos = require('kerberos');
kerberos.SSPI.SecurityCredentials.acquire("Negotiate", "~", function(err, security_credentials) {
  console.log('Negotiated Security Credentials returned', err, security_credentials);
});

Comment by Luke Prochazka [ 14/Jun/17 ]

I think this feature request needs to be amended:

  1. SSO support for the Windows version only
  2. The auth login for SSO (perhaps via a checkbox) should be optional, as it may not be desirable to restrict login to the current user only

As an additional enhancement, it would be nice to report any security context impersonations as reported by the OS. This would apply in the case where a user enters different (but valid) credentials to the current security context. This would assist in reporting auth errors to the user, which would apply equally to the current non-SSO implementation.

Comment by Lucas Hrabovsky (Inactive) [ 04/May/17 ]

All of the business logic for how Compass understands Kerberos (and generally, defines how to map form input into the options passed to the node.js driver) lives in the mongodb-connection-model module. See the documentation for kerberos on nix and the special case for windows. If this documentation is incorrect or underspecified, please let me know asap.

When it comes to debugging or exploring viability of features suggested in recent comments: The underlying module used by the node.js driver that has the native bindings to system kerberos API's is located here

kerberos was purpose built for the node.js driver. It is intentionally under-documented as to not draw feature requests or bug reports based on usage outside of the node.js driver usage. If you open the devtools in Compass, require('kerberos') will give you a reference to the module at lib/kerberos.js. This module has pretty detailed docstrings and is where to start exploring possibilities. If you prefer to start from a lower-level or are more knowledgeable of c++ and kerberos inner-workings, see lib/kerberos.cc.

Please feel free to ping me in the #compass Slack channel for any clarification or assistance on the above.

Kerberos is very foreign to us but we understand it's importance in our customer organizations. We would be eager to connect with those at MongoDB who are familiar with Kerberos and interested in building together to make using it via Compass excellent.

Comment by Peter Schmidt [ 03/May/17 ]

Replace SAPgui with Compass in the following:
http://kb.mit.edu/confluence/display/istcontrib/GSS-API+miscellaneous+failure+matching+credentials+not+found

My reading of it is that if a Kerberos ticket is available on the user's machine then the user should not even need to provide their username. I'm not yet sure what the Kerberos ticket contains, perhaps on start up if said ticket is found Compass could expose that info to the user with Click to Log In as <ticket details>.

Comment by Danny Hatcher (Inactive) [ 03/May/17 ]

UI should be the same for both; you shouldn't need to provide a password in the interface for either implementation.

Comment by Idan Sher [ 03/May/17 ]

Should the Compass UI and logic be different for Linux based and Windows based OS's?

In windows if i'm not mistaken there should be no need to supply the password to get the kerberos ticket. However in Linux I believe currently I have to run kinit in the shell otherwise Compass will not be able to authenticate.

Comment by Thomas Rueckstiess [ 11/Apr/17 ]

Driver Kerberos testing instance: https://wiki.mongodb.com/display/DI/Testing+Kerberos

Comment by Lucas Hrabovsky (Inactive) [ 10/Apr/17 ]

christkv says:

this only works for Windows I think, MIT kerberos requires the auth to be done via the kerberos tooling xinit
the kerberos module should pick up the current logged in context on windows
problem with the kerberos thing is that we have never had an environment we can test in
so it’s only “theoretically working” using sspi
we know username/password works on windows because it’s been tested
but if you don’t pass username/password it should in theory use the logged in active record context
if this is something you really want to test we can help out if you could help figure out how to get a test environment set up

Comment by Thomas Rueckstiess [ 05/Apr/17 ]

sam.weaver this was brought up by Luke and Dinesh, working with Barclays (see case number above). Is this something you want to spend time on? This ticket would only be the research task, there would potentially be follow-up tickets to implement the behavior. As with all auth related issues, this is complex and would require many story points.

Generated at Wed Feb 07 22:26:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.