Question User Level Security

LadyDi

Registered User.
Local time
Today, 09:21
Joined
Mar 29, 2007
Messages
894
I am trying to protect the structure of a database by using the User Level Security Wizard. I set myself up as the Admin and tried to set up others as "Full Data Users" using their usernames for their computers. The database lets me in without a problem, but it won't let any of the people I set up as "Full Data Users" in. They get an error message stating that they do not have premissions. Do you have any idea why it won't let them in? Is there a better way to protect the structure of the database?
 
Please read the following. You will probably find your error(s) there.

The 10 Commandments of Group/User Level Security

I - Don’t dismiss the Database Password.
Many databases only require a database password, not the Group or User Level Security function. This is especially true of stand-alone databases (only on one computer). Although the database password function may seem tame, many times it’s all that’s required.
While you may use both the Database Password function AND Group Level Security, you should really select one or the other. The two functions (Database Password and Group Level Security) are separate and distinct from one another. By using both, you are not adding to security, you are merely introducing a redundant step.

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.
Almost everything in Access can be learned by trial and error EXCEPT SECURITY.
Check the posts on security, then 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 or User 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. This will avoid having to assign individual permissions to every user.

Some User Groups may have a dozen Users, others my have only one.

V - The User “Admin” is no one and everyone.
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”.
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.
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. Don’t forget to delete your .mdw file as well (see IX).

VII - The Owner
When you create a database, Access assigns an owner. The owner is the person who was logged on at the time the database was created. As “Admin” is the default User (See V) “Admin” is normally the database owner.
Regardless of what restrictions you may subsequently place on “Admin”, “Admin” can’t be restricted – after all, he owns the database.
The Final Step in Group Level Security is to make your User name the owner and to delete “Admin”.

VIII – The Administrator
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 an Administrator who has permissions for everything. 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 any changes”.

IX - Create a new .mdw file.
Security settings are saved in a Workgroup file which has the extension .mdw The default is System.mdw which is usually located in C:Windows/Settings of your computer.
Each secured database should have its own .mdw file which should be saved in the same folder as the database. When creating it, give it a name other than System.mdw as this may cause problems down the line.
You must include this new .mdw file in the path on the shortcut to the secured database. Anyone trying to open the database will receive a password challenge.

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. This way you’ll always have somewhere to go if a disaster occurs.
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.
 
Statsman, pretty good, but you left out something that I have found to be a key point a couple of times, never did find out WHY it was important. But it was.

When you create a new and separate workgroup file for the DB, you make your own account a member of the Admins group, which is special and cannot be deleted. You make the Users group "brain dead" and assign rights to groups of your own naming.

Now log out of the DB. Log back in. NOW move the Admin user (no "s") to the Users group. The logout forces all pending buffers to be written. You NEVER EVER disable the admin user until you have another admins-group user. And I found it is best to do that step in a second DB session after closing the first one.

About changing ownership? Spot on.
About not using the default workgroup file? Spot on.
About making a master copy that never gets overwritten while mucking about? Spot on.

You glossed over something, but the teacher still lurking inside of me says to emphasize a point. I used to teach Windows Security topics to new systems administators for the DoN at my home site. This is one that we were ourselves taught to pound into our students because it makes your life so much easier in the long run.

NO USER HAS RIGHTS. EVER. However, users can and should be members of groups that have rights. This is actually the Microsoft paradigm for a LOT of products including Windows itself. You get your rights through group membership. NOT through your own account. Even your new "Admins" account should never have rights directly associated to it. Derive all rights from groups.

Your safety net is that you can't make a group the owner of a database, a person has to have that honor. The reason this is a safety net is the old MS rule that says this: The owner of some object has the right to change the security settings of that object regardless of what rights appear in their permissions list.
 
I was actually aware of most of your points. I didn't want to post a message that took up a entire page.

The missing parts are covered in commandment III, your Guide.

I personally prefer to delete the User "Admin" completely as it makes security airtight.
 
You should not delete Admin entirely for one simple reason. It is what is called a "honey pot" account. I.e. it attracts attention because it LOOKS like an easy place to get the goods on the database. But you end up getting stuck in the honey pot, which turns out to be a honey PIT. (You have to be ex-military to know what a honey PIT is, and I'm too polite to say it in open forum.)

Remember that a "virgin" workgroup file defines you as Admin. By having user Admin exist but only as a brain-dead entity, you trap the people who failed to use the right workgroup file. And you do it in a not-so-obvious way because it LOOKS like it worked. But you can't do anything with it.

Also, you can get rid of Admin user in that database, but that ID is still available on every system precisely because it is bound to the default user for workgroups. You can never get rid of that factor. This is a philosophical preference, but the Dept. of the Navy says TRAP the dangerous accounts, don't delete them. It distracts the hackers.
 
I followed the directions the two of you provided. However, I am still having trouble. I have the .mdw file in the same folder as the .mdb file, and the folder is on a network drive. However, the other users are still locked out. I figure they are still being recognized as Admin, but I can't seem to get rid of that, or make it "brain dead". What do I need to do?
 
I agree with Banana. It's the guide I use.
 
You should not delete Admin entirely for one simple reason. It is what is called a "honey pot" account. I.e. it attracts attention because it LOOKS like an easy place to get the goods on the database. But you end up getting stuck in the honey pot, which turns out to be a honey PIT. (You have to be ex-military to know what a honey PIT is, and I'm too polite to say it in open forum.)

Remember that a "virgin" workgroup file defines you as Admin. By having user Admin exist but only as a brain-dead entity, you trap the people who failed to use the right workgroup file. And you do it in a not-so-obvious way because it LOOKS like it worked. But you can't do anything with it.

Also, you can get rid of Admin user in that database, but that ID is still available on every system precisely because it is bound to the default user for workgroups. You can never get rid of that factor. This is a philosophical preference, but the Dept. of the Navy says TRAP the dangerous accounts, don't delete them. It distracts the hackers.

I had never looked at it like that before. You make a good point.

Whats the old saying...

Just because I'm paranoid doesn't mean they aren't out to get me.:D
 
This was a great thread! Thanks. However, the link for the popular guide is no longer working. Can anyone provide a good link? Thanks!
 

Users who are viewing this thread

Back
Top Bottom