Re: Multi user enviroment - part II
- From: enochsnorton@xxxxxxxxx
- Date: Tue, 15 Jan 2008 10:13:44 -0800 (PST)
On Dec 10 2007, 10:33 am, Fester Bestertester <whatmewo...@xxxxxxx>
wrote:
Keith Wilby wrote:
Are you really the same poster as the one who posted security advice in
the "Thinking about going multiuser with user security,..." thread?
I deeply appreciate all the technical feedback actually answering my
question. Since it's now so obvious that I'm an incompetent fool who
shouldn't be anywhere near a computer, let's review.
Let's say for the sake of discussion that I have a multi-user database
that's split between a back end (data only) and a front end
(application). The back end resides on a server and the front end is on
the user's machine.
Let's further say for the sake of discussion that I've already added and
tested a set of modules triggered by an AutoExec macro that verifies
that the link from front to back is valid, and, if not, raises a File |
Open dialog that allows the user (or a sysadmin) to point the front end
to the correct path if necessary.
Now let's suppose that I want security which is specific to that
application only, and does not affect any other instances of Access on
the local machine, even though, in that same thread, "Thinking about
going multiuser with user security..." one "Lyle Fairfield" posted,
"Many developers do almost none of the above, with the exception of
splitting their applications. I am one of them."
To accomplish this, I would perform the following steps:
1. Open an empty session of Access.
2. Select Tools | Security | Workgroup Administrator...
3. Select Create...
4. Give the new security file an ID, note the User, Organization, and ID
information, and click OK.
5. Browse to the appropriate location where I wish to store the mdw file
and name the file, i.e., MyApp.mdw.
6. Select Tools | Security | Workgroup Administrator, select Join, and
navigate to the new mdw file.
7. Select Tools | Security | User and Group Accounts, and create the
users and groups I wish to have.
8. Select Tools | Security | User and Group Permissions, and configure
the permissions for the groups.
9. Select Tools | Security | Workgroup Administrator, select Join, and
re-join the default System.mdw file.
10. For distribution, copy the backend database file to a shared
directory, copy the front end application file to the user's machine,
and copy the security file to a shared directory.
11. At this point, according to MSKB article 305542, "Understanding the
role of workgroup information files in Access security":
"To associate specific secured database files with their workgroup
information files, you must create desktop shortcuts. Each desktop
shortcut must have the Command-Line option set to start a specific
database and use the specific workgroup information file secured with
that database.
"To start a secured Access database named MyApp.mdb in a folder named
MyAppFolder with the workgroup information file used when establishing
security on MyApp.mdb, the command-line syntax must include the /WrkGrp
command-line switch, for example:
"C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
"C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\System.MDW"
"You can create a shortcut and enter this syntax as the target of the
shortcut."
12. The result is that there is now security which is specific to this
particular application and does not affect other sessions of Access on
the user's machine.
The user can still run Access, with the default System.mdw, file to open
or create mdb files, but if the user double clicks the desktop shortcut
to the "MyApp.MDB" application, they will get a password prompt using
the security file that is specific to that application.
Unfortunately, this security does not apply if the user opens an empty
session of Access, or opens Windows Explorer, and navigates directly to
the MyApp.mdb file. So it appears that the only way to defeat this would
be to turn off Windows Explorer and/or remove all Access-related icons
from the desktop except the shortcut to MyApp.mdb.
Or, is there something unrelated to desktop lockdown, and specific to
Access security, that I'm missing? It's already been effectively pointed
out that I'm incompetent, so what, exactly, was so obvious about Access
security that anyone should have been able to see it?
I had the same problem securing my database. The work-around that I
used to prevent unauthorized access to the original database was to
remove permissions for the admin user, the default user for any access
database, in the database I secured and linked the private
Security.MDW to.
I then inserted a little chunk of code that executes on startup that
checks the username. If the username is "admin", the code displays a
message telling the user that they must open the database using the
designated shortcut. The code then closes the database.
This method has worked for me. It's not pretty but it works.
-- Enoch Norton
.
- Follow-Ups:
- Re: Multi user enviroment - part II
- From: Dominic Vella
- Re: Multi user enviroment - part II
- Prev by Date: emails para mala direta segmentada por sexo
- Next by Date: Help with pay
- Previous by thread: emails para mala direta segmentada por sexo
- Next by thread: Re: Multi user enviroment - part II
- Index(es):
Relevant Pages
|
