MongoDB Documentation, Release 3.0.4 In sharded clusters, applications authenticate to directly to mongos instances, using credentials stored in the admin database of the config servers . The shards in the sharded cluster also have credentials, and clients can authenticate directly to the shards to perform maintenance directly on the shards. In general, applications and clients should connect to the sharded cluster through the mongos . Changed in version 2.6: Previously, the credentials for authenticating to a database on a cluster resided on the primary shard (page 669) for that database. Some maintenance operations, such as cleanupOrphaned , compact , rs.reconfig() , require direct connec- tions to specific shards in a sharded cluster. To perform these operations with authentication enabled, you must connect directly to the shard and authenticate as a shard local administrative user. To create a shard local administrative user, connect directly to the shard and create the user. MongoDB stores shard local users in the admin database of the shard itself. These shard local users are completely independent from the users added to the sharded cluster via mongos . Shard local users are local to the shard and are inaccessible by mongos . Direct connections to a shard should only be for shard-specific maintenance and configuration. Authentication on Sharded Clusters Localhost Exception The localhost exception allows you to enable authorization before creating the first user in the system. When active, the localhost exception allows connections from the localhost interface to create the first user on the admin database. The exception applies only when there are no users created in the MongoDB instance. Changed in version 3.0: The localhost exception changed so that these connections only have access to create the first user on the admin database. In previous versions, connections that gained access using the localhost exception had unrestricted access to the MongoDB instance. If you use the localhost exception when deploying a new MongoDB system, the first user you create must be in the admin database with privileges to create other users, such as a user with the userAdmin (page 407) or userAdminAnyDatabase (page 412) role. See Enable Client Access Control (page 357) and Create a User Ad- ministrator (page 384) for more information. In the case of a sharded cluster, the localhost exception applies to each shard individually as well as to the cluster as a whole. Once you create a sharded cluster and add an administrator to the mongos instance, you must still prevent unauthorized access to the individual shards. Follow one of the following steps for each shard in your cluster: MongoDB employs Role-Based Access Control (RBAC) to govern access to a MongoDB system. A user is granted one or more roles (page 325) that determine the user’s access to database resources and operations. Outside of role assignments, the user has no access to the system. MongoDB does not enable authorization by default. You can enable authorization using the --auth or the --keyFile options, or if using a configuration file, with the security.authorization or the security.keyFile settings. MongoDB provides built-in roles (page 405), each with a dedicated purpose for a common use case. Examples include the read (page 405), readWrite (page 406), dbAdmin (page 406), and root (page 413) roles. Chapter 6. Security 324 6.2.2 Authorization • Create an administrative user, or • Disable the localhost exception at startup. To disable the localhost exception, use setParameter in your configuration file , or --setParameter on the command line to set the enableLocalhostAuthBypass parameter to 0 .