@@ -10,100 +10,100 @@ Users
10
10
.. contents:: On this page
11
11
:local:
12
12
:backlinks: none
13
- :depth: 1
13
+ :depth: 2
14
14
:class: singlecol
15
15
16
- To authenticate a client in MongoDB, you must add a corresponding user to
17
- MongoDB.
16
+ To authenticate a client in MongoDB, you must add a corresponding user
17
+ to MongoDB.
18
18
19
+ User Management
20
+ ---------------
19
21
20
- User Management Interface
21
- -------------------------
22
+ You can add a user with the :method:`db.createUser()` method using
23
+ :binary:`~bin.mongosh`. The first user you create must have privileges
24
+ to create other users. The :authrole:`userAdmin` or
25
+ :authrole:`userAdminAnyDatabase` role both confer the privilege to
26
+ create other users.
22
27
23
- To add a user, MongoDB provides the :method:`db.createUser()` method.
24
- When adding a user, you can assign :doc:`roles </core/authorization>` to
25
- the user in order to grant privileges.
26
-
27
- .. note::
28
+ .. seealso::
28
29
29
- The first user created in the database should be a user administrator
30
- who has the privileges to manage other users. See
31
- :doc:`/tutorial/enable-authentication`.
30
+ :doc:`/tutorial/create-users`
32
31
33
- You can also update existing users, such as to change password and grant
34
- or revoke roles. For a full list of user management methods, see
32
+ You can grant a user privileges by assinging :doc:`roles
33
+ </core/authorization>` to the user when you create the user. You can
34
+ also grant or revoke roles, as well as update passwords, by updating
35
+ existing users. For a full list of user management methods, see
35
36
:ref:`user-management-methods`.
36
37
38
+ .. seealso::
39
+
40
+ :doc:`/tutorial/manage-users-and-roles`
41
+
37
42
A user is uniquely identified by the user's name and associated
38
- authentication database. Starting in MongoDB 4.0.9, a users managed by
39
- MongoDB are assigned a unique ``userId``. [#userid]_
43
+ :ref:`authentication database <authentication-database>`. MongoDB
44
+ associates a user with a unique ``userId`` upon creation in MongoDB.
45
+
46
+ LDAP Managed Users
47
+ ~~~~~~~~~~~~~~~~~~
48
+
49
+ :ref:`LDAP managed users <security-ldap>` created on an LDAP
50
+ server do not have an associated document in the :doc:`system.users
51
+ </reference/system-users-collection>` collection, and therefore don't
52
+ have a :data:`~admin.system.users.userId` field associated with them.
40
53
41
- .. seealso::
42
54
43
- :doc:`/tutorial/create-users`
44
-
45
55
.. _authentication-database:
46
56
.. _user-authentication-database:
47
57
48
58
Authentication Database
49
59
-----------------------
50
60
51
- When adding a user, you create the user in a specific database. This
52
- database is the authentication database for the user.
53
-
54
- A user can have privileges across different databases; that is, a user's
55
- privileges are not limited to their authentication database. By assigning
56
- to the user roles in other databases, a user created in one database can
57
- have permissions to act on other databases. For more information on
58
- roles, see :doc:`/core/authorization`.
59
-
60
- The user's name and authentication database serve as a unique identifier
61
- for that user. [#userid]_ That is, if two users have the same name but are created
62
- in different databases, they are two separate users. If you intend to
63
- have a single user with permissions on multiple databases, create a
64
- single user with roles in the applicable databases instead of creating
65
- the user multiple times in different databases.
61
+ When you add a user, you create the user in a specific database. The
62
+ database you create the user in is the authentication database for the
63
+ user.
66
64
67
- .. [#userid]
65
+ However, a user's privileges are not limited to their authentication
66
+ database. Therefore, a user can have privileges across different
67
+ databases. For more information on roles, see
68
+ :doc:`/core/authorization`.
68
69
69
- Starting in version 4.0.9, MongoDB associates a user with a unique
70
- ``userId`` upon creation in MongoDB.
71
-
72
- :ref:` LDAP managed users <security-ldap>` created on the LDAP server
73
- do not have an associated document in the :doc:`system.users
74
- </reference/ system- users-collection>` collection, and hence, do not
75
- have a :data:`~admin.system.users.userId` field associated with them.
70
+ A user's name and authentication database serve as a unique identifier
71
+ for that user. MongoDB associates a user with a unique ``userId`` upon
72
+ creation in MongoDB. However, :ref:`LDAP managed users <security-ldap>`
73
+ created on an LDAP server do not have an associated document in the
74
+ :doc:`system.users </reference/system-users-collection>` collection, and
75
+ therefore don't have a :data:`~admin. system. users.userId` field
76
+ associated with them.
76
77
77
- .. _authentication-auth-as-user:
78
-
79
- Authenticate a User
80
- -------------------
81
-
82
- .. include:: /includes/fact-authenticate.rst
78
+ If two users have the same name but are created in different databases,
79
+ they are two separate users. If you want to have a single user with
80
+ permissions on multiple databases, create a single user with a role for
81
+ each applicable database.
83
82
84
83
Centralized User Data
85
84
---------------------
86
85
87
86
For users created in MongoDB, MongoDB stores all user information,
88
87
including :data:`name <admin.system.users.user>`, :data:`password
89
- <admin.system.users.credentials>`, and the :data:` user's authentication
88
+ <admin.system.users.credentials>`, and the user's :data:` authentication
90
89
database <admin.system.users.db>`, in the :doc:`system.users
91
90
</reference/system-users-collection>` collection in the ``admin``
92
91
database.
93
92
94
- Do not access this collection directly but instead use the :ref:`user
95
- management commands <user-management-commands>`.
96
-
93
+ Do not modify this collection directly. To manage users, use the
94
+ designated :ref:`user management commands <user-management-commands>`.
97
95
98
96
.. _sharding-localhost:
99
97
.. _sharding-security:
100
98
101
99
Sharded Cluster Users
102
100
---------------------
103
101
104
- To create users for a sharded cluster, connect to the
105
- :binary:`~bin.mongos` instance and add the users. Clients then
106
- authenticate these users through the :binary:`~bin.mongos` instances.
102
+ To create users for a sharded cluster, connect to a
103
+ :binary:`~bin.mongos` instance and add the users. To authenticate as a
104
+ user created on a :binary:`~bin.mongos` instance, you must authenticate
105
+ through a :binary:`~bin.mongos` instance.
106
+
107
107
In sharded clusters, MongoDB stores user configuration data in the
108
108
``admin`` database of the :term:`config servers <config server>`.
109
109
@@ -112,62 +112,33 @@ In sharded clusters, MongoDB stores user configuration data in the
112
112
Shard Local Users
113
113
~~~~~~~~~~~~~~~~~
114
114
115
- However, some maintenance operations, such as :dbcommand:`cleanupOrphaned`,
116
- :dbcommand:`compact`, :method:`rs.reconfig()`, require direct connections to
117
- specific shards in a sharded cluster. To perform these operations, you must
118
- connect directly to the shard and authenticate as a *shard local*
119
- administrative user.
120
-
121
- To create a *shard local* administrative user, connect directly to the shard
122
- and create the user. MongoDB stores *shard local* users in the ``admin``
123
- database of the shard itself.
124
-
125
- These *shard local* users are completely independent from the users added to
126
- the sharded cluster via :binary:`~bin.mongos`. *Shard local* users are local to the
127
- shard and are inaccessible by :binary:`~bin.mongos`.
128
-
129
- Direct connections to a shard should only be for shard-specific maintenance and
130
- configuration. In general, clients should connect to the sharded cluster
131
- through the :binary:`~bin.mongos`.
132
-
133
- .. _localhost-exception:
134
-
135
- Localhost Exception
136
- -------------------
137
-
138
- The localhost exception allows you to enable access control and then
139
- create the first user in the system. With the localhost exception, after
140
- you enable access control, connect to the localhost interface and create
141
- the first user in the ``admin`` database. The first user must have
142
- privileges to create other users, such as a user with the
143
- :authrole:`userAdmin` or :authrole:`userAdminAnyDatabase` role.
144
- Connections using the localhost exception *only* have access to create
145
- the first user on the ``admin`` database.
146
-
147
- .. versionchanged:: 3.4
148
-
149
- MongoDB 3.4 extended the localhost exception to permit execution of the
150
- :method:`db.createRole()` method. This method allows users authorizing via
151
- LDAP to create a role inside of MongoDB that maps to a role defined
152
- in LDAP. See :ref:`LDAP Authorization <security-ldap-external>` for more
153
- information.
115
+ Some maintenance operations, such as :dbcommand:`cleanupOrphaned`,
116
+ :dbcommand:`compact`, or :method:`rs.reconfig()`, require direct
117
+ connections to specific shards in a sharded cluster. To perform these
118
+ operations, you must connect directly to the shard and authenticate as a
119
+ *shard local* administrative user.
154
120
155
- The localhost exception applies only when there are no users created in the
156
- MongoDB instance.
121
+ To create a *shard local* administrative user, connect directly to the
122
+ primary of the shard and create the user. For instructions on how to
123
+ create a shard local user administrator see the
124
+ :doc:`/tutorial/deploy-sharded-cluster-with-keyfile-access-control`
125
+ tutorial.
157
126
158
- In the case of a sharded cluster, the localhost exception applies to each shard
159
- individually as well as to the cluster as a whole. Once you create a sharded
160
- cluster and add a user administrator through the :binary:`~bin.mongos` instance,
161
- you must still prevent unauthorized access to the individual shards. Follow one
162
- of the following steps for each shard in your cluster:
127
+ MongoDB stores *shard local* users in the ``admin`` database of the
128
+ shard itself. These *shard local* users are independent from
129
+ the users added to the sharded cluster through a :binary:`~bin.mongos`.
130
+ *Shard local* users are local to the shard and are inaccessible by
131
+ :binary:`~bin.mongos`.
163
132
164
- - Create an administrative user, or
133
+ Direct connections to a shard should only be used for shard-specific
134
+ maintenance and configuration or for targeted analytics workloads. In
135
+ general, clients should connect to the sharded cluster through the
136
+ :binary:`~bin.mongos`.
165
137
166
- - Disable the localhost exception at startup. To disable the localhost
167
- exception, set the :parameter:`enableLocalhostAuthBypass` parameter to ``0``.
168
138
169
139
.. toctree::
170
140
:titlesonly:
171
141
:hidden:
172
142
173
143
/tutorial/create-users
144
+ /tutorial/authenticate-a-user
0 commit comments