For this tutorial, each member of the sharded cluster must use the same
internal authentication mechanism and settings. This means enforcing internal
authentication on each mongos and mongod in the cluster.

The following tutorial uses a keyfile to
enable internal authentication.

Enforcing internal authentication also enforces user access control. To
connect to the replica set, clients like the mongo shell need to
use a user account. See
Access Control.

This tutorial covers creating the minimum number of administrative
users on the admin database only. For the user authentication,
the tutorial uses the default SCRAM
authentication mechanism. Challenge-response security mechanisms are
are best suited for testing or development environments. For production
environments, we recommend using x.509
certificates or LDAP Proxy Authority Authentication
(available for MongoDB Enterprise only) or Kerberos Authentication
(available for MongoDB Enterprise only).

For details on creating users for specific authentication mechanism,
refer to the specific authentication mechanism pages.

In general, to create users for a sharded clusters, connect to the
mongos and add the sharded cluster users.

However, some maintenance operations require direct connections to
specific shards in a sharded cluster. To perform these operations, you
must connect directly to the shard and authenticate as a shard-local
administrative user.

Shard-local users exist only in the specific shard and should only be
used for shard-specific maintenance and configuration. You cannot
connect to the mongos with shard-local users.

The contents of the keyfile serves as
the shared password for the members of the sharded cluster. The
content of the keyfile must be the same for all members of the
sharded cluster.

You can generate a keyfile using any method you choose. The contents
of the keyfile must be between 6 and 1024 characters long.

Note

On UNIX systems, the keyfile must not have group or world
permissions. On Windows systems, keyfile permissions are not checked.

The following operation uses openssl to generate a complex
pseudo-random 1024 character string to use for a keyfile. It then
uses chmod to change file permissions to provide read permissions
for the file owner only:

You can specify the mongod settings either via a
configuration file or the command line.

Note

MongoDB 3.2 deprecates mirrored config servers. The downtime may
be an ideal time to upgrade mirrored config servers to a replica
set deployment. See the
Upgrade Config Servers to Replica Set tutorial
for instructions on converting a mirrored config server
deployment to a replica set deployment.

If at least one user does not have privileges to create users,
once the localhost exception closes you may be unable to create
or modify users with new privileges, and therefore unable to
access certain functions or operations.

For each shard replica set in the cluster, connect a mongo
shell to the primary member over the localhost
interface. You must run the mongo on
the same machine as the target mongod to use the localhost
interface.

Create a user with the userAdminAnyDatabase
role on the admin database. This user can create
additional users for the shard replica set as necessary.
Creating this user also closes the Localhost Exception.

The following example creates the shard-local user fred on the
admin database.

Important

Passwords should be random, long, and complex to ensure system security
and to prevent or delay malicious access.

Start eachmongos in the replica set using either
a configuration file or the command line.

Configuration File

If using a configuration file, set the security.keyFile
to the keyfile`s path and the sharding.configDB to
the replica set name and at least one member of the replica
set in <replSetName>/<host:port> format.

At this point, the entire sharded cluster is back online and can
communicate internally using the keyfile specified. However, external
programs like the mongo shell need to use a correctly
provisioned user in order to read or write to the cluster.

Alternatively, connect a new mongo shell to the target
replica set member using the -u<username>, -p<password>, and
the --authenticationDatabaseadmin parameters. You must use
the Localhost Exception to connect to the mongos.

Create users to allow clients to connect and access the
sharded cluster. See Database User Roles for available built-in
roles, such as read and readWrite.
You may also want additional administrative users.
For more information on users, see Users.