Set or change Access 2003 user-level security in current Access versions

The basics of user-level security

User-level security in Access resembles the security mechanisms on server-based systems — it uses passwords and permissions to allow or restrict the access of individuals, or groups of individuals, to the objects in your database. In Access 2003 or earlier versions, when you implement user-level security in an Access database, a database administrator or an object's owner can control the actions that individual users, or groups of users, can perform on the tables, queries, forms, reports, and macros in the database. For example, one group of users can change the objects in a database, another group can only enter data into certain tables, and a third group can only view the data in a set of reports.

User-level security in Access 2003 and earlier versions uses a combination of passwords and permissions — a set of attributes that specifies the kinds of access that a user has to the data or objects in a database. You can set passwords and permissions for individuals or groups of individuals, and those combinations of passwords and permissions become security accounts that define the users and groups of users who are allowed access to the objects in your database. In turn, the combination of users and groups is known as a workgroup, and Access stores that information in a workgroup information file. At startup, Access reads the workgroup information file and enforces the permissions based on the data in the file.

By default, Access provides a built-in user ID and two built-in groups. The default user ID is Admin, and the default groups are Users and Admins. By default, Access adds the built-in user ID to the Users group because all IDs must belong to at least one group. In turn, the Users group has full permissions on all the objects in a database. In addition, the Admin ID is also a member of the Admins group. The Admins group must contain at least one user ID (there must be a database administrator), and the Admin ID is the default database administrator until you change it.

When you start Access 2003 or earlier versions, Access assigns the Admin user ID to you and thus makes you a member of each default group. That ID and those groups (Admin and Users) give all users full permissions on all the objects in a database — this means that any user can open, view, and change all the objects in all .mdb files unless you implement user-level security.

One way to implement user-level security in Access 2003 or earlier versions is to change the permissions for the Users group and add new administrators to the Admins groups. When you do so, Access automatically assigns new users to the Users group. When you take those steps, users must log in with a password whenever they open the protected database. However, if you need to implement more specific security — allow one group of users to enter data and another to only read that data, for example — you must create additional users and groups, and grant them specific permissions to some or all of the objects in the database. Implementing that type of user-level security can become a complex task. To help simplify the process, Access provides the User-Level Security Wizard, which makes it easier to create users and groups in a one-step process.

The User-Level Security Wizard helps you to assign permissions and create user and group accounts. User accounts contain user names and unique personal ID numbers (PIDs) needed to manage a user's permissions to view, use, or change database objects in an Access workgroup. Group accounts are a collection of user accounts that, in turn, reside in a workgroup. Access uses a group name and PID to identify each work group, and the permissions assigned to a group apply to all users in the group. For more information about using the wizard, see Set user-level security, later in this article.

After you complete the wizard, you can manually assign, modify, or remove permissions for user and group accounts in your workgroup for a database and its existing tables, queries, forms, reports, and macros. You can also set the default permissions that Access assigns for any new tables, queries, forms, reports, and macros that you or another user add to a database.

Workgroups and workgroup information files

In Access 2003 and earlier versions, a workgroup is a group of users in a multiuser environment who share data. A workgroup information file contains the user and group accounts, passwords, and permissions set for each individual user or group of users. When you open a database, Access reads the data in the workgroup information file and enforces the security settings that the file contains. In turn, a user account is a combination of user name and personal ID (PID) that Access creates to manage the user's permissions. Group accounts are collections of user accounts, and Access also identifies them by group name and a personal ID (PID). Permissions assigned to a group apply to all users in the group. Those security accounts can then be assigned permissions for databases and their tables, queries, forms, reports, and macros. The permissions themselves are stored in the security-enabled database.

The first time a user runs Access 2003 or earlier versions, Access automatically creates an Access workgroup information file that is identified by the name and organization information that the user specifies when he installs Access. For Access 2003, the setup program adds the relative location of this workgroup information file to the following registry keys:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Access\Jet\4.0\Engines\SystemDB

and

HKEY_USERS\.DEFAULT\Software\Microsoft\Office\11.0\Access\Jet\4.0\Engines\SystemDB

Subsequent users will inherit the default workgroup file path from the value in the HKEY_USERS registry key. Because this information is often easy to determine, it is possible for unauthorized users to create another version of this workgroup information file. Consequently, unauthorized users could assume the irrevocable permissions of an administrator account (a member of the Admins group) in the workgroup defined by that workgroup information file. To prevent unauthorized users from assuming these permissions, create a new workgroup information file, and specify a workgroup ID (WID), a case-sensitive alphanumeric string from 4 to 20 characters long that you enter when you create a new workgroup information file. Creating a new workgroup uniquely identifies the Admin group for this workgroup file. Only someone who knows the WID will be able to create a copy of the workgroup information file. To create the new file, you use the User-Level Security Wizard.

How permissions work and who can assign them

User-level security recognizes two types of permissions: explicit and implicit. Explicit permissions are those permissions that are granted directly to a user account; no other users are affected. Implicit permissions are the permissions granted to a group account. Adding a user to that group grants the group's permissions to that user; removing a user from the group takes away the group's permissions from that user.

When a user attempts to perform an operation on a database object that employs security features, that user's set of permissions are based on the intersection of that user's explicit and implicit permissions. A user's security level is always the least restrictive of that user's explicit permissions and the permissions of any and all groups to which that user belongs. For this reason, the least complicated way to administer a workgroup is to create new groups and assign permissions to the groups, rather than to individual users. Then you can change individual users' permissions by adding or removing those users from groups. Also, if you need to grant new permissions, you can grant them to all members of a group in a single operation.

Permissions can be changed for a database object by:

• Members of the Admins group of the workgroup information file in use when the database was created.

• The owner of the object.

• Any user who has Administer permissions for the object.

Even though users might not be able to currently perform an action, they might be able to grant themselves permissions to perform the action. This is true if a user is a member of the Admins group, or if a user is the owner of an object.

The user who creates a table, query, form, report, or macro is the owner of that object. Additionally, the group of users that can change permissions in the database can also change the ownership of these objects, or they can re-create these objects, both of which are ways to change ownership of the objects. To re-create an object, you can make a copy of the object, or you can import it from, or export it to, another database. This is the easiest way to transfer the ownership of objects, including the database itself.

Security accounts

An Access 2003 workgroup information file contains the following predefined accounts.

In effect, security in Access 2003 and earlier versions is always active. Until you activate the logon procedure for a workgroup, Access invisibly logs on all users at startup by using the default Admin user account with a blank password. Behind the scenes, Access uses the Admin account as the administrator account for the workgroup. Access uses the Admin account in addition to the owner (group or user) of any databases and tables, queries, forms, reports, and macros that are created.

Administrators and owners are important because they have permissions that can't be taken away:

• Administrators (members of the Admins group) can always get full permissions for objects created in the workgroup.

• An account that owns a table, query, form, report, or macro can always get full permissions for that object.

• An account that owns a database can always open that database.

Because the Admin user account is exactly the same for every copy of Access, the first steps in helping to secure your database are to define administrator and owner user accounts (or use a single user account as both the administrator and owner accounts), and then to remove the Admin user account from the Admins group. Otherwise, anyone with a copy of Access can log on to your workgroup by using the Admin account and have full permissions for the workgroup's tables, queries, forms, reports, and macros.

You can assign as many user accounts as you want to the Admins group, but only one user account can own the database — the owning account is the user account that is active when the database is created or when ownership is transferred by creating a new database and importing all of a database's objects into it. However, group accounts can own tables, queries, forms, reports, and macros within a database.

Considerations when organizing security accounts

• Only user accounts can log on to Access; you can't log on by using a group account.

• The accounts that you create for users of the database must be stored in the workgroup information file that those users will join when they use the database. If you are using a different file to create the database, change the file before creating the accounts.

• Make sure to create a unique password for your administrator and user accounts. A user who can log on by using the administrator account can always get full permissions for any tables, queries, forms, reports, and macros that were created in the workgroup. A user who can log on by using an owner account can always get full permissions for those objects owned by that user.

After you create user and group accounts, you can view and print the relationships between them. Access prints a report of the accounts in the workgroup that shows the groups to which each user belongs and the users that belong to each group.

Start the User-Level Security Wizard

1. Open the .mdb or .mde file that you want to administer.

2. On the Database Tools tab, in the Administer group, click the arrow below Users and Permissions, and then click User-Level Security Wizard.

3. Follow the steps on each page to complete the wizard.

   Notes: 

   • The User-Level Security Wizard creates a back-up copy of the current Access database with the same name and a .bak file name extension, and then employs security measures for the selected objects in the current database.

   • If your current Access database helps protect VBA code by using a password, the wizard prompts you for the password, which you must enter for the wizard to complete its operation successfully.

   • Any passwords that you create through the wizard are printed in the User-Level Security Wizard report, which is printed when you finish using the wizard. You should keep this report in a secure location. You can use this report to re-create your workgroup file if it is lost or corrupted.

Save a copy of the file in the .ACCDB format

1. Click the File tab. The Backstage view opens.

2. On the left, click Share.

3. On the right, click Save Database As, and then click Access Database (*.accdb).

   The Save As dialog box appears.

4. Use the Save In list to find a location in which to save the converted database.

5. In the Save as type list, select Access 2007-2016 Database (*.accdb).

6. Click Save.