User accounts identify connections to the database. The database and dataset privileges granted or denied to a user account determine what the user can access. User accounts can be grouped together based on what tasks they need to perform to simplify the management of privileges.
User accounts
User accounts are unique names and passwords used to identify a person or client application that connects to your database. In ArcGIS, user accounts determine who owns what data. User accounts also provide a way to control what type of access (if any) a person or client application has to a database or geodatabase and its datasets.
Be aware that you can create usernames outside of ArcGIS that contain special characters, but these usernames must be delimited whenever they are used. ArcGIS will add the delimiter automatically when it is passed to SQL Server; you do not need to provide it when you log in. For example, if your username is map.user, type map.user, not "map.user" when you log in to SQL Server from ArcGIS. For more information on regular and delimited identifiers, see your SQL Server documentation.
Data ownership
For ArcGIS, the user who creates tables, feature classes, and views in a geodatabase or database owns those datasets. For example, the geodatabase administrator creates the geodatabase; therefore, the geodatabase system tables that are created in the database at that time are owned by the geodatabase administrator. Similarly, a user who creates a feature class owns that feature class.
The username used to make the connection to the geodatabase at the time the datasets are created is the one who owns them.
Users who own data must also have schemas in the database that have the same name as the username.
For instance, part-time staff members Boris and Basil are allowed to create datasets in the geodatabase. Boris and Basil use the same computer. If both use Basil's account to connect to the geodatabase in ArcGIS, all datasets created by either Boris or Basil will be owned by Basil and stored in his schema.
If Boris wants the data he creates to be stored in his schema, he must alter the database connection properties and connect to the database with his own username before he starts creating data.
Knowing who owns the data is important because you cannot remove a user account from the database if the user owns data, and it is the user who created the dataset who controls the level of access other users have to the dataset.
User access
Your database must be able to verify the user accounts that attempt to connect to it. That means the database administrator has to add users to the database. The database checks the list of users to make sure a user is allowed to make a connection. This process is called authentication.
Authentication types vary depending on whether you connect to SQL Server or one of the supported SQL Server-based database services. See Database connections in ArcGIS Pro for more information about authentication.
Once users are added, the database administrator must grant specific privileges to users to determine what they can and cannot do in the database. The database checks these privileges when an authenticated user tries to access or alter the database. This process is called authorization. In ArcGIS, data owners can also grant privileges on their data to other users or groups.
The types of privileges granted to a user are based on the type of work the user needs to perform. Some users only need to connect to the database and view specific data. Other users need to create new datasets. The following section explains how user accounts can be grouped to simplify privilege management.
Groups or roles
Most database management systems provide ways for the database administrator to group users based on their data access needs and assign privileges to the group. This can reduce the time spent altering each individual user's privileges and simplifies administration of large numbers of privileges for large numbers of users. You could, therefore, use groups (also called roles, types, or authorities depending on the database management system) that grant rights to users based on their common functions.
Common categories or groups of users are those who view data, those who edit data, and those who create data.
In most cases, granting rights to groups does not preclude granting rights to individual users in enterprise geodatabases. For instance, you could grant the minimum privileges required to create data in the database to the data creator group (which could include the geodatabase administrator), and grant additional privileges to only the geodatabase administrator user. Each database management system handles privilege precedence differently, though, so consult your database management documentation for details on the behavior of privileges for roles and individual users.
In addition, most database management systems provide predefined groups. One of these is the PUBLIC role.
The PUBLIC group or role is basically a variable that equates to anyone connected to the database; therefore, any right granted to PUBLIC is granted to everyone with a database connection. There may be cases in which all users require a certain privilege. For example, to connect to SQL Server or Db2 databases, users must be granted the CONNECT privilege. Because all users need this privilege to connect, SQL Server and Db2 grant this privilege to PUBLIC by default.
Sometimes, high-level privileges are given to PUBLIC by default when the database is created. However, for security reasons, granting privileges to PUBLIC should be used only when absolutely necessary.
For other predefined groups, consult your database management system documentation.
Tips for grouping users
The following are a few tips for grouping users in the database management system:
- Create separate groups (roles) for system and object privileges. This enables the database administrator to manage database privileges by granting them on the system groups, and data owners to grant privileges on their datasets by granting them to the object groups.
- Choose a naming convention that reflects each type of group (role) for easy reference. For example, for a group that will be able to edit all the land base data, you could name the group LANDBASE_EDITORS.
- Grant privileges directly to the geodatabase administrator and grant privileges via groups (roles) for all other users. The geodatabase administrator is a unique entity. In most cases, only one such user exists for any geodatabase and it is not part of a larger logical group of users. Experienced database administrators consider it good design to grant privileges directly to such application administrator accounts. By contrast, accounts for nonadministrators should receive privileges through groups that represent their job description, project responsibilities, or other logical classification within the organization.
- Avoid mixing roles with directly granted privileges for nonadministrator accounts. When nonadministrator accounts receive privileges through roles and have privileges granted to their accounts directly, a well-planned security model can quickly devolve into an unmanageable mess, requiring considerable time and effort to restore to an organized state. Set policies for data owners to follow when granting access to their data.
In the rare case that a nonadministrator account has truly unique security requirements, consider granting some privileges directly to avoid complicating the role-based security model. Document these cases; they should be the exception rather than the rule.