Access Security Key Diagram

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.

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

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

Read More

User and Group Check

Introduction.

In a secured Database; basic access rights to Objects like Tables, Forms, Queries, and Reports are defined for specific Workgroups/Users as a one-time exercise. This takes effect automatically when a User belonging to a particular Workgroup accesses the Database Objects.

For example: Assume that the Employees Table is set with only Read Data permission for Group-A Workgroup.  When a User belongs to Group-A opens the Employees Form with the Employees Table as Record Source or opens the Table directly, he cannot execute Update/Insert/Delete Data operations on the Table. 

But, if we want to make this scenario a little more flexible like allowing for Update data, then this can be enabled in the User and Group Permissions Control under the Security option in the Tools Menu.

In this case, all Users belonging to Group-A Workgroup can Edit and Update all Data Fields of the Employees Table.  Normally, Users are never allowed to open Tables directly, but through Data Entry/Edit/Display Forms, allowing the Developer more control over the Users.

When we assign Update Data permission all data fields can be modified/updated by Users.  But, if we want to prevent the Users, from making changes to certain fields of data; it cannot be done through the normal security methods explained 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 open 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 or not.

3. If so, then lock the Birth Date and Hire Date fields on the Form, so that the current user is prevented from making changes to these two field values.

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 then the Birth Date and Hire Date data fields are locked on the Form through the Form_Load() Event Procedure so that the current user cannot edit the contents of these fields.

3. If the user belongs to some other Workgroup then the above fields are unlocked and allowed to edit/update.

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 name belongs to the Workgroup name you have assigned to the strGroup Variable then the Birthdate and HireDate fields will be in the locked state.

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 above Subroutine. By default, you will be logged in as Admin User, as a member of the Admins Workgroup. This will lock both the above test fields from editing when the Employees Form is open.

Technorati Tags: Microsoft

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

Read More

Change Secure DB to Unsecured

Introduction.

It is very unlikely that you want to change the status of a Secured Database (implemented with Microsoft Access Security) to an unsecured one. This exercise becomes necessary when you want to install/share a Database in an unsecured environment.

Before we embark on this simple exercise to remove the security settings of a database, the first thing to do is to change the Ownership of the Database.  The Owner (the User who created the Database is the Owner) of the Database Object has full access rights to all objects within the database and can assign permissions to other Users or User-Groups as well.  Members of the Admins Group also have 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 very 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 on the Select All Command Button to select all the Tables to import.

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

   

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

7. Put the checkmark in the Menus and Toolbars option.

8. Click OK to Import all Objects (other than hidden objects) into the new Database.

Access privileges of all objects of the new database have now been set to default.  By default, all Users of the new Database are members of the Users Group and they all have Full Access Rights (to Open/Run, Read Design, Modify Design, Administer permissions) to all Objects.

But, if you plan to share this unsecured database on a Network you should make a few changes to make it available for concurrent use.  Otherwise, the database cannot be used by more than one user at the same time.

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

   

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 all Users are silently logged in as  Admin Users.  MS-Access will not prompt for User Id and Password.

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

8. Remove the check-mark from the Open Exclusive Option.

   

9. Click OK to close the Dialog Box.

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

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