Posts tagged:


Setting up Java Applications to Communicate with MongoDB, Kerberos and SSL

Aug 19 • Posted 15 hours ago

By Alex Komyagin, Technical Services Engineer at MongoDB

Setting up Kerberos authentication and SSL encryption in a MongoDB Java application is not as simple as other languages. In this post, I’m going to show you how to create a Kerberos and SSL enabled Java application that communicates with MongoDB.

My original setup consists of the following:

1) KDC server:

kerberos config file (/etc/krb5.conf):

KDC has the following principals:

  • gssapitest@MONGOTEST.COM - user principle (for java app)
  • mongodb/ - service principle (for mongodb server)

2) MongoDB server:

MongoDB version: 2.6.0

MongoDB config file:

This server also has the global environment variable $KRB5_KTNAME set to the keytab file exported from KDC.

Application user is configured in the admin database like this:

3) Application server: has stock OS with krb5 installed

All servers are running with RHEL6.4 onboard.

Now let’s talk about how to create a Java application with Kerberos and SSL enabled, and that will run on the application server. Here is the sample code that we will use (

Download the java driver:

Install java and jdk:

sudo yum install java-1.7.0 sudo yum install java-1.7.0-devel

Create a certificate store for Java and store the server certificate there, so that Java knows who it should trust:

(mongodb.crt is just a public certificate part of mongodb.pem)

Copy kerberos config file to the application server: /etc/krb5.conf or ““C:\WINDOWS\krb5.ini“` (otherwise you’ll have to specify kdc and realm as Java runtime options)

Use kinit to store the principal password on the application server:

kinit gssapitest@MONGOTEST.COM

As an alternative to kinit, you can use JAAS to cache kerberos credentials.

Compile and run the Java program

It is important to specify useSubjectCredsOnly=false, otherwise you’ll get the “No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)” exception from Java. As we discovered, this is not strictly necessary in all cases, but it is if you are relying on kinit to get the service ticket.

The Java driver needs to construct MongoDB service principal name in order to request the Kerberos ticket. The service principal is constructed based on the server name you provide (unless you explicitly asked to canonicalize server name). For example, if I change to the host IP address in the connection URI, I would be getting Kerberos exceptions No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - UNKNOWN_SERVER)]. So be sure you specify the same server host name as you used in the Kerberos principal (). Adding to Java runtime options helps a lot in debugging kerberos auth issues.

These steps should help simplify the process of connecting Java applications with SSL. Before deploying any application with MongoDB, be sure to read through our 12 tips for going into production and the Security Checklist which outlines recommended security measures to protect your MongoDB installation. More information on configuring MongoDB Security can be found in the MongoDB Manual.

For further questions, feel free to reach out to the MongoDB team through google-groups.

MongoDB Security Part II: 10 mistakes that can compromise your database

Jun 3 • Posted 2 months ago

This is the second in our 3-part series on MongoDB Security by Andreas Nilsson, Lead Security Engineer at MongoDB

This post outlines 10 things to avoid when configuring security for MongoDB. These types of mistakes can lead to the loss of sensitive data, disrupted operations and have the potential to put entire companies out of business. These recommendations are based on my experience working with MongoDB users, and building security systems for databases and financial services organizations. Items are ordered by a combination of severity and frequency.

Mistake #1: Directly exposing a MongoDB server to the Internet

It is surprisingly common to deploy MongoDB database servers directly online or in a DMZ. The MongoDB server network interface is designed to be stable under rogue conditions but exposing the database to the Internet is an unnecessary risk. This holds true for any backend system and is not specific for MongoDB.

If public network exposure is combined with lack of access control, the entire content of the database is up for grabs for anyone who cares to look. In addition, an attacker could intentionally or accidentally change the database configuration, modify the application behavior or perform a Denial of Service (DoS) attack.


Design web applications with a multi-tier architecture in mind, use firewalls to segment the network layers appropriately, and place your database server at the inner data storage layer.

Mistake #2: No access control

Access control is not enabled by default when installing MongoDB. If access control is not enabled, anyone with network access to the server can perform any operation. This includes extracting all data and configuration, running arbitrary Javascript using the eval command, modifying any data in the database, creating and removing shards, etc.


Always enable access control, unless it is guaranteed that no untrusted entities will gain access to the server, see the section on Role-Based Access Control in the MongoDB security manual.

Mistake #3 - Not enabling SSL

It is fairly straightforward to protect the network communication using SSL, and enabling SSL in MongoDB does not impact the database performance. SSL also protects against man-in-the-middle attacks, where an attacker would intercept and modify communication between two parties.


Enable SSL to protect network communication against eavesdropping between the clients and the servers and within MongoDB clusters and replica sets.

Mistake #4 - Unnecessary exposure of interfaces

MongoDB ships with an HTTP server and REST interface. By default this interface is turned off in MongoDB 2.6. Do not enable the HTTP server interface unless it is used for backwards compatibility. Instead use the wire API for communication with the server.

We also recommend only binding to necessary network interfaces and turn off server side Javacript execution if not needed.


Run MongoDB with secure configuration options as described in the documentation.

Mistake #5 - Poor user account configuration

There are a few ways to configure user accounts incorrectly, for MongoDB as well as for other systems. These include but are not limited to:

  • Use of a single high-privilege admin account for all purposes.
  • Granting high privileges and roles to users who do not need them.
  • Use of weak passwords or the same password for multiple accounts.
  • Orphaned user accounts belonging to decommissioned users or applications.


Use the principle of least privilege when configuring user accounts and utilize the flexibility available in the MongoDB access control system. Use unique, complex passwords and be mindful to decommission deprecated user accounts.

Mistake #6 - Insecure OS privileges

Running the mongod or mongos processes using a non-dedicated, high-privilege account like root puts your Operating System at unnecessary risk. Instead use a dedicated, special purpose account.

Avoid lax, insecure OS file permissions on * Data files * Keyfile * SSL private key files * Log files


Database data files, the keyfile and SSL private key files should only be readable by the mongod/mongos user. Log files should only be writable by the mongod/mongos user and readable only by root.

Mistake #7 - Insecure replica set keyfile configuration

The content of the keyfile used for authentication in sharded clusters and replicasets is in essence a password and should as such be long and of high entropy. Avoid:

  • Short or low-entropy password in the keyfile
  • Inadequate protection of the keyfile


Use a long, complex password if using a keyfile and protect it using adequate file permissions.

Mistake #8 - Poor SSL configuration

SSL is a complex protocol that needs to be configured properly to avoid leaving unexpected security holes.


Always provide MongoDB servers or the mongo shell with one or several CA certificates to establish a basis of trust.

Do not use self-signed certificates unless you are only looking for the encryption parts of SSL. Using a self-signed certificate invalidates substantial parts of SSL. Use certificates issued by a commercial or internal Certificate Authority.

Avoid using the same certificate across servers or clients. This exposes the private key in multiple places and unless a wildcard (*) certificate is used no hostname validation can be performed.

Mistake #9 - Unprotected backups

Care should be taken to adequately protect backup files generated by copying the data files or using the mongodump tool. If the content of the database is sensitive, the content of the backup is equally sensitive and should be treated as such.


Treat database backup files with the same level of care as the original database storage files.

Mistake #10 - Conscious or unconscious ignorance

A guaranteed way to create an insecure system is to ignore the topic altogether, or hope someone else thinks about it.


Before deploying a MongoDB instance with sensitive data, please consult the MongoDB Security Manual and the MongoDB Security Architecture Whitepaper and stay conscious about potential threats to your application.

MongoDB subscriptions provide access to additional enterprise grade capabilities. The subscription includes all the ease-of-use, broad driver support and scalability features of MongoDB, while addressing the more demanding security and certification requirements of corporate and government information security environments. To see more, download the development version of the MongoDB Enterprise edition here

blog comments powered by Disqus