On this page
New in version 2.4.
MongoDB Enterprise provides support for Kerberos authentication of
MongoDB clients to
mongos. Kerberos is
an industry standard authentication protocol for large client/server
systems. Kerberos allows MongoDB and applications to take advantage of
existing authentication infrastructure and processes.
Kerberos Components and MongoDB¶
In a Kerberos-based system, every participant in the authenticated communication is known as a “principal”, and every principal must have a unique name.
Principals belong to administrative units called realms. For each realm, the Kerberos Key Distribution Center (KDC) maintains a database of the realm’s principal and the principals’ associated “secret keys”.
For a client-server authentication, the client requests from the KDC a “ticket” for access to a specific asset. KDC uses the client’s secret and the server’s secret to construct the ticket which allows the client and server to mutually authenticate each other, while keeping the secrets hidden.
To authenticate using Kerberos, you must add the Kerberos user
principals to MongoDB to the
$external database. User principal
names have the form:
For every user you want to authenticate using Kerberos, you must create
a corresponding user in MongoDB in the
For examples of adding a user to MongoDB as well as authenticating as that user, see Configure MongoDB with Kerberos Authentication on Linux and Configure MongoDB with Kerberos Authentication on Windows.
Manage Users and Roles for general information regarding creating and managing users in MongoDB.
<service>/<fully qualified domain name>@<KERBEROS REALM>
For MongoDB, the
<service> defaults to
mongodb. For example, if
m1.example.com is a MongoDB server, and
EXAMPLE.COM Kerberos realm, then
m1 should have the service
To specify a different value for
serviceName during the start up of
mongo shell or other clients may also specify a different
service principal name using
Service principal names must be reachable over the network using the fully qualified domain name (FQDN) part of its service principal name.
By default, Kerberos attempts to identify hosts using the
/etc/krb5.conf file before using DNS to resolve hosts.
On Windows, if running MongoDB as a service, see Assign Service Principal Name to MongoDB Windows Service.
Linux Keytab Files¶
Linux systems can store Kerberos authentication keys for a
service principal in keytab
files. Each Kerberized
running on Linux must have access to a keytab file containing keys for
its service principal.
On Linux, MongoDB clients can use Kerberos’s
kinit program to
initialize a credential cache for authenticating the user principal to
Windows Active Directory¶
Unlike on Linux systems,
instances running on Windows do not require access to keytab files.
mongos instances read
their server credentials from a credential store specific to the
However, from the Windows Active Directory, you can export a keytab file for use on Linux systems. See Ktpass for more information.
Authenticate With Kerberos¶
To configure MongoDB for Kerberos support and authenticate, see Configure MongoDB with Kerberos Authentication on Linux and Configure MongoDB with Kerberos Authentication on Windows.
The HTTP Console¶
The MongoDB HTTP Console interface does not support Kerberos authentication.
Deprecated since version 3.2: HTTP interface for MongoDB
PTR DNS records, the host cannot resolve the
components of the Kerberos domain or the Key Distribution Center (KDC).
Kerberized MongoDB Environments¶
The following MongoDB drivers support Kerberos authentication:
Use with Additional MongoDB Authentication Mechanism¶
Although MongoDB supports the use of Kerberos authentication with other
authentication mechanisms, only add the other mechanisms as necessary.
Incorporate Additional Authentication Mechanisms section in
Configure MongoDB with Kerberos Authentication on Linux
Configure MongoDB with Kerberos Authentication on Windows