Introduction - Access 2003.
As you are aware implementing Microsoft Access Security is a serious business. Even though this has been deprecated from Access2007 and later versions, thousands of Access Developers are still using this feature. There are several pages of MS-Access Help text explaining the complexities of this feature and it is difficult to visualize how all of them fit together to form the security key.
I made an attempt here to put the main elements of Microsoft Access Security elements together into the form of a picture so that we will get a general idea of what all components are involved and where they are all kept for implementing Microsoft Access Security.
It is important to regulate Users' roles and maintain the security of data, the integrity of various objects, and the VBA Code.
We already have several Articles discussing Microsoft Access Security. You can access these articles from the Security Sub-Menu from the Main Menu Bar on 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 pieces of security elements, becomes the full security key of a User. See the diagram given below:
Workgroup FileID.
The first three elements: Workgroup Name, Organization & Workgroup Id form the unique Workgroup Information File identification elements. You must keep this information in a safe place, after creating the Workgroup Information File. If you somehow got lost this file you must give this specific information to create this Workgroup Information File again. MS-Access distinguishes one Workgroup Information File from the other using this unique information.
User Specific Credentials.
The next three elements: User or Group Name, Personal ID & Password, are User-specific information. Group-Account have only Group Names and Personal IDs, no passwords. It is very important that you keep a record of the User/Group Names and their Personal ID information in a safe place.
The Group Security Account is only a means of organizing Users into different groups so that their access privileges can be assigned at the Group level. Users inherit the access privileges assigned to the Users’ Group Account when they are added to the Group.
When you create a new Workgroup Information File, by default, there will be only one User Account: Admin and two Group Accounts: Admins & Users. The Admin User account is a member of the Admins & Users Group Accounts. You cannot delete these two Group Accounts and any new User Account, you create will be a member of the Users Group Account by default. You cannot delete the Admin User Account either, but it can be removed from the Admins Group Account as part of a security measure.
Members of the Admins Group have the full administrative power to assign permissions to Objects and transfer ownership of objects (except the Database Object) to any other User/Group accounts.
Database Owner.
Here, one important aspect you have to keep in mind is that the Owner of the Database (the User who created the Database)/Object has equal privileges of an Administrator, a member of the Admins Group Account. The owner of an object can assign permissions, like an administrator, for other Users or transfer his ownership of the object to another User.
Ownership of a Database Object cannot be transferred to anybody. But, one who likes to take ownership of a Database, must create a new database and import all the objects (if, he has enough privileges to do that) into the new Database.
[...] 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