createUser
On this page
Definition
createUser
Creates a new user on the database where you run the command. The
createUser
command returns a duplicate user error if the user exists. ThecreateUser
command uses the following syntax:Tip
Starting in version 4.2 of the
mongo
shell, you can use thepasswordPrompt()
method in conjunction with various user authentication/management methods/commands to prompt for the password instead of specifying the password directly in the method/command call. However, you can still specify the password directly as you would with earlier versions of themongo
shell.{ createUser: "<name>", pwd: passwordPrompt(), // Or "<cleartext password>" customData: { <any information> }, roles: [ { role: "<role>", db: "<database>" } | "<role>", ... ], writeConcern: { <write concern> }, authenticationRestrictions: [ { clientSource: [ "<IP|CIDR range>", ... ], serverAddress: [ "<IP|CIDR range>", ... ] }, ... ], mechanisms: [ "<scram-mechanism>", ... ], //Available starting in MongoDB 4.0 digestPassword: <boolean>, comment: <any> } createUser
has the following fields:FieldTypeDescriptioncreateUser
stringThe name of the new user.pwd
stringThe user's password. The
pwd
field is not required if you runcreateUser
on the$external
database to create users who have credentials stored externally to MongoDB.The value can be either:
the user's password in cleartext string, or
passwordPrompt()
to prompt for the user's password.
Tip
Starting in version 4.2 of the
mongo
shell, you can use thepasswordPrompt()
method in conjunction with various user authentication/management methods/commands to prompt for the password instead of specifying the password directly in the method/command call. However, you can still specify the password directly as you would with earlier versions of themongo
shell.customData
documentOptional. Any arbitrary information. This field can be used to store any data an admin wishes to associate with this particular user. For example, this could be the user's full name or employee id.roles
arrayThe roles granted to the user. Can specify an empty array[]
to create users without roles.digestPassword
booleanOptional. Indicates whether the server or the client digests the password.
If true, the server receives undigested password from the client and digests the password.
If false, the client digests the password and passes the digested password to the server. Not compatible with
SCRAM-SHA-256
Changed in version 4.0: The default value is
true
. In earlier versions, the default value isfalse
.writeConcern
documentOptional. The level of write concern for the creation operation. ThewriteConcern
document takes the same fields as thegetLastError
command.authenticationRestrictions
arrayOptional. The authentication restrictions the server enforces on the created user. Specifies a list of IP addresses and CIDR ranges from which the user is allowed to connect to the server or from which the server can accept users.
New in version 3.6.
mechanisms
arrayOptional. Specify the specific SCRAM mechanism or mechanisms for creating SCRAM user credentials. If
authenticationMechanisms
is specified, you can only specify a subset of theauthenticationMechanisms
.Valid values are:
"SCRAM-SHA-1"
Uses the
SHA-1
hashing function.
"SCRAM-SHA-256"
Uses the
SHA-256
hashing function.Requires featureCompatibilityVersion set to
4.0
.Requires digestPassword to be
true
.
The default for featureCompatibilityVersion is
4.0
is bothSCRAM-SHA-1
andSCRAM-SHA-256
.The default for featureCompatibilityVersion is
3.6
isSCRAM-SHA-1
.New in version 4.0.
digestPassword
booleanOptional. Indicates whether the server or the client digests the password.
If true, the server receives undigested password from the client and digests the password.
If false, the client digests the password and passes the digested password to the server. Not compatible with
SCRAM-SHA-256
Changed in version 4.0: The default value is
true
. In earlier versions, the default value isfalse
.comment
anyOptional. A user-provided comment to attach to this command. Once set, this comment appears alongside records of this command in the following locations:
mongod log messages, in the
attr.command.cursor.comment
field.Database profiler output, in the
command.comment
field.currentOp
output, in thecommand.comment
field.
A comment can be any valid BSON type (string, integer, object, array, etc).
New in version 4.4.
Roles
In the roles
field, you can specify both
built-in roles and user-defined
roles.
To specify a role that exists in the same database where
createUser
runs, you can either specify the role with the name of
the role:
"readWrite"
Or you can specify the role with a document, as in:
{ role: "<role>", db: "<database>" }
To specify a role that exists in a different database, specify the role with a document.
Authentication Restrictions
New in version 3.6.
The authenticationRestrictions
document can contain only the
following fields. The server throws an error if the
authenticationRestrictions
document contains an unrecognized field:
Field Name | Value | Description |
---|---|---|
clientSource | Array of IP addresses and/or
CIDR ranges | If present, when authenticating a user, the server verifies
that the client's IP address is either in the given list or
belongs to a CIDR range in the list. If the client's IP address
is not present, the server does not authenticate the user. |
serverAddress | Array of IP addresses and/or
CIDR ranges | A list of IP addresses or CIDR ranges to which the client can
connect. If present, the server will verify that the client's
connection was accepted via an IP address in the given list. If
the connection was accepted via an unrecognized IP address, the
server does not authenticate the user. |
Important
If a user inherits multiple roles with incompatible authentication restrictions, that user becomes unusable.
For example, if a user inherits one role in which the
clientSource
field is ["198.51.100.0"]
and another role in
which the clientSource
field is ["203.0.113.0"]
the server is
unable to authenticate the user.
For more information on authentication in MongoDB, see Authentication.
Behavior
User ID
Starting in version 4.0.9, MongoDB automatically assigns a unique
userId
to the user upon creation.
Encryption
Warning
By default, createUser
sends all specified data to the MongoDB
instance in cleartext, even if using passwordPrompt()
. Use
TLS transport encryption to protect communications between clients
and the server, including the password sent by createUser
. For
instructions on enabling TLS transport encryption, see
Configure mongod
and mongos
for TLS/SSL.
MongoDB does not store the password in cleartext. The password is only vulnerable in transit between the client and the server, and only if TLS transport encryption is not enabled.
External Credentials
Users created on the $external
database should have credentials
stored externally to MongoDB, as, for example, with MongoDB
Enterprise installations that use Kerberos.
Changed in version 3.6.3: To use sessions with $external
authentication users (i.e.
Kerberos, LDAP, x.509 users), the usernames cannot be greater
than 10k bytes.
local
Database
You cannot create users on the local database.
Username Limits
Usernames must consist of at least one character and cannot be larger than 7MB.
Required Access
To create a new user in a database, you must have the
createUser
action on that database resource.To grant roles to a user, you must have the
grantRole
action on the role's database.
The userAdmin
and
userAdminAnyDatabase
built-in roles
provide createUser
and
grantRole
actions on their respective resources.
Example
The following createUser
command creates a user accountAdmin01
on the
products
database. The command gives accountAdmin01
the
clusterAdmin
and readAnyDatabase
roles on the admin
database
and the readWrite
role on the products
database:
Tip
Starting in version 4.2 of the mongo
shell, you can
use the passwordPrompt()
method in conjunction with
various user authentication/management methods/commands to prompt
for the password instead of specifying the password directly in the
method/command call. However, you can still specify the password
directly as you would with earlier versions of the
mongo
shell.
db.getSiblingDB("products").runCommand( { createUser: "accountAdmin01", pwd: passwordPrompt(), customData: { employeeId: 12345 }, roles: [ { role: "clusterAdmin", db: "admin" }, { role: "readAnyDatabase", db: "admin" }, "readWrite" ], writeConcern: { w: "majority" , wtimeout: 5000 } } )