Pearl Database Access User Level Security Administration

Transcription

1 Before You Begin These instructions presume your Pearl Access User Level Security is already set up. There are two standard groups in Access that cannot be deleted, Admins (to which the default user Admin belongs) and Users (to which EVERY user belongs). Remember: Your permissions are the sum of all rights for all groups to which you belong. o o Make permissions by groups, never by individual users. This makes security easier to administer as new users join the workgroup. Also, try to establish security ONLY on tables, because Pearl will automatically prevent forms and reports from opening if they use protected tables. Essential Skill: Know How to Open the User and Group Accounts Dialog Box 1) Access XP/2003: Go to the menu Tools, Security, User and Group Accounts 2) Access 2007: Go to the Database Tools tab of the Ribbon, go to the Users and Permissions command group and select the User and Group Accounts command 3) Access 2010: Go to the File tab of the Ribbon, go to the Users and Permissions command group and select the User and Group Accounts command Page 1 of 9

2 Why Users Get Disconnected from the Workgroup File Pearl users will become disconnected from Pearl.mdw any time they open an Access database and the Pearl.mdw file is not available. Common situations include: Opening and working on an off-line copy of Pearl at home over the weekend Change or reinstall Windows or Office software on the computer How to Reconnect a User to the Workgroup File 1) Press F11 to reveal the Navigation Pane. 2) Scroll down to the Macros 3) Find the macro Pearl WorkgroupAdministrator. Double-click on it. 4) Click Join, then Browse and then navigate to Pearl\System\Pearl.mdw. 5) Select Pearl.mdw and click Open. 6) Click OK. You should get a message that you have successfully joined the workgroup. How to Disconnect a User from the Pearl Workgroup 1) Every user is initially connected to the default System.MDW file. For a user who does not need to be connected to the Pearl security group, use the same process to connect the user back to the System.MDW file. 2) For each user, it will be in their \AppData\Roaming\Microsoft\Access\ folder. For example: C:\Users\administrator.ILARTS\AppData\Roaming\Microsoft\Access\System.MDW. Page 2 of 9

3 How to Clear a User Password CRITICAL: Never clear the user password for Admin. The Admin user must have a non-blank password in order for users connected to the secured workgroup to be prompted to logon. 1) Logon to Pearl as the SecurityManager 2) Open the User and Group Accounts dialog box 3) On the User tab, select the Name of the user from the drop list 4) Click Clear Password, then click OK and close How to Set or Change a User Password: 1) Logon to Pearl as the User (if you have cleared their password, leave the password field blank) 2) Open the User and Group Accounts Dialog Box 3) On the Change Logon Password tab, fill in the Old Password (if cleared, leave blank) 4) Fill in the New Password then enter it again in the Verify box 5) Click OK and close Page 3 of 9

4 How to Print the List of Users and Groups: 1) Open Pearl 2) Go to File Info Users and Permissions User and Group Accounts 3) In the bottom right, click on the "Print Users and Groups" button Page 4 of 9

5 How to Add/Delete Users or Groups: 1. Open Pearl and logon as SecurityManager when prompted for logon. Enter SecurityManager password. Notes: If you don't see the prompt to logon with a user name, proceed to step 2. If you don't know your SecurityManager password, contact Bromelkamp Company. 2. Confirm you are joined to the PEARL.MDW workgroup (instructions below work for Pearl 4.25 and later) Access XP/2003: Press F11 to unhide the Database Window. Then go to the menu Tools, Security, Workgroup Administrator Access 2007/2010: Press F11 to open the Navigation Pane. Then scroll down to Macros and double-click on Pearl WorkgroupAdministrator Note: If you are not connected to the PEARL.MDW file in the System subfolder of your main Pearl folder, click Join, Browse to that location, then OK and click OK again. Access will restart go back to Step Open the User and Group Accounts dialog box. 4. From the Users tab, (User>New) add the names of the each User who will have special security (or each User you want to logon to Pearl with a password). You will need to assign random ID numbers to these users, assign any unique 8-10 digit number (each User must have a different number).tip: use date and time. 5. Once the users have been added, assign them to the group(s) to which they need to belong. By default each user is a part of the group Users. 6. Each User who has been added to User and Group Accounts needs to join the PEARL.MDW workgroup on their workstation if they haven t already (see Note to Step 2). 7. Restart Access and Pearl. Any user attached to the Pearl.MDW is asked to provide a logon and password when they open Access. They will be required to logon each time they enter Access. All others can stay members of the SYSTEM.MDW. They will not be required to enter a logon name. Page 5 of 9

6 How to Set Up Permissions for Objects 1. Open the Pearl Permissions table to edit which rights should be assigned to which groups. 2. Once you're done editing the table, go back to the Navigator, go to Utilities, Prepare Objects for Pearl and choose <prepare permissions>. 3. When the PreparePermissions function has been run, Pearl automatically updates the Pearl Permissions table to reflect the permissions assigned to each group. WARNING: A Pearl Update often edits properties of tables and forms; you will need to logon as SecurityManager in order to have full ability to install the update. WARNING: If you create a new.mdb file and import all the objects from Pearl.mdb, they will not include their previous User and Group permissions. Remember this if you copy objects from one.mdb to another. WARNING: If the database owner is not changed from the default Admin to the Pearl SecurityManager, the database may be vulnerable to access from unauthorized persons. For assistance changing the database owner, contact Bromelkamp Company. By default, Pearl assigns the following rights: Note: As you see in the example below, wildcards such as *,?, and # are available: * matches any number or characters # matches any single numeric character? matches any single alphabetic character Group Name Object Name Object Type Read Data Update Data Insert Data Delete Data Modify Design Explanation Users Query * Pearl added this, you can only change ModifyDesign. (To restrict data, put restrictions on tables not queries.) Users Query <new> Pearl added this, you can only change ModifyDesign. (To restrict data, put restrictions on tables not queries.) Users Query Qry* Pearl added this, you can change it. (To restrict data, put restrictions on tables not queries.) Users Report <new> Pearl added this, you can change it Users Table Pearl Settings Pearl always protects this object this way. Changes made here will be ignored. Page 6 of 9

7 Translation of table: Anyone belonging to the Users groups has the following permissions when in Pearl: o ALL (*) existing queries except those with names that start qry all rights (read, change, add, delete, modify design) o New (<new>) queries that are created in the session - all rights (read, change, add, delete, modify design) o Existing queries with names that start qry (qry*) read, change, add, delete but NOT modify design o New (<new>) reports that are created in the session read and modify design rights (the other rights are not relevant to reports). o The table called Pearl Settings read, change, add, delete but NOT modify design You may have noticed that read design (which is a permission option in Access) is not a column in the table Pearl Permissions. That s because our assumption is there s no reason to NOT give anyone read design permission. Also, the permission administer is not a column, because our assumption is that NO ONE except SecurityManager should have administer rights. For any object (table, query, form, report) or any group not mentioned in the Pearl Settings table, ReadData only rights are assigned. For example, in the default Pearl Permissions setup, the Users group will only be able to read the data in Clist, Contacts, Grants Management, etc. If you have a Grants group set up, they will have read-only rights to these same objects until/unless you add more rights for the group. In a standard Pearl Permissions set up, the most restricted group is the Users group. In this setup, anyone can read data, but you d only assign change, add, delete rights to other groups. Individuals who will have these most restricted rights do not have to join the Pearl.mdw. Access design specifies that anyone going into a secured database that is not part of the assigned MDW file, will belong to two standard groups Admins and Users. That means these users will have the standard USERS group rights as assigned in Pearl. (The Admins group which isn t normally mentioned in the Pearl Permissions table will be set to read-only rights.) Again, the default for any object is read-only, so if everyone SHOULD be able to change reports, queries, etc., give the Users group those rights in this table (EVERY user is a member of Users group). If ANY user needs to be ruled out of even seeing data (read data permission), then you have to reduce both the Users group and add and reduce the Admins group permissions to remove read data permission. Then add back rights to another group for those who can see the data. Normally you will set the Admins groups rights to be the same as the Users group rights. Page 7 of 9

8 Following is an example of a Pearl Permissions table that does not let the Users or Admins groups read data from the accounting tables (LedgerXX and General Journal including associated subtables notice the use of the * and # wildcard characters). Nor can these groups run existing reports or create new ones. GroupNam ObjectTyp ObjectName ReadD UpdateDat InsertDat DeleteDat ModifyDesig Explanation admins report * admins report <new> Admins admins table table General *Ledger##* Add to restrict Users query * Pearl added this, Users query <new> Pearl added this, Users query qry* Pearl added this, Users report * Users report <new> Pearl added this, *General Grants table *Ledger##* Users table Pearl Settings Pearl always protects this object When you re restricting the Users group rights, remember this group MUST have at least read-only this rights way. Changes to the Pearl License table and read, change, add and delete rights to the Pearl Settings table in order for made them here to open will be Pearl at all. ignored. Page 8 of 9

9 Following is a typical Pearl Permissions table, including several groups with varying rights. GroupName ObjectType ObjectName ReadData Up Inser DeleteDat ModifyDesign Explanation Contacts table CLIST Contacts table CONTACTS Donors table Donor Donors table General Journal Donors table Gifts Donors table Subtable general journal* Donors table Subtable Gifts* Grants table General Journal Grants table Requests grants table Subtable General Journal* Grants table Subtable Requests* Posting table Budget## Posting table General Journal Posting table Ledger## Posting table Subtable General Journal* Posting table Subtable* Payments Users query * Pearl added Users query <new> this, Pearl you added can Users query qry* only this, Pearl you change added can Users report <new> ModifyDesig change this, Pearl you added it. can Users table *Chronicle* n. New change this, (To you Tables it. can Users table Pearl Settings restrict get (To change Pearl the restrict always it. same data, protects put rights this In this case, anyone who is a part of either the Grants, Donor or Posting Group should also be part of the as restrictions object new this Contacts group and all should be part of the Users group. queries. on way. tables not Changes By default, the Users group has read rights to all tables. They ve been given change, add and delete rights queries.) made to any here Chronicle table. will be ignored. The Contacts group has been given the additional rights to add, change and delete data in the Contacts and Clist tables. The Donors group has been given permissions to add, change and delete data in the Donor table, the Gifts table and any Gifts subtable. They ve also been given insert rights to the General Journal and Subtable General Journal* tables. This is required if the fiscal transfer is being used. They are automatically given Read rights to the General Journal tables as well. The Grants group has been given permissions to add, change and delete data in the Requests table and any Requests subtable. They ve also been given insert rights to the General Journal and Subtable General Journal* tables. This is required if the fiscal transfer is being used. They are automatically given Read rights to the General Journal tables as well. The Posting Group has been given the rights to the Budget tables, the General Journal tables and to the Ledger tables. Additionally they ve been given rights to any Payment subtables. This is required if the fiscal transfer is being used. Page 9 of 9