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
- depends on
-
CXX-228 Optional Canonicalization of SSPI hostnames
-
- Closed
-
- is documented by
-
DOCS-9000 Kerberos Authentication on Windows from mongo client only works with FQDN
-
- Closed
-
- is duplicated by
-
SERVER-19469 Create a flag to require hosts to be canonicalised based on DNS records
-
- Closed
-