[SERVER-13885] Kerberos Authentication on Windows from mongo client only works with FQDN Created: 08/May/14  Updated: 16/Nov/21  Resolved: 14/Oct/15

Status: Closed
Project: Core Server
Component/s: Security, Shell
Affects Version/s: 2.6.1
Fix Version/s: 3.2.0-rc0

Type: Bug Priority: Minor - P4
Reporter: David McLennan Assignee: Spencer Jackson
Resolution: Done Votes: 0
Labels: kerberos
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on CXX-228 Optional Canonicalization of SSPI hos... Closed
Documented
is documented by DOCS-9000 Kerberos Authentication on Windows fr... Closed
Duplicate
is duplicated by SERVER-19469 Create a flag to require hosts to be ... Closed
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Using the Mongo command line client supplied in the windows enterprise build of 2.6.1, connect using Kerberos authentication without supplying a FQDN in the URL.

Sprint: Security 8 08/28/15, Security 9 (09/18/15), Security A 10/09/15
Participants:

 Description   

When authenticating from a Windows 7 2.6.1 enterprise client to a MongoDB 2.4.9 enterprise instance using Kerberos, the connection will only succeed if the FQDN is used in the URL instead of the short host name. Clients on Linux seem unaffected by this problem.

Example 1 - Using FQDN in the URL and everything works;

C:\Apps\MongoDB\2.6.1\bin>mongo host10601.intranet.mydomain.com:27118/admin -
authenticationDatabase='$external' -authenticationMechanism=GSSAPI -username mclennad@INTRANET.MYDOMAIN.COM
MongoDB shell version: 2.6.1
connecting to: host10601.intranet.mydomain.com:27118/admin
>

Example 2 - Using short name and get a GSSAPI error;

C:\Apps\MongoDB\2.6.1\bin>mongo host10601:27118/admin -authenticationDatabase=
'$external' -authenticationMechanism=GSSAPI -username mclennad@INTRANET.MYDOMAIN.COM
MongoDB shell version: 2.6.1
connecting to: host10601:27118/admin
2014-05-08T18:00:31.602-0400 Error: 17 SASL(-1): generic failure: SSPI: InitializeSecurityContext: The specified target is unknown or unreachable
at src/mongo/shell/db.js:1210
exception: login failed

Example 3 - DNS lookup of short name showing that FQDN is available;
C:\Apps\MongoDB\2.6.1\bin>nslookup host10601
Server: host013.mydomain.com
Address: 10.X.X.X

Non-authoritative answer:
Name: host10601.intranet.mydomain.com
Address: 10.Y.Y.Y



 Comments   
Comment by Spencer Jackson [ 15/Oct/15 ]

I closed this ticket with the following commit:

Author:
{u'username': u'spencerjackson', u'name': u'Spencer Jackson', u'email': u'spencer.jackson@mongodb.com'}
 
Message: SERVER-2421 SERVER-17739 Add FQDN canonicalization for serverStatus and SPNs
Branch: master
https://github.com/mongodb/mongo/commit/e7189d7af091983e9eedc1ca30bc7f1d8e136951

The wrong ticket number was included in the commit name.

Comment by Spencer Jackson [ 14/Oct/15 ]

This has added a new command to Windows copies of the shell. It should probably have a note for those who need to do this.

Comment by Eric Milkie [ 09/May/14 ]

In the client, we could look up the name before calling InitializeSecurityContext, but I'm not sure what the security implications of doing that are.
We should check what the other drivers do. If it works for the C# driver, we should make it work for the C++ driver in kind.

Comment by David McLennan [ 08/May/14 ]

Additional SPN data;

C:\Apps\MongoDB\2.6.1\bin>setspn -l cn
Registered ServicePrincipalNames for CN=cn,OU=ou1,OU=ou2,DC=INTRANET,DC=dc,DC=com:
mongodb/host10602.mydomain.com
mongodb/host10601.mydomain.com

(sysmngdwps is the operating system account the MongoDB instance is running under).

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