To change permissions for just one object (form or report) in your database, you first need a user account with administer permission over that object (and hopefully all others as well). The steps to achieve this protection follow:
Join the developer workgroup file (called Developer.mdw ) as described in the "Preparing Your Developer Workgroup File" section earlier in the chapter.
Select the database that you are going to secure (I use a copy of Northwind in these examples).
Log on to the developer's account (which we earlier named Developer). If you are already using Access, double check that you are using the correct workgroup file and user account.
Open the database container and select a form or report to protect. In this case, I will select the first form in the Northwind database, called Categories .
Choose Tools ˜ Security ˜ User and Group Permissions.
Select Admin in the User/Groups Name list. Clear the Read Design check box in the Permissions area. This action also clears the Modify Design and Administer check boxes. Now click Apply.
Choose the Groups option. A dialog appears, asking if you want to assign the permissions now. Click Yes.
Select Users in the User/Groups Name list.
Clear the Read Design check box in the Permissions area, as shown in Figure 8-11. Now click Apply.
Figure 8-11: Clearing the Read Design check box in the Permissions area.
Finally, change the ownership of the object to the Developer account to make sure that the anonymous Admin user cannot modify this object. To do this, select the Change Owner tab. Now choose the correct object type (form or report) and choose the object. Then select your secure user (Developer) from the New Owner drop-down list, as shown in Figure 8-12.
Figure 8-12: Changing the ownership of the form to the Developer.
Tip | You can always check your user account in the Current User field at the bottom of the User and Group Permissions dialog. |
That concludes the process of securing an object. To describe this important process in a different way, here is a summary of what we have done. We have minimized the necessary permissions on an object for the Admin user and the Users group and changed the ownership of the object to your Developer user account. Now, unless the user can log on to or re-create the same developer workgroup file, you will achieve the following worthwhile security and protection outcomes .
The obvious benefit of these changes is that the anonymous Admin account cannot open the object in design mode.
Removing read design permissions from an object prevents someone from importing the object into another database. To try out this deterrence, open another database and import (the already secured) Categories form from the Northwind database with which we have been experimenting. When you do, you will receive the error message shown in Figure 8-13.
Whenever you open an Access database in a later version of Access, Access will assess the permissions of all the objects in the database. If Access finds that the current user has read design permissions for all the objects in the database (and passes other requirements as well), the user can upgrade the database to a later version of the database. If Access doesn't find that the user is able to convert the database, a warning message appears, as shown in Figure 8-14.
User Story | This particular result of securing an object has proved profitable to me over the years when the occasional user has wandered off to another employer with the database. When that user arrives, they find that the new employer has a later version of Access, making it impossible to run the database the user depended on. One such user relocated from central Australia to West Africa and, after opening the software, found that he was blocked. If he had looked hard enough, he would have found that he could have imported all the important objects into another database because in this case, I had not protected any object of importance. The other way in which this result proves useful is when clients themselves upgrade Access. At this stage, I receive a call and a little bit of work to upgrade and test the software, and I have a chance to reestablish contact after long periods of maintenance-free running. A good analogy is that securing just one object is a bit like designing a refrigerator so that it starts to break down after seven years. |
One feature of multiversion compatibility with Access is the Open Database option (shown in Figure 8-15) that allows Access 2000 or later to open Access 97 databases without converting the database. This seemingly useful option is not without its pitfalls, however, because the first time that someone opens the database this way, the database expands without warning because Access adds extra compatibility information to the database. As an example, the Access 97 Northwind database expands from 1.5MB to 2.2MB. Not even the unsupported \decompile shortcut switch will retrieve the space. But because you're interested in protecting your database, not having the appropriate permissions will stop the anonymous Admin account from opening the database by using a later version of Access.
That concludes the descriptions of the considerable benefits that result from removing the object permissions from the anonymous Admin account and Users group. In the next section of this chapter, I describe how to transfer the ownership of all the objects in the database to the new Developer account.