I have never used Access workgroup security and have a question. Will setting up security and/or a workgroup alter the individual database that I am currently working on, or will it alter the settings on the Access application, which will carry over into all databases, both past and future? Thanks.
Workgroup Secrurity Question
- Thread starter Lynn63
- Start date
- Local time
- Today, 00:08
- Joined
- Feb 28, 2001
- Messages
- 30,495
Workgroup security creates a new file (called an .mdw) with information in it about users who are permitted to open your DB. Security is always a tough concept. I'll try to give you some guidelines here.
Will setting up security and/or a workgroup alter the individual database that I am currently working on
That shouldn't happen if you do it right.
will it alter the settings on the Access application, which will carry over into all databases, both past and future?
That can happen for careless or uneducated users and can also happen if you yourself are careless in your setup of the workgroup file.
1. If you choose to go this way, make a new workgroup file with a name that matches the name of your database .mdb file (or that of your primary .mdb file if a split database is involved). Put the workgroup file in the same shared directory as the database file.
2. When you set up the workgroup, create accounts for each user but don't assign them any rights at all. Before you create the first user, set up a method to assign unique ID codes. If you have to rebuild a user account, knowing the ID codes you assigned makes this task easier. Clear each new password.
3. Create a series of groups that describe functional responsibilities. Assign access rights to the group names. This part will be tedious, but there is a payback to it. If you add a new user down the road, you will have a bunch of groups already defined for comparisons to see if that user fits the profile.
As to the groups...
i.e. DataClerk can enter data but not modify it or delete it.
Designer can create new database objects such as tables, queries, forms, etc. DBA can do anything. Auditor can see anything but can't change anything. etc. etc. TAKE SOME TIME TO DESIGN THE GROUPS. Bad design at this step will come back to haunt your dreams.
4. Make yourself and/or your designated assistant the DBA with all rights as described above.
5. Take away ALL RIGHTS from groups User and Admins (that 's' on the end is the group.) Make user Admin (with no 's' on the end) a member of the User and Admins group. You are doing this because if someone doesn't remember to join the workgroup correctly, they come in as ADMIN. You don't want them mucking about, so this step makes the ADMIN account useless. And the step creating DBA gives you the way to have an administrator who isn't a member of the Admins group - BEFORE you disenfranchise the Admins group.
6. Now assign each individual user to be a member of one or more of your groups. They will ALWAYS be members of the User group no matter what, so don't bother to revoke that membership. You can't. But the earlier step gutted the User group, too. So that membership is benign. Oh, by the way, you cannot remove Admins group membership from the Admins account.
7. Instruct your users on how to join a workgroup using the wrkgadm program in your Windows\System32 directory. Have them log in through the workgroup.
8. Instruct users that if they wish to open a different database, they will have to join either the workgroup specific to the new database or the system default workgroup that is ALSO located in the Windows\System32 directory. This will even apply to their own private db files.
9. Either absolutely never or darned near almost never assign access rights by username for new users. Instead, add your newbies to the group that fits their job description.
10. Read up on the Help topics related to Workgroup Security.
Will setting up security and/or a workgroup alter the individual database that I am currently working on
That shouldn't happen if you do it right.
will it alter the settings on the Access application, which will carry over into all databases, both past and future?
That can happen for careless or uneducated users and can also happen if you yourself are careless in your setup of the workgroup file.
1. If you choose to go this way, make a new workgroup file with a name that matches the name of your database .mdb file (or that of your primary .mdb file if a split database is involved). Put the workgroup file in the same shared directory as the database file.
2. When you set up the workgroup, create accounts for each user but don't assign them any rights at all. Before you create the first user, set up a method to assign unique ID codes. If you have to rebuild a user account, knowing the ID codes you assigned makes this task easier. Clear each new password.
3. Create a series of groups that describe functional responsibilities. Assign access rights to the group names. This part will be tedious, but there is a payback to it. If you add a new user down the road, you will have a bunch of groups already defined for comparisons to see if that user fits the profile.
As to the groups...
i.e. DataClerk can enter data but not modify it or delete it.
Designer can create new database objects such as tables, queries, forms, etc. DBA can do anything. Auditor can see anything but can't change anything. etc. etc. TAKE SOME TIME TO DESIGN THE GROUPS. Bad design at this step will come back to haunt your dreams.
4. Make yourself and/or your designated assistant the DBA with all rights as described above.
5. Take away ALL RIGHTS from groups User and Admins (that 's' on the end is the group.) Make user Admin (with no 's' on the end) a member of the User and Admins group. You are doing this because if someone doesn't remember to join the workgroup correctly, they come in as ADMIN. You don't want them mucking about, so this step makes the ADMIN account useless. And the step creating DBA gives you the way to have an administrator who isn't a member of the Admins group - BEFORE you disenfranchise the Admins group.
6. Now assign each individual user to be a member of one or more of your groups. They will ALWAYS be members of the User group no matter what, so don't bother to revoke that membership. You can't. But the earlier step gutted the User group, too. So that membership is benign. Oh, by the way, you cannot remove Admins group membership from the Admins account.
7. Instruct your users on how to join a workgroup using the wrkgadm program in your Windows\System32 directory. Have them log in through the workgroup.
8. Instruct users that if they wish to open a different database, they will have to join either the workgroup specific to the new database or the system default workgroup that is ALSO located in the Windows\System32 directory. This will even apply to their own private db files.
9. Either absolutely never or darned near almost never assign access rights by username for new users. Instead, add your newbies to the group that fits their job description.
10. Read up on the Help topics related to Workgroup Security.
Similar threads
