Security in a Frontend/Baclend Environment 1

[JDRoss]

I am wondering if somebody could help with an understanding on security issues.

What is the correct procedure with security for a frontend pulling data from a backend databases? I know I have seen this discussed in other threads or a faq, I'd appreciate it if somebody could point me to something definitive.

Should you use the same Workgroup file for both?

Secondly, is it good working practice or a simple work-around if you need to have different users on a database to give users different Workgroup files to logon with?

Thirdly, ownership? In the hierarchy of things has ownership more permissions than Admins? When I change some permissions for a user, I notice they don't take effect. What could be happening?

How secure is your database using the MS Access Security

Much appreciated

John

 

[GDGarth]

I'll try to answer your questions:


Use the same workgroup for security of both front and back end databases.

Have everyone use the same workgroup file - it would be really hard to set it up using different workgroup (.mdw) files.

If your permission changes don't take effect, something's wrong. Check to see if you really have administrator permissions on the object. You may want to start all over and make sure you're setting it up properly.

From my experience, Access security, when properly set up, is reasonably secure. A hacker will always be able to get into it, I suppose, but most users won't have a chance. I've had a couple of I.T. people tell me they could crack my security "easily". I gave them a copy of the database and invited them to try, and they were unable to get in. Admittedly, they didn't try any advanced hacker tricks.

I think Access security is pretty good, and, once you've got it figured out, it's easy to implement. It's way more secure than anything you're likely to create on your own.

 

[JDRoss]

Thanks GDGarth, for a very straight forward explanation. I take your point on the Workgroup file and confidence in MS Access security. It is reassuring!

I think MS have tried to transfer their file sharing network security idea to Access. When I try to understand the security issue looking at it like this, it seems very logical. You have read/open/design/administer permissions etc, like you have read/write/execute/ etc. permissions in Windows NT or Linux.

My question is why can't the workgroup file be encrypted into the database? I know, MS ACCess wants the Workgroup file to be like a system login securing all and every database on the computer or network, but reading the discussions on this forum, this is not in fact how things are implemented in real life.

Just one question on your comment:

Check to see if you really have administrator permissions on the object.

How can I check this? If I have created the database do I automatically have Administrator permissions? In securing it, I gave the Admin logon a password, I relogged on with the Admin user and password. I created a new user joining the Admins group, but I don't seem to have the same permissions as Admin. I notice that I can 'change owner' on all the objects except the Database itself. This is some kind of major loophole in Access Security. Changing owner can lock you out.

I'm pretty sure I followed the steps exactly in the Developers Handbook but something seems to be missing. Only difference that I can see is that I implemented the security on another computer, not the one I created it on. Would this have any bearing?

Finally, I read somewhere that if your database is copied then loaded in to another computer without a secure workgroup file, that it opens. I have some reason to believe this is true. So the workgroup and the database must always be distributed together.

At the moment, all I am really confident about in the security side is the Database Password which prevents the code being viewed or altered. I wish also that Access would extend this very simple method for protecting other objects such as forms or queries, as an option.

As you can see, I am still at sea with a lot of the security issues of Access.

Appreciate your comments and help.

 

[GDGarth]

The easiest way to check if you have administrator permissions on a database or objects is to try to change the permissions. If you can, then you should be OK.

It sounds like you set up your security using "System.mdw" or a copy of it as your workgroup information file. If you do that, your database isn't really secure. You need to make a new .mdw file from scratch. If you do that, people can still open your database with System.mdw, but only if you've given permissions to the default "Admin" user (this is the default user, and this account should be removed from the "Admins" group).

Implementing security on another computer shouldn't have any effect on it, as long as you're joined to the proper .mdw file.



There's a security FAQ that should lay it out pretty well for you. The basic steps are:

1. Create a new workgroup using WRKGADM.EXE. Don't just make a copy of System.mdw.

2. Join the new workgroup.

3. Create a new user name for yourself, and set a password for your user name. Put your user name into the "Admins" group.

4. Remove the default "admin" user from the "Admins" group (leave them in the "users" group).

5. Open your database and run the User Level Security Wizard. This will make a secure copy of your database without changing the original.

6. Open the new, secure database, and set up your user and group accounts. If you don't want the default user to have access to your database, set up a new user group, and remove all permissions from the existing user group.

This is the condensed version of Access Security.

 

[JDRoss]

Thanks once again GDGarth for the explanation on security.

I see that my problem came at step 5 in your step-by-step.

When I tried to run the user level security wizard, Access gave me an error, so it may in fact have failed and has defaulted back to the system.mdw workgroup file, which would explain the anomolies.

Thanks for pointing out the logic on the admin logon, a bit like the 'guest' logon on a secure system that we are meant to remove for security reasons. I am beginning to put my faith in Ms once again, but I'll continue to try out some more of the concepts first.

Much appreciated, your time and help.

John