Access Security Key Diagram

Access Security Key Diagram - 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.

1. The first part of the Security elements (Workgroup File ID elements, User/Group Names, Personal IDs, and Passwords) resides in the Workgroup Information File.

2. 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:

Right-click to open Large Image in New Tab/Window.

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 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, 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.

• User-level Access Security and Access 2007
• Macro and Temporary Variables
• Easy-read Reports
• Top N Records in Query
• Attachment field in Access 2007

Read More

User and Group Check

User and Group Check.

In a secured database, basic access rights to objects—such as Tables, Forms, Queries, and Reports—are defined for specific Workgroups or Users as a one-time exercise. These permissions take effect automatically when a User belongs to a particular Workgroup for the database objects.

For example, if the Employees Table is configured to allow only Read Data permission for the Group-A Workgroup, any User in Group A cannot update, insert, or delete records when opening the Employees Form (with the Employees Table as its Record Source) or when accessing the Table directly.

If you want to make this scenario more flexible—for instance, to allow Users to update data— then this can be enabled in the User and Group Permissions control under the Security option in the Tools menu.

Right-click to open Large Image in New Tab/Window.

In this case, all Group-A Workgroup Users can edit and update all data fields of the Employees Table. Normally, Users are not allowed to open Tables directly; instead, they interact with the data through Data Entry, Edit, or Display Forms, which gives the Developer greater control over how the data is accessed and modified.

When the Update Data permission is assigned, Users can modify all fields in the Table. However, if we want to prevent Users from changing certain specific fields, this cannot be enforced using the standard security methods described above.

Field-Level Security Implementation.

This level of security can be implemented only through Visual Basic Programs.  This method can be implemented in the following way:

1. When the Employee Form is opened by the User for normal work, we can get the User Name through the CurrentUser() Function.

2. The next step is to check whether this User belongs to the Group-A Workgroup.

3. If so, lock the Birth Date and Hire Date fields on the Form to prevent the current user from making changes.

We need two programs to try out this method:

1. A Function to check and confirm whether the User Name passed to it belongs to a particular Workgroup; if so, send a positive signal back to the calling program.

2. If the user is identified as a member of the Group-A Workgroup, the Birth Date and Hire Date data fields are locked on the Form through the Form_Load() Event Procedure; the current user cannot edit these field contents.

3. If the user belongs to a different Workgroup, then the above fields are unlocked for editing/updating. 

The Demo Run.

To try this out:

1. Import the Employees Table and Northwind.mdb

2. Open an existing Standard VBA Module or create a new one.

3. Copy and paste the following Visual Basic Code into the Module and save it:

   Public Function UserGroupCheck(ByVal strGroupName As String, ByVal strUserName As String) As Boolean
   Dim WrkSpc As Workspace, Usr As User
   
   On Error GoTo UserGroupCheck_Err
   
   Set WrkSpc = DBEngine.Workspaces(0)
   
   For Each Usr In WrkSpc.Groups(strGroupName).Users
   If Usr.Name = strUserName Then
       UserGroupCheck = True
       Exit For
   Else
       UserGroupCheck = False
   End If
   
   Next
   
   UserGroupCheck_Exit:
   Exit Function
   
   UserGroupCheck_Err:
   MsgBox Err.Description, , "UserGroupCheck_Err"
   Resume UserGroupCheck_Exit
   
   End Function

4. Open the Employees Form in Design View.

5. Display the Form's VBA Module (View --> Code).

6. Copy and paste the following code into the VBA Module and save the Form:

   Private Sub Form_Load()
   Dim strUser As String, strGroup As String, boolFlag As Boolean
   
   strUser = CurrentUser
   strGroup = "GroupA" 'replace the GroupA value with your own test Group Name
   boolFlag = UserGroupCheck(strGroup, strUser)
   
   If boolFlag Then
      Me.BirthDate.Locked = True
      Me.HireDate.Locked = True
   Else
      Me.BirthDate.Locked = False
      Me.HireDate.Locked = False
   End If
   
   End Sub

7. Open the Form in Normal View.

8. Try to change the existing values in the Birth Date and Hire Date Fields.

If the Current User belongs to the Workgroup name assigned to the strGroup Variable, then the Birthdate and HireDate fields will be locked.

Tip: Even if your database is not implemented with Microsoft Access Security, you can test these programs. Assign the value Admins to the strGroup variable in the Subroutine. By default, you will be logged in as Admin User, a member of the Admins Workgroup. This will lock both the test fields from editing when the Employees Form is open.

Technorati Tags: Microsoft

• Group Account Permissions with VBA
• Users Group and Permissions
• Creating a User Account with VBA
• Microsoft Date/Time Picker Control
• Form and Report Open Arguments

Read More

Change Secure DB to Unsecured

Change Secure DB to Unsecured.

It is generally uncommon to convert a secured database (implemented using Microsoft Access Security) into an unsecured one. However, this step may become necessary when you want to deploy or share a database in an environment that does not use security.

The first step in removing security from a database is to change the ownership of the database objects. By default, the User who creates the database is its Owner. The owner of an object has full access rights to it and can also assign permissions to other Users or Groups. Additionally, members of the Admins group possess these privileges.

Points to remember:

1. The User who attempts to convert the Database must have at least Read Permission to all Objects of the Database.

2. The Hidden Objects, if any, cannot be transferred into the target Database.

The Conversion Process.

The conversion process is simple and needs only a few steps.

1. Create a new Database.

2. Select File --> Get External Data --> Import.

3. Browse to the location of the Database you are trying to convert, and open it.

4. Select the Tables tab, and click the Select All Command Button to select all Tables to import.

5. Repeat this method for all Queries, Forms, Reports, Macros, and Modules.

   

   Right-click to open Large Image in New Tab/Window.

6. If your Database has Custom Menus and Toolbars, then click on Options.

7. Select the Menus and Toolbars option.

8. Click OK to import all Objects (except the hidden objects) into the new Database.

At this stage, the access privileges of all objects in the new database are reset to their defaults. By default, every database user is a member of the Users group, and therefore has full access rights to all objects. This includes permissions to Open/Run, Read Design, Modify Design, and Administer permissions.

However, if you intend to share this unsecured database over a network, a few additional changes are required to enable concurrent use. Without these adjustments, the database will be limited to single-user access, preventing concurrent use. 

Changes for Multi-User Environment.

1. Select Tools --> Options --> Advanced.

2. Select Shared under the Default Open Mode Options Group.

3. Select Edited Record under the Default Record Locking Options Group.  Open Database using Record Level Locking Option is already in the selected state.

   

   Right-click to open Large Image in New Tab/Window.

4. Click OK to close the Dialog Box.

5. Select Tools --> Security --> User and Group Permissions.

6. Select the Admin User Name under the User/Group Name List. 

   Why select Admin User Account? Because in an unsecured environment, it is a member of the Admins Group and logged in silently when no password is set.  MS Access will not prompt for User ID and Password.

7. Select the Database Object in the Object Type Control.

8. Unselect the Open Exclusive Option.

   

   Right-click to open Large Image in New Tab/Window.

9. Click OK to close the Dialog Box.

Now, you have a new Database with no Security settings.  The old database will remain unchanged.

Technorati Tags: Microsoft Security

1. Microsoft Access Security
2. Convert MS-Access Old Versions
3. Convert Old Version Workgroup File
4. Share Previous Version Database

Read More