Configure MongoDB with Kerberos Authentication

The MongoDB database administrators in a large enterprise may need to configure MongoDB to support Kerberos Authentication. The configuration of MongoDB with Kerberos authentication is very simple, provided you have some Kerberos knowledge. The MongoDB documentation article, Configure MongoDB with Kerberos Authentication on Linux, is pretty extensive on this topic. However, the article states — “Setting up and configuring a Kerberos deployment is beyond the scope of this document”, resulting in some of the starters/enthusiasts with limited knowledge in Kerberos not proceed any further. This article is geared more towards bridging that gap and to help you understand

• How Kerberos Works
• How to set up Kerberos and MongoDB in your lab
• Finally, How to integrate MongoDB with Kerberos authentication

This is one of the many articles in multi-part series, Mastering MongoDB — One tip a day, solely created for you to master MongoDB by learning ‘one tip a day’. In a few series of articles, I would like to give various tips to tighten the security on MongoDB. In this article, I would discuss “How to Integrate MongoDB with Kerberos Authentication”.

Mastering — MongoDB with Kerberos Authentication

What is a Kerberos

Kerberos is a computer network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. It works on the basis of tickets to allow nodes communicating over a non-secure network, to prove their identity to one another in a secure manner. The Kerberos protocol messages are protected against eavesdropping and replay attacks. The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades.

How does Kerberos work

Instead of asking the client to enter username/password credentials for every service they access, the Kerberos allows single sign-on by using the tickets. These proof of identity tickets are issued by a trusted 3rd party (Key Distribution Center) and are typically encrypted with a secret/symmetric key. This section discusses how various resources within the Kerberos Realm interacts with each other during the authentication process.

Key Distribution Center

In order to administer the access to a resource via Kerberos, all of the components, services, and users must be in the Kerberos Realm. The Kerberos Distribution Center (KDC) is at the core of the Kerberos Realm and has following key server components

• Database Server — Stores secret keys of registered users and Services
• Authentication Server — Provides a ticket to access Ticket-Granting Server
• Ticket-Granting Server — Provides a ticket to access the service of interest

The KDC’s database stores all of the secret keys for user machines and services. The secret keys are in-turn a hash value of the password plus a salt. The database itself is further encrypted with a master key to prevent anyone stealing keys from the database’s file system.

The flow of events during the authentication process

Let’s say you want to access the MongoDB Service using Kerberos authentication. During the authentication process, the following resources process/exchange information with a defined objective

• Client. Objective: Login using kinit
• Client and Authentication Service. Objective: Get Ticket-Granting-Ticket
• Client and Ticket-Granting Service. Objective: Get Service Ticket
• Client and MongoDB Service. Objective: Get access to MongoDB Service

The above diagram shows various resources/components involved in the Kerberos authentication process and illustrates how they interact with each other. Let’s try to understand the internal details of each step.

Please pay special attention to the color of the lock icon, an encrypted message. It can only be decrypted by the resource having the same colored secret key.

Login using kinit

The User (AKA Client/Principal) must introduce themselves to the Authentication Server by logging into the computer, or by running the command kinit <username>

Communication between the User and the Authentication Server

Every User must have a Ticket-Granting Ticket (TGT) issued by Authentication Server before accessing any Service. The TGT is a ticket that allows the user to get Tickets for accessing services of their interest.

The User’s objective is to get a Ticket-Granting Ticket by sending a request to Authentication Server. The request message contains

• 
  

  
  

  
  

  
  

  Username: Username / Client IDService Requested: Ticket-Granting ServiceNetwork Address: Client’s IP AddressExpiration: Lifetime of TGTTimestamp: When the request message was created

The Authentication Server processes the request and checks if Timestamp in the message is within 5 min, checks if the User and requested Service are in KDC. It finally issues a Ticket-Granting Ticket, generates and shares Ticket-Granting Session Key with the User.

The Authentication Server responds to the User’s request with two messages. The Response #1 is encrypted with Client Secret Key (Cyan color key) and the message has below contents —

• 
  

  
  

  Service: Ticket-Granting Service Timestamp: When it was createdValidity: Lifetime of TGTTGS Session Key (Magenta color key )

The Response #2 is Ticket Granting Ticket, TGT, which is encrypted with TGS Secret Key (Yellow color key). It can only be decrypted by KDC. The message has below contents —

• 
  

  
  

  
  

  
  

  Username: Your Name / IDService: Ticket-Granting Service Timestamp: When it was createdNetwork Address: IP AddressValidity: Lifetime of TGTTGS Session Key

The Client processes Authentication Service response and decrypts Response #1 using the User's Secret Key (Cyan color key). Upon successful decryption, both the User and the KDC has TGS Session Key (Magenta color key ). The TGS Session Key is used for encrypting the communication between the Client and the Ticket Granting Server. The Client cannot decrypt the Response #2, TGT, as it does not have TGS Secret Key but it would be stored within client’s credential cache.

Communication between the User and the Ticket-Granting Server

With the Ticket-Granting Ticket in hand, the client can request Ticket-Granting Server for a ticket to access the MongoDB Service. Upon validating the TGT, the Ticket Granting Server will issue a Service Ticket, STKT, to request access for MongoDB Server.

The User’s objective is to get a Service Ticket by sending a request to Ticket Granting Server. The Request #1 message has below contents —

• 
  

  Validity: Lifetime of TGTService Requested: MongoDB Service Ticket-Granting Ticket (only KDC can decrypt)

The Request #2 is encrypted with TGS Secret Key (Magenta color key) and the message has below contents —

• 
  

  Username: Your Name / IDTimestamp: When it was created

The Ticket-Granting Server processes the request, checks if Timestamp in the message is within 5 min, checks if the service MongoDB Service is registered with KDC. It finally issues a Service Ticket, generates and shares MongoDB Service Session Key (Royal Blue color key) with the User.

The Ticket Granting Server responds to the User’s request with two messages. The Response #1 is encrypted with TGS Session Key (Magenta color key) and the message has below contents —

• 
  

  
  

  
  

  Service Requested: MongoDB ServiceTimestamp: When it was createdValidity: Lifetime of TGTService Session Key (Royal Blue key )

The Response #2 is encrypted with MongoDB Secret Key (Green color key) and can be decrypted only by MongoDB Server. The message has below message contents —

• 
  

  
  

  
  

  
  

  
  

  Username: Your Name / IDService: MongoDB ServiceTimestamp: When it was createdNetwork Address: IP AddressValidity: Lifetime of STKTMongoDB Service Session Key

The MongoDB Service Session Key is used for encrypting the communication between the User and the MongoDB server. The Client cannot decrypt the Response #2, STKT, as it does not have MongoDB Secret Key but it would be stored within the client’s credential cache.

Communication between the User and the MongoDB Service

With the Service Ticket in hand, the client can send a login request to MongoDB Server. The MongoDB Server will validate the Service Ticket and sets the authorized roles and privileges for the User's login session.

The User’s objective is to get access to MongoDB Service by sending a login request to MongoDB Server. The Request #1 is encrypted with MongoDB Session Key (Royal Blue color key) and the message has below contents —

• 
  

  Username: Your Name / IDTimestamp: When it was created

The Request #2 is the Service Ticket itself which can be decrypted only by MongoDB Server using it’s Secret Key (Green color key). The message has below contents —

• 
  

  
  

  
  

  
  

  
  

  Username: Your Name / IDService: MongoDB ServiceTimestamp: When it was createdNetwork Address: IP AddressValidity: Lifetime of STKTMongoDB Service Session Key

The MongoDB Server processes the request, checks if Timestamp in the message is within 5 min, checks if the User is registered with the database. It finally sets the roles and privileges for the User.

The MongoDB Server responds to the User’s request with a message. The Response #1 is encrypted with MongoDB Session Key (Royal Blue color key) and the message has below contents —

• 
  

  Username: Your Name / IDService: MongoDB Service

The Client processes MongoDB Service response and decrypts Response #1 using the MongoDB Session Key (Royal Blue color key). Upon successful decryption, and validation, the Client would communicate directly with the MongoDB Server for further database requests.

I know it’s a lot of information to digest especially if you have no knowledge of Kerberos. For further reading on Kerberos, I strongly recommend you to read Lynn Root’s article Explain like I’m 5: Kerberos and/or watch the YouTube video Kerberos — CompTIA Security by Professor Messer.

Hands-On lab exercises

Now that you understood the theory and information flow during Kerberos authentication, let's work on setting up a lab environment. This lab exercise helps you understand how to set up Kerberos, MongoDB and configure a client to use them on a CentOS 7.5.

Setup environment

First, you would need an environment to play around. In this example, I have created 3 AWS EC2 instances, one for each server — KDC, MongoDB Server and User machine. If you are short on resources, you could potentially install them all on the same lab server.

Please make sure to configure your firewall/security groups to allow incoming traffic on ports 88, 749, 27017 for respective services.

A bash script to install ntpd service on all three servers (KDC, MongoDB Server and User machine)

Installing & Configuring KDC Server

Login to the KDC server to install/configure the Kerberos Server.

A bash script to install Kerberos server on KDC server and configure the files with MDBKRB5.NET realm

For your convenience, I am illustrating how the file contents would look like after running the above commands.

The file contents of Kerberos configuration files

Next, you need to create a Kerberos database for the Realm and create the Principal entries for the Users, Services etc

A bash script to create a Kerberos database for the Realm and create the Principal entries for the Users, Services etc

Setup the MongoDB Server

Login to the MongoDB server to install/configure the MongoDB Server, mdb01.mdbkrb5.net

A bash script to install the Kerberos client and display the Kerberos configuration file

Next, you would need to install the MongoDB Enterprise server, create the MongoDB keyfile, configure the /etc/mongod.conf file, etc

A bash script to install the MongoDB and set the MongoDB configuration files

Create a keytab file to store Kerberos service principals and encrypted keys

A bash script to help you create the Kerberos keytab file

Set the folders permissions to only allow the user mongod to read them.

A bash script to configure environment variables and set permissions for the folders

Finally, let’s create the following in MongoDB server

• superuser with root privileges
• alex Principal with root role on admin database
• bob Principal with readWrite role on social database

A bash script using mongo client to create replica set and user privileges on $external database

Install MongoDB client on the client01.mdbkrb5.net

Login to the MongoDB client server to install the Kerberos and MongoDB clients.

A bash script to install the Kerberos client and display the Kerberos configuration file on the User machine

First, install the MongoDB shell and Enterprise dependencies using Yum.

A bash script to install the MongoDB shell and the MongoDB Enterprise dependencies

Login to the Kerberos as bob and then log in to the MongoDB Server to test the readWrite permissions on the social database.

A bash script illustrating authentication to MongoDB via Kerberos SSO and authorization on MongoDB

If you run the same tests for the user, alex, then you would be able to query both social and admin databases because of his root role.

Summary

As stated at the beginning of the article — “Configuring MongoDB with Kerberos Authentication is very simple!”. However, without proper Kerberos knowledge, your hands are pretty much tied-down to do a simple POC.

Hopefully, this article has simplified the understanding of Kerberos events, and shed some light on “How to integrate MongoDB with Kerberos Authentication”.

The MongoDB Enterprise provides integration with Kerberos as well as LDAP authentication mechanisms. Although the MongoDB is using Kerberos Authentication, the user management still requires the User privileges to be created in the MongoDB. If your organization has 100s of users requiring access to MongoDB then you may to explore the use of LDAP for both authentication and authorization. But that’s a topic for another day. Hopefully, you learned something new today as you scale the path to “Mastering MongoDB — One tip a day”.

Previously published articles

• 
  

  Tip # 005: Getting started with MongoDB Enterprise OperatorNow you could deploy MongoDB in Kubernetes under a minute

• 
  

  Tip # 004: Faster electionsMeasures to reduce the election time during the rolling maintenance

• 
  

  Tip # 003: TransactionsA long awaited and most requested feature for many, has finally arrived

• 
  

  Tip # 002: createRoleAhhh …! Someone just dropped a collection

• 
  

  Tip # 001: currentOpKnow the operations currently executing on MongoDB server inside out