Access2000: Securing a specific existing database

[Arvi Laanemets]

Hi

Some years ago I secured a Access97 database, but until now was there no
need for this anymore. I tried to search, but I did find only MS KB comments
about this. And it looks like following those guidelines, I protect all my
access projects, not a particular project only.

In my earlier secured project, as much as I remember, I created a special
Workgroup Information File (MyProject.mdw), and set all security settings
there. After that, the original system.mdw was restored.

Project MyProject.mdb was distributed together with MyProject.mdw, and with
a shortcut. Shortcut started application with it's Workgroup Information
File as parameter.

There was no way to start project without it's Workgoup Information File,
and it didn't start with wrong one either. At same time, the user could open
his other Acess databases as usually (using system.mdw as default Workgroup
Information File).


Where can I find a guide for securing like this for Access2000?


Thanks in advance!

 

[Arvin Meyer [MVP]]

The process is essentially the same. You can get the "latest" information in
the Security FAQ:

http://support.microsoft.com/support/access/content/secfaq.asp
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access

 

[Arvi Laanemets]

Thanks!

I have another question: In part "1. What are the steps to help protect a
database?" I read "... Note that the Access 2000 security wizard does not
create a new database-it simply creates a backup copy of the original. One
flaw with this arrangement is that not all permissions to open the database
are removed from the Admin user and Users group to open the database, even
though they appear to have been removed. "

I remember someone here at my work tried to secure Acess2000 database
following this guide, and all was OK, except that any user who opened the
project without declaring mdw-file, did open it as admin, i.e as Admin from
System.mdw. Can this be the flaw, above is talked about? Or messed he there
something up? He asked for my help, and I remember I posted a question about
it here, but finaly he simply put the project on network unprotected.


--
Arvi Laanemets
( My real mail address: arvi.laanemets<at>tarkon.ee )

 

[Joan Wild]

For 2000, you should not use the wizard, for that very reason. Instead
secure it manually. There isn't anything the wizard does, that you can't do
yourself.

Some step by step instructions:
http://www.jmwild.com/security97.htm

 

[Arvi Laanemets]

Thanks! An excellent link!

Sorry, but another question - too excellent source to waste it )). I'm
almost sure that the answer will be negative, but is there a way to create a
group, member(s) of which can create new non-admin users (or users in
specified groups), but can't change anything for users with administrator
rights, And, of-course, which can't open the project in design view too
(holding Shift key down).

Such an user would be useful, when I do not want any user to dabble in
tables or in form design's etc., but in same time I don't want, that every
time some new user needes access to database, I have to travel there to
create an user account.

When this is not possible, maybe I create an administrators user with full
rights, and another user with common user rights, where for common user is
no password set (or has a fixed password). When different rights are needed,
I'll use different front-ends. Access to database can be limited by network
administering (only limited number of users have access to network resource
with database). Are there any hidden riffs or drawbacks with such setup?


Arvi Laanemets

 

[Joan Wild]

Sorry, but another question - too excellent source to waste it )).
I'm almost sure that the answer will be negative, but is there a way
to create a group, member(s) of which can create new non-admin users
(or users in specified groups), but can't change anything for users
with administrator rights, And, of-course, which can't open the
project in design view too (holding Shift key down).

Sure, the key is to distribute a different mdw in production, than the one
you used to secure it with for development purposes.

A member of the Admins Group can add/delete users. But since the mdw you
put into production is not the same as the one you used to secure it with,
the Admins Group is different, and therefore does not have the same
permissions as the Admins Group in the development mdw.

You secure it using the development mdw. Assign permissions only to groups.
When you're done, you create a new mdw for production (different name and
WID), and then create the same groups that you have in the development mdw
(ensuring that you use the exact same names/PIDs). The person you make a
member of the Admins Group in the production mdw will be able to add/delete
users, but nothing else.

More details in the security FAQ; section 33
http://support.microsoft.com/?id=207793