Among the Issues Covered:
http://support.microsoft.com/support/access/content/secfaq.asp
http://support.microsoft.com/support/kb/articles/q165/0/09.asp
Message 1 in thread From: Terri Watson (defaultuser@domain.com) Subject: Removing Open/Run from Database container Newsgroups: microsoft.public.access.security Date: 1999/07/09
I am using user-level security in 97 with passwords. Users open a database via an icon on the Win95 desktop, containing the /wrkgrp switch. I want to keep everyone from opening a database by using another .MDW file, i.e. by opening the database file from Explorer. Microsoft's "Steps to Secure a Database" say to remove Open/Run permission from the User group, but when I do that, the Users cannot run the database even from the correct .MDW file (which makes sense to me!) I'm missing something here... So how do I keep clever "outsiders" out, without blocking access to legitimate users? TIA, Terri twatson@fhcrc.org
Message 2 in thread From: Steve Mazzola (steve_mazzola@my-deja.com) Subject: Re: Removing Open/Run from Database container Newsgroups: microsoft.public.access.security Date: 1999/07/10
You need to create a new group for your users, give this new group appropriate permissions to tables, forms, etc. and Open/Run to the Database object then join your users to the new group. I'm not sure where you are reading from but the following is an excellent resource...Microsoft Security FAQ http://support.microsoft.com/support/downloads/dp2719.asp Steve In article [37868A0A.1FFF0D7E@domain.com[, Terri Watson [defaultuser@domain.com[ wrote: [ I am using user-level security in 97 with passwords. Users open a [ database via an icon on the Win95 desktop, containing the /wrkgrp [ switch. I want to keep everyone from opening a database by using [ another .MDW file, i.e. by opening the database file from Explorer. [ Microsoft's "Steps to Secure a Database" say to remove Open/Run [ permission from the User group, but when I do that, the Users cannot run [ the database even from the correct .MDW file (which makes sense to me!) [ I'm missing something here... [ [ So how do I keep clever "outsiders" out, without blocking access to [ legitimate users? [ [ TIA, [ [ Terri [ twatson@fhcrc.org [
That is, in my database I had a group named "users," which is a default group Access sets up. I set up ANOTHER group named "users_2," and in THIS group Open/Run under the [database] parameter was CHECKED. In the default "user" group, it was UNCHECKED. I made sure my users were assigned to the "users_2" group AS WELL as "users."
For the users of your secure database to use the database, it must load with the proper workgroup file. Properly set up (as explained above), if the user loads your database under the standard "System" workgroup," it will not allow them to read the database at all. The user of that computer needs to have your workgroup file loaded, or "joined." The user could always do this manually using the "C:\WINNT\system32\WRKGADM.EXE" file, but it makes much more sense to have the specific workgroup file load with the database, ask for the login, and then have the computer return to the prior/correct default "SYSTEM" workgroup file. Here is some sample syntax for doing this:
"C:\Program Files\Microsoft Office\Office\msaccess.exe" "H:\SHARED EVERYONE\larryharrisonjr\databases\milestones_secure.mdb" /wrkgrp "H:\SHARED EVERYONE\larryharrisonjr\databases\SYSTEM_LARRY.MDW"The 1st portion covers the path to the Access program. The 2nd portion covers the path to the database. The 3rd path covers the path to the workgroup file.
Another option: you can autologin a person's user name/password, particularly handy to design for YOU, the designer, to save time. These command-line switches would go just BEFORE the workgroup switch. A sample (just the user/password portion):
/user "cmcnamar" /pwd "gerald"If you set up your secure database properly and then attempt to convert it to an MDE file, you may occasionally get the message:
Record(s) can't be read; no read permissions on 'MsysModules2'
If you get this message, then go to the following Microsoft Knowledge Base Article (article ID:Q170696) http://support.microsoft.com/support/kb/articles/q170/6/96.asp
You can also go to my local copy.
I came across this error when I loaded the front end & back end tables on a networked drive which has various read/write permission via Windows NT 4.0 I had permission to write to the directory, and others had the permission to read/write to the back-end data tables, but it wasn't letting more than 1 person in at the time. When I tried to run it at the same time, it gave the error message "file already in use" (the TABLES) file. I don't currently have a fix for this, so I included in here several newsgroup postings about this which I found.
Also, here is a link to the question in Microsoft's Knowledge Base
To view this thread, search comp.databases.ms-access for file already in use error dated May 12th 1999.
This issue is covered as topic #34 in Microsoft's very helpful Security FAQs. However, two things which the Security FAQs fail to mention is that, once you have de-secured a database, you need to import all the objects into another blank database. Until you do this, the de-secured database won't run free of workgroup files as you wish for it to. It also fails to mention that, if you de-secure the database and the workgroup file that the database is joined to also is applicable to other databases, then de-securing the database will basically ruin the security features that the other databases related to the workgroup file. Therefore, in that case, you will want to make a copy the workgroup file and join that one instead of the regular one, to prevent ruining security features for the other databases.
Hereby, I will submit my own information (again, derived largely from #34 of the Microsoft FAQs) on how to de-secure a database: