A quick tour of user accounts
User accounts determine who can access the data and who owns the data.
User access
Your geodatabase must be able to "recognize" the users who attempt to connect to it. That means an administrative user—the one who created the database—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.
There are two types of authentication used with geodatabases: operating system authentication and database authentication.
Operating system (OS) authentication indicates a user logs into the computer, and the credentials for authorization are supplied to the database by the operating system of the user's computer. For the connecting user, that means he or she only has to log in at his or her computer and does not have to log in separately to the database. For the database administrator, this means the existing login must be added to the database and the database must be configured to recognize the user's existing login.
If you use database authentication, users log into the server and then must separately log into the database using database user names and passwords, which the database administrator must create.
Only Oracle, SQL Server, and PostgreSQL utilize database user accounts; DB2 and Informix do not. For DB2 and Informix databases, the user accounts are managed by the operating system.
Once users are added, the administrative user must also grant specific permissions to users to determine what they can and cannot do in the geodatabase. The database checks these permissions when an authenticated user tries to access or alter the geodatabase. This process is called authorization.
The types of permissions granted to a user are based on the type of work the user needs to perform. Some users only need to view the data in the geodatabase. Others need to edit some of the datasets in the geodatabase. Certain users need to create new datasets. One or more users need to administer the geodatabase. For more information on administrative and other user permissions, see the topics appropriate for your DBMS:
- The_ArcSDE_administrative_account_in_DB2
- The_ArcSDE_administrative_account_in_Informix
- The_ArcSDE_administrative_account_in_Oracle
- The_ArcSDE_administrative_account_in_PostgreSQL
- The_ArcSDE_administrative_account_in_SQL_Server
- User_permissions_for_geodatabases_in_DB2
- User_permissions_for_geodatabases_in_Informix
- User_permissions_for_geodatabases_in_Oracle
- User_permissions_for_geodatabases_in_PostgreSQL
- User_permissions_for_geodatabases_in_SQL_Server
Data ownership
The user who creates tables in the database management system (DBMS) owns those tables. For example, the ArcSDE administrative user creates the geodatabase; therefore, the geodatabase system tables that are created in the DBMS at that time are owned by the ArcSDE administrative user. Similarly, a user who creates a feature class owns that feature class.
Be aware that the user name used to make the connection to the geodatabase at the time the tables are created is the one who owns the data.
For instance, part-time staff members Boris and Basil are allowed to create data in the geodatabase. Boris and Basil use the same computer. If both use Basil's account to connect to the geodatabase in ArcCatalog, 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 user name 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.