Re: Sorting out security
- From: "Lynn Trapp" <ltrapp_NOSPAM@xxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 11 May 2005 11:42:36 -0500
Charles,
First of all, have you read the Security FAQ? If not, you need to do so.
There is a link to it on the Security page of my website.
See my other comments inline below.
--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html
"Charles Hudson" <clh333@xxxxxxxxxxx@JoiMail.com> wrote in message
news:e3j67PkVFHA.3076@xxxxxxxxxxxxxxxxxxxxxxx
> Please pardon yet another post on the subject of Access and user-level
> security. I am inexperienced and greatly appreciate any help I can
> receive. I would like to ask a question about the internal organization
> of MS Access (or, perhaps, Jet) security.
>
> I am developing an application which will give multiple users access to
> various tables and forms, and with various permissions for reading,
> entering, updating and deleting data. Eventually this will be deployed on
> the Internet. I have read and experiemented and thus far have
> successfully created a new workgroup, added a password for the Admin
> role, added groups, users, user IDs and passwords for users and allocated
> permissions on the database objects. I have demonstrated that these
> "roles", to borrow an Oracle term, are restricted as intended. Some
> questions remain about andministering multiple users, multiple System.mdw
> files ("workgroups") and remote logins to a secured database.
Did you use the Security Wizard to do this or did you do it manually? You
should always name the .mdw file you use for securing your databases
something other than System.mdw. That is the default that is created when
you install Access. You will be happier with life if you always have a
different name for the secure workgroup file.
>
> As I understand matters, the Microsoft Jet engine enforces Access security
> rules, and security is always enforced when Jet runs, according to the
> settings it reads.
Yes, this is true. If the Admin user has no password then every user is
logged in "silently" as Admin.
[snip]
>
> In order to secure the database it is necessary to at least create a
> database password. Doing so will create a prompt for any (anonymous) user
> to gain access to the database, but once admitted, they are once again
> all-powerful Admin.
NO, NO, a thousand times NO. Do NOT create a database password. It is next
to useless. Hackers can crack it in just a few seconds, if not quicker.
> In order to differentiate powers, as it were, it is necessary to define
> "user-level security", which means, at a minimum, creating a password for
> the Admin. Once Admin has a password created for their account, the
> database can no longer be accessed without specifying a "user name" and
> password, if any, both. In the previous case we assume no database
> password has been created. I don't know what would happen if both a
> database password and user-level security were enforced, or if they can be
> at the same time.
If you give Admin a password AND create a database password, you will be
prompted for both the database password AND the user name/password
combination.
>
> The Admin can create other users and groups, and add users to groups. If
> a user has been created, the Admin can also create a password for them, or
> can leave this field blank.
Except through VBA, the Admin user cannot create a password for users but
can clear a user's password. However, if you secure your database properly,
you should remove the Admin user from the Admins group and remove all
permissions to all objects for the Users Group so that Admin has no ability
to do anything. This is how you prevent unauthorized entry to the database.
[snip]
>
> Permissions are attached to the object itself, say my references.
That depends on what you mean, but the permissions for given objects are
stored in the database file.
> I take this to mean that if a table were imported into another database
> (by linking or by copying, does it make a difference?) then the
> permissions would accompany it.
If you link to a table that has been secured, then the permissions on that
table will adhere, if that's what you mean.
> In practice, does this mean that a database that was unsecured now
> requires a logon?
The logon requirement is based purely on the presence or absence of an Admin
user password. If the Admin user of the .mdw file has a password then a
logon prompt will appear.
>
> A workgroup is a collection of users, objects, groups, permissions, and
> passwords, it seems. It is represented by a file with .mdw as its
> extension. Is a workgroup file associated with Access itself, with Jet,
> or with a database?
A workgroup file is, itself, a Jet database.
> Does Access keep track of where this file is, internally with some
> pointer? Is it a Registry key? Does Access read this file each time it
> starts up, or only when it opens an associated database - in other words,
> is the pointer to the security .mdw file stored in the database itself?
The specific workgroup file being used is based on each session and it
depends on how you open the database. If you open the database by double
clicking on it from Windows explorer, then it will use the workgroup file
that the computer (it is a by machine situation) is joined to. If, however,
you create a shortcut (as recommended in the Security FAQ) with the /wrkgrp
switch, then that workgroup will be used for as long as that session of
Access remains open. The general syntax for creating such a shortcut is:
"FullPathToMSAccess.exe" "FullPathToDatabase.mdb" /wrkgrp
"FullPathToSecure.mdw"
>
> And what about the Jet engine? I created a secured database that required
> user names and password access, then stored it in a webroot folder and
> created ASP pages to query and post to the database. Despite being
> password protected, no username or password was provided in the ADODB
> connection string, yet the information was returned to my browser from a
> query. it's possible that I received the contents of a browser cache
> instead of a database hit, I realize now, but I don't think that's what
> happened.
I can't give you any advice here
>
> If it is possible to have more than one workgroup, there must be more than
> one .mdw file. Some references suggest making a backup of System.mdw and
> renaming it something other than System.mdw. How does Access know that
> you have done this? How does one switch between multiple .mdws, as one
> post suggested earlier? The workgroup administrator offers the option of
> creating a new workgroup or joining an existing one. Who or what is it
> that "joins" a workgroup: the Access application, the current database or
> the user?
The COMPUTER you are using is what joins the workgroup.
>
> In order for the .mdw file to be read by others on a network, it has to be
> in a shared folder, say my references. If my database were in a shared
> folder but my system.mdw folder were not, could others open the database
> in question? If they were using a copy of Access on their own machine,
> would they reference their local System.mdw file containing different
> settings, and perhaps over-ride security?
If you properly secure your database, they should only be able to open it by
using (either via a shortcut or by joining) the workgroup file that you used
to secure the database.
>
.
- Follow-Ups:
- Re: Sorting out security
- From: Joan Wild
- Re: Sorting out security
- References:
- Sorting out security
- From: Charles Hudson
- Sorting out security
- Prev by Date: Re: Can median be calculated in Accesss?
- Next by Date: Re: Workgroup File
- Previous by thread: Sorting out security
- Next by thread: Re: Sorting out security
- Index(es):
Relevant Pages
|
