securing access to user forms

[Paul James]

I'm developing an Access 2002 application in a multi-user environment, and
I'd like to make certain forms available to some users, but not to others.
This isn't a high threat situation - it's on a WAN and I'm mainly trying to
keep people from using the wrong form.

I've never used security procedures like this before, but in my cursory
reading of the introductory material, I've seen it described as ranging from
labyrinthine to inscrutable. I'm not thrilled about embarking on such a
journey, so I'm trying to think up ways to accomplish my objectives without
having to deal with something that's likely to be painful. So I'd like to
avoid dealing with individual permissions on different objects, and I'm
thinking I can do the following:

- disable the shift key at startup
- hide the database window
- disable the F11 key from opening the database window
- disallow full menus
- capture the OS user name, and
- display the opening form of a specific navigational system at startup,
based on the OS user name so that I will, in effect, limit each user to the
forms available in their particular system.

I already know how to do each of the above items, thanks in no small part to
the wonderful people who contribute to these newsgroups (like Jeff Conrad,
Marsh Barton, Allen Browne, John Spencer, Albert Kallal, Tony Toews, Tom
Ellison, Van T. Dinh, and John Vinson).

My experience with Access, however, has been that often times when I cook up
a scheme to accomplish something, I can usually get it to work, but
afterwards when I talk with some real experts, they explain all the reasons
why I shouldn't have done that, and how I will rue the day I ever did
something like that in my application.

So my question is this: is what I've described above a feasible way to keep
my users in the forms that are intended for them?

Thanks in advance,

Paul

 

[Douglas J. Steele]

What you're describing won't be very secure. For example, any user who wants
will be able to import all of the objects from your database into a new one,
thereby bypassing your security.

You'd be much better off applying Access Security.

Read http://support.microsoft.com/support/access/content/secfaq.asp
thoroughly several times, and try on a copy of your database.

 

[Jeff Conrad]

Hi Paul,

As Doug has already pointed out, applying User Level Security (ULS) is definitely the way to go.
Virtually any type of "home-grown" security system cannot protect the data tables. Your code can
easily be protected by making an MDE file, but when you get right down to it, why would someone want
to break into your database? To get to the data, period. And the *best* way to protect data in
Access (Jet) tables is to use ULS. Even that is not fool proof, but it will keep out 99% of
everyone.

I would point out that I personally believe there are many occasions where making a home-grown
security system is just fine. You have to ask yourself two important questions:
What am I trying to protect?
Who am I trying to protect the data from?
If you have very low-tech users then ULS may be overkill. I have made my own home-grown security
systems before for our store locations since the data was nothing sensitive and the users were VERY
low-tech. However, as Doug pointed out, anyone can simply open Access, create a new database, and
link to your *secured* database!

Learning ULS takes time and it can be difficult the first couple of times. Practice on dummy
databases. Doug already gave you the link to the Security FAQ. Here are several other good resources
on the subject:

Jack Macdonald's Security Document:
http://www.geocities.com/jacksonmacd/AJMAccessSecurity.pdf

Lynn Trapp's Ten Security Steps:
http://www.ltcomputerdesigns.com/Security.htm

Joan Wild's Tips:
http://www.jmwild.com/security02.htm

Good luck with your project.

 

[Paul James]

Thank you, gentlemen. Looks like you've given me links to the information
I'll need to secure the database.

This is something I've avoided for some time, wishing it would go away, but
it seems best if I just forge ahead into it.

Thanks for your comments and the references.

Paul