Trusting Your Users by Adopting the Same Workgroup File



Once you have decided that you don't want everyone on your network to have access to your database, the easiest Access security technique is to add a user or two to your workgroup file. This action means that, for the first time, you have to start trusting your database users. The approach that you will probably want to take in this case is to provide these designated users with the authority to edit your data and use the interface that you have designed for your database. You need to have a level of trust in your users because, by exposing the workgroup security file, your users could install password-cracking software to find your Developer account's user name and password.

Irrespective of what you think about the protection provided by this approach, it is a good idea to learn how to set up a new user and add it to a Group account. To do so, follow these steps:

  1. Make a copy of the database and save it in a temporary directory. In this case, we are using the Northwind database.

  2. Follow the steps in the previous section to protect the database against the anonymous Admin workgroup account.

  3. Back up your developer workgroup file that we created in Chapter 8.

  4. Join this developer workgroup file by using the workgroup administrator. Remember to recover the back-up workgroup file if you don't like the changes that you make in this section.

  5. Now log on to the workgroup file by using the Developer account.

Note  

If you are already in the database and you want to make changes to the workgroup security, it is always a good idea to test which work-group and workgroup account you are in by using the CurrentUser and SysCmd(13) functions in the Immediate window (explained in Chapter 8).

Now choose Tools ˜ Security ˜ User and Group Accounts to add a new User account. In this case, you want to add a User account that will edit the data in the database. Call this account the Editor account, as shown in Figure 10-9. Whenever you create a new account, you also have to give the account a personal ID (PID). For this book, I have used a PID of Real World Editor. Please make sure that you record the details of the account, either by writing down the information or by capturing a screen print of the New User/Group dialog and saving it as a file. If you forget or lose these entries, you cannot recover them.

click to expand
Figure 10-9: Making a new account that will be used to edit data.

Once you have added the account, remember to use the Change Logon Password tab to add a password for the account.

Note  

Permissions on queries, forms, reports , data access pages, and macros are covered in Chapter 11.

Creating Our New Group of Users

The next step in adding a new user to a database involves creating a Group account and adding the user to it. The group that I want to add will, in this case, have full access to all the data in the database. For simplicity of instruction, I will use the same name for the group as the equivalent permissions scheme used by the User-Level Security wizard (discussed later).

To create a new users group, choose Tools ˜ Security ˜ User and Group Accounts and select the Groups tab, as shown in Figure 10-10. Now click the New button and add the name of your group (Full Data Users) and a PID (Real World Full Data). Remember to write these names down because you will need them to reconstruct the workgroup file or to implement one of the PID authentication strategies that I will outline later in this chapter. When you have added the new Group account, return to the Users tab for the next step.

click to expand
Figure 10-10: Adding a new users group to the database.

To complete the setting up of a Group account, you need to make the appropriate account (Editor) a member of the Group (Full Data Users). Now select the Editor user from the Name drop-down list and move the Full Data Users account over to the Member Of list box (as shown in Figure 10-11) by using the Add button.

click to expand
Figure 10-11: Adding the Editor user to the Full Data Users group.

Giving the Group Account Permissions to Access Our Data

To add data- related permissions, choose Tools ˜ Security ˜ User and Group Permissions. Now select Full Data Users from the Groups drop-down list (shown in Figure 10-12). Next, select all the tables for which you want to provide permissions, including, probably, the <New Tables/Queries> value. Selecting this value means that you will not need to remember to select permissions for each table as you add it to the database. Now select all the data editing permissions (the Read Data, Update Data, Insert Data, Delete Data, and Read Design check boxes). There is no need to select Modify Design or Administer, because this user should not need to change your table designs. Now click Apply, and the Group will be granted the permissions.

click to expand
Figure 10-12: Granting full data permissions to the Full Data Users group.

Now you should log on to the database with the new account (Editor) that is a member of this workgroup (Full Data Users) to test that your new permissions are working. If you are as fallible as I am, you will need to take your time setting up your security. I habitually forget to select the correct User/Group name before I apply the permissions, which usually means making changes to the first item in the User/Groups list, which is usually one of the big A accounts, Admin or Admins, and usually results in me getting the big C for confusion.

Can Other Objects Override Table Permissions?

When I first started describing how to use permissions on tables to protect data, I split the Northwind application into front and back ends to separate the application from the data. Then I proceeded to secure the database by denying access to the tables for the ubiquitous Users group. Finally, I added a new users group that had permissions to edit data. If you have also been trying out the examples, you will have seen that this work has secured the data in the tables so that only someone using the account from the correct workgroup will actually have the authority to change (or even view) the data.

But does this mean that the data is protected when you use other objects in the database? To test, join your default workgroup file and log on to the Northwind front-end database. Here you will find that you will be able to see and edit the objects in the front end of the Northwind database. When you go to open a form, such as the Categories form, however, you will find that the anonymous Admin account that you logged on as does not have the appropriate permissions to view or modify the data, and you'll get an error message (shown in Figure 10-13).

click to expand
Figure 10-13: No permission to open the Categories form due to read data permissions.

Therefore, if you are only concerned about protecting your data and not too worried about protecting your user interface, you may find that the instructions thus far are sufficient for your database. Either way, you should read on because the discussions on shortcut files and PID authentication will make you more efficient and protect your data as well.




Real World Microsoft Access Database Protection and Security
Real World Microsoft Access Database Protection and Security
ISBN: 1590591267
EAN: 2147483647
Year: 2003
Pages: 176

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