Password-Protecting Access Front-Ends

All production database applications should have at least some level of security applied. The minimum level of security is password-protecting the front end .mdb file. The problem with password protection is that users can open any Access object except password-protected VBA code in Design view and make changes to the front end. The only method of preventing unauthorized design changes to a password-protected .mdb file is to distribute the front end as an .mde file or supply a runtime version of your application, which requires the Access 2003 Developer Extensions' runtime version of MSAccess.exe, which was included with the Microsoft Office Developer Edition (MOD) for earlier Office versions. Creating an .mde version from a copy of your front-end .mdb file or use of runtime Access prevents users from opening any object in Design view. As a general rule, don't password-protect or create .mde versions of back-end .mdb files. Instead, use share- and file-level security, as described in the earlier "Establishing Network Share and File Security for the Back End" section, apply user-level security, or both.

For more information about user-level security, see "Applying User-Level Security to Access Front-Ends," p. 783.


Caution

Don't password-protect back-end .mdbs whose data you intend to replicate. Jet replication fails with password-protected databases. SQL Server back ends use publish/subscribe replication, which relies on Windows or SQL Server security.


Providing your application's users with a password-protected .mde version of your front-end database is the simplest method to achieve nominal security. You set only the initial password for the .mdb precursor of the .mde file; users can change the password of an .mde file. This means that everyone running your front-end can unset the password, which can compromise security. You or your network administrator can minimize security breaches by requiring network users to change their logon passwords periodically. Changing logon passwords doesn't require changes to file-based or SQL Server security parameters for the back end.

Adding a Database Password

To password-protect a front-end .mdb file, do this:

  1. Close the database if it's open, and store an unprotected backup copy of the front end on a secure medium, such as a recordable or rewritable CD, or floppy disk. Most front-end .mdbs will fit on a 1.44MB floppy disk. Use the backup copy if you forget the password. This copy also serves as the backup for an .mde version.

  2. Choose File, Open to display the Open dialog.

  3. Select the file to protect, and click the arrow to the right of the Open button to display a list of Open... options (see Figure 19.31). Choose Open Exclusive to open the file for exclusive use.

    Figure 19.31. Use the Open button's list to open the .mdb file in exclusive mode. You need exclusive access to change the database password.

    graphics/19fig31.gif

  4. Choose Tools, Security, Set Database Password to open the dialog of the same name. If you didn't open the file for exclusive use in step 3, you receive an error message.

  5. Type and confirm the password in the two text boxes (see Figure 19.32), click OK, and close the database.

    Figure 19.32. Type and confirm the front-end password in the Set Database Password text boxes. For maximum security, use a combination of upper- and lower-case letters, numbers, and allowed punctuation characters. You can't use the following characters in a password: " \ [ ] : | < > + = ; , . ? *.

    graphics/19fig32.jpg

  6. Reopen the .mdb file, type the password in the Password Required dialog's Enter Database Password text (see Figure 19.33), and click OK.

    Figure 19.33. Users must type the database-specific password to open the front end. Password protecting a database doesn't prevent users from making design changes or other modifications to database objects.

    graphics/19fig33.jpg

To remove the password, repeat steps 2 4, but choose Unset Database Password in step 4. Type the password again in the text box and click OK.

Password-Protecting VBA Code

Access 2000 introduced password protection for VBA 6.0 code in conventional and Class Modules. You don't need to password-protect VBA code if you convert your front end to an .mde file, which compiles your source code and removes it from the .mde file. Class Modules (also called Microsoft Access Class Objects) hold the VBA code behind forms and reports. You might want to protect your VBA code against modification by users who have design privileges for the front end.

You can prevent users from viewing or modifying the VBA code in your entire front end by taking the following steps:

  1. graphics/code.gif Open any module, form, or report in Design view, and click the Code button of the form or report to open the VBA editor. Exclusive access isn't necessary to password-protect VBA code.

  2. Choose Tools, ProjectName Properties to open the ProjectName Properties dialog, and click the Protection tab.

  3. Mark the Lock Project for Viewing check box, and type and confirm a password in the two text boxes (see Figure 19.34). Click OK.

    Figure 19.34. Prevent front-end users from viewing and modifying your VBA code behind forms and reports and in modules by password-protecting the code for the entire project.

    graphics/19fig34.gif

    Tip

    Don't use the same or a similar password for the VBA code and the database. The database password will be the first choice of curious users. More determined users will try variations on the database password, such as adding a numeric suffix.

  4. Close and reopen the database, and then repeat step 1. Type the password in the ProjectName Password dialog, and click OK.

To remove the VBA code password, repeat steps 1 and 2, clear the Lock Project for Viewing check box, and click OK.

Note

You can't apply user-level security to Access 200x VBA 6.0 modules, because VBA modules no longer are Access objects, despite the fact that the code is stored in the .mdb file. The VBA 6.0 editor is the same for all Office 2003/2000 components. Access 97 and earlier versions have an Access-specific version of the VBA editor.


Creating and Testing an .mde Front-End

As mentioned earlier, .mde files provide a quick way to protect your front ends from modification by users. Users can't add, delete, or view in design mode forms, reports, and modules. Users have unrestricted access to tables and queries, which means they can wreak havoc on their own copy of the program by deleting links to tables, rewriting queries, and performing other mischief. Applying user-level security is the only means of securing local and linked tables, and preserving the integrity of queries and macros (if you use macros).

Creating an .mde file from an .mdb front end is a one- or two-step process. If you created your front-end database in the default Access 2000 format, you must choose Tools, Database Utilities, Convert Database, To Access 2002 Format and specify a different name for your front end, such as NWClient2002.mdb. This action, of course, restricts use of your MDB file to users with Access 2002 or later.

Open your Access 2002 front-end .mdb file and choose Tools, Database Utilities, Make MDE File to open the Save MDE As dialog. Accept the default MdbFileName.mde or rename the file. Click Save to create the new .mde file. Open the .mde file and verify user restrictions for tables, forms (see Figure 19.35), reports, and modules. Users might be able to open the Visual Basic Editor but can't view source code, because creating the .mde file removes the source code.

Figure 19.35. The context menu for a form illustrates user restrictions by disabled choices. Unfortunately, there are no user restrictions for tables, queries, and macros other than Add to Group.

graphics/19fig35.jpg



Special Edition Using Microsoft Office Access 2003
Special Edition Using Microsoft Office Access 2003
ISBN: 0789729520
EAN: 2147483647
Year: 2005
Pages: 417

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net