RE: User Level Security Malfunction

FOR FUTURE REFERENCE.

The 10 Commandments of Group Level Security

I - Don’t dismiss the Database Password.
Many of the secured databases I deal with only require a database password,
not the Group Level Security function. This is especially true of
stand-alone databases (only on one computer). Although the database password
function may seem tame, most of the time it’s all that’s required.
Don’t use the Database Password function AND Group Level Security. Select
one or the other.

II - Security is always on.
You can’t turn it off. Even on an “unsecured” database, there is one
default user in the security system. (see V)

III - Do not enter the deep waters of Access security without a guide.
Check the posts in this section, download the suggested articles and read
them until you understand them. Pay special attention to Users, User Groups
and Permissions; how to use them and how to create them. I still have to
refer to my guide for assistance each time I use User or Group Level Security.

IV - Turn off your computer.
Now that you have made the decision to proceed with Group Level security,
turn off your computer. Sit down with a paper and pencil. Figure out before
you start what your User Groups are going to be and what permissions you need
to assign to them. This is done by identifying the permissions people need
to do their jobs.
Examples:
The clerks enter or update data and only require permissions to use the
forms that let them do this. They don’t need permissions for anything else.
The president of the company on the other hand is given permissions to view
or print all forms and reports.
You must then decide the permissions to be given to everyone in between.
The company’s Accounting dept. needs permissions for receivable and payable
forms and reports but they don’t require permissions for the clerk’s forms.
Create your User Groups first. Assign permissions to each User Group based
on what the group does. You then create individual users and assign them to
the appropriate User Group.
Some User Groups may have a dozen Users, others my have only one.

V - The user “Admin” is everybody.
The person who decided to use that name should be severely chastised. When
you start security you will notice that the user Admin is already there.
First time around, most people think they’re OK because they assign
themselves as Admin based on the false impression that a user named Admin
must have special rights and permissions. Admin is only the “Default User”.
Admin has no special status unless you specifically assign it.
By the way, don’t confuse the user Admin with the User Group Admins (notice
the “s” in the User Group).

VI - Make a copy of your database and use that.
If you are like me, you will probably mess up the security at least once.
While you can undo or make corrections to your secured database, if its’
totally fouled up (which it will be the first few times you try Security),
it’s easier to just delete the database and start again on another copy.

VII - The Administrator
Create a database Administrator. The Administrator (most likely you) is
the ONLY person to whom you assign permissions for everything. The
Administrator is the only one you assign permissions to make programming
changes and changes to the designs of tables, queries, reports, macros and
modules. The Administrator is the only one you assign permission to move a
User to a new User Group, delete old Users, create new Users and to change
User Group permissions. The Administrator is the only one you assign
permission to upload new functions into the database.
How many people spend their entire career with the same company anymore?
When you leave the company you are currently with, it’s likely they will
still be using your database. Create a second Administrator. Place the User
Name and Password in a sealed envelope and leave it with your supervisor. If
the supervisor leaves the company, change the User Name and Password of your
“back door” and give the new information to the new supervisor. This will
avoid one of the most common Access Security questions which begins “I
inherited this secured database but I can’t make changes”.


VIII - Create a new .mdw file.
The .mdw file is where your all of your security settings (User Groups,
Permissions, User names and passwords) are stored. By default, they are
saved in System.mdw which is located in C:Windows/Settings of your computer.
If you store them there, the database is secured on your computer but not
on anyone else’s. Why? The System.mdw on my computer is not the same as the
one on your computer. My computer doesn’t have the security settings so I
can get right into the database with no password challenge. In addition, if
you save your security to System.mdw, all of your formerly unsecured
databases now demand a password and User Name before you can use them.
Create a new .mdw file (don’t name it System) which should be saved in the
same folder as your database. You must include this new .mdw file in the
path on the shortcut to the secured database when it’s opened. Anyone trying
to use the database will receive a password challenge.

IX - Make it fail.
Now that you’ve checked all the User Names and passwords to ensure they
work and they only have the permissions they need, run some tests. Come up
with the most obscure scenarios to make your security fail or be bypassed.
Be creative. Pretend you’re a spy trying to hack the CIA’s computers. When
you’re satisfied everything is covered, you’ve finished the job.

X - Never make changes to the original database.
One of the reasons we used a copy of the database to install security was
to leave an intact original or master copy which is kept in a secure area.
When changes are required, make them to a copy of your master. When
everything in the copy is working properly, make the copy your new master.
You’ll also have somewhere to go if you mess up your changes.
When backing up, you only need to copy the data that’s in the tables. All
the forms, queries, reports, macros etc. are already backed up in your master.

.

Relevant Pages

  • Re: Creating security for MS Access application
    ... I wanted to create user ids and grant permissions based on user ids. ... You've not properly secured your database if that's the case. ... of User Level Security before mucking around with it too much more. ... with instructions on how to properly secure a database without the Security Wizard: ...
    (microsoft.public.access.security)
  • Re: A note to add to ASPFAQ.com for database compacting
    ... I set the database directory permission to give full access to ... then checked "Allow inheritable permissions from parent to ... Thus your problem is that you have to high of security set ... > the files needed and also a compact & repair operation will not cause ...
    (microsoft.public.inetserver.asp.db)
  • Sorting out security
    ... MS Access security. ... created a new workgroup, added a password for the Admin role, added groups, ... user IDs and passwords for users and allocated permissions on the ... remote logins to a secured database. ...
    (microsoft.public.access.security)
  • RE: Security setup does not allow import of tables
    ... When you click on the menu option Tools> Security> User and Group ... Permissions at the bottom of the screen does it show you logged in as the ... | new system database that has a unique Name, Organization, ... In the User and Group Accounts dialog box, ...
    (microsoft.public.access.security)
  • Re: Access db accessibility (permissions??)
    ... if you have not then your computers are workgrouped, security becomes a bit ... password when you first login to your database. ... > folder and then delete it. ... So the permissions are RWED on that folder. ...
    (microsoft.public.access.security)