Introduction - Access 2003.
Implementing Microsoft Access Security is a serious undertaking. Although this feature was deprecated starting with Access 2007, thousands of developers still rely on it in their applications. Microsoft’s documentation spans several pages, detailing the intricacies of this system, and it can be difficult to visualize how all the components work together to form the complete security framework.
To clarify this, I have created a diagram that consolidates the key elements of Microsoft Access Security. This visual overview provides a general understanding of the components involved and how they fit into the overall security structure.
Maintaining proper security is critical—not only to regulate user roles but also to safeguard data, protect the integrity of database objects, and ensure the security of VBA code.
For a deeper dive, you can explore the collection of articles on Microsoft Access Security available under the Security sub-menu on the main menu bar of this site.
Microsoft Access Security - Two Sections.
The first part of the Security elements (Workgroup File Id elements and User/Group Names, Personal IDs, and Passwords) resides within the Workgroup Information File.
Object-level access rights information that resides within the Database forms the second part.
When both parts are combined, consisting of fourteen security elements, it becomes the full security key of a User. See the diagram given below:
Workgroup FileID.
The first three elements—Workgroup Name, Organization, and Workgroup ID—serve as the unique identifiers of a Workgroup Information File. It is essential to keep this information safely stored after creating the file. If the file is ever lost, you will need these exact details to recreate it. Microsoft Access uses this combination of values to distinguish one Workgroup Information File from another.
User Specific Credentials.
The next three elements—User or Group Name, Personal ID, and Password—are user-specific credentials. Group accounts, however, contain only a Group Name and Personal ID; they do not use passwords. It is crucial to maintain a secure record of all User and Group Names along with their corresponding Personal IDs.
Group accounts are primarily a way to organize users, allowing access privileges to be assigned at the group level. Any user added to a group automatically inherits that group’s access permissions.
When you create a new Workgroup Information File, it includes, by default:
-
One User Account: Admin
-
Two Group Accounts: Admins and Users
The Admin user account is automatically a member of both groups. While the two group accounts (Admins and Users) cannot be deleted, new user accounts you create will always be added to the Users group by default. Similarly, the Admin user account itself cannot be deleted, but as a security precaution, it can be removed from the Admins group.
Members of the Admins group hold full administrative authority. They can assign permissions to objects and transfer ownership of objects (except the database object) to other user or group accounts.
Database Owner.
An important point to remember is that the owner of a database or object (i.e., the user who created it) has the same privileges as an administrator, specifically as a member of the Admins group. The owner of an object can assign permissions to other users or transfer ownership of that object to another user, just as an administrator would.
However, ownership of a database itself cannot be transferred. If someone wishes to assume ownership of a database, they must create a new database and then import all the objects from the original database. Provided they have sufficient permissions to do so.
[...] idea as how the Access Security Key elements assembled together to assign access privileges: http://msaccesstips.com/2011/10/acce...y-key-diagram/ If the tables are linked to the FE and the data can be read from there, then create Make-table [...]
ReplyDelete