Re: More security questions


"Joan Wild" <jwild@xxxxxxxxxxxxxxxx> wrote in message
news:u87aXd8EHHA.3616@xxxxxxxxxxxxxxxxxxxxxxx
BruceM wrote:
"Joan Wild" <jwild@xxxxxxxxxxxxxxxx> wrote in message
news:OHLy45zEHHA.4464@xxxxxxxxxxxxxxxxxxxxxxx

There is no 'default' PID; also I don't understand why you'd give
everyone the same password.

Is there any value to using something other than the automatically
generated PID?

No that's fine. I didn't realize you were using the wizard. If you want
to add users later, you'd do so via Tools, security, accounts, and there
you have to come up with your own PID.

The trouble is that a number of computers are shared. On those
computers there may need to be a user-specific shortcut. Without it
people would double click the shortcut, add their passwords
(regardless of the user name), and then complain that the database
doesn't work. It will not occur to them to check the user name.

I would use /user "" in the shortcut instead - that'll pop up the login
with no username filled in and force them to enter one - then you only
need a single shortcut for all.

Cool!


You say that I can check that the password isn't blank, but the only
way I can figure out how to do that is to log on as that user. Is
there another way of doing that? Regarding giving the user a form,
I'm not sure what you mean by that. Are you talking about having
them tell me the password so that I can enter it for them, or are you
talking about an Access form, or something else?

I'm talking about using an Access form to change passwords, and using code
to determine if their password is blank.

You'd create an unbound form with three textboxes and a command button.
The three textboxes are for the user to enter their username (or have it
default to CurrentUser()), their old password, and their new password
(maybe even another textbox to confirm the new password). There is sample
code in the security FAQ for how to change a password.

Thanks for pointing that out. I think I found it in the part about clearing
the password.


As for checking if it's blank, you can do this in on startup (in your main
form, or have a hidden form that opens at startup and checks this. You
could attempt to open a DAO workspace in code using the CurrentUser() for
the username, and a blank password.

If the password is wrong (i.e. they have a password set), you can trap the
error.

If you get no error then you'll know it is blank, and can throw up a nice
message, and then open your change password form.

Dim ws as Workspace
Set ws = DBEngine.CreateWorkspace("tempws", CurrentUser(),"")
If Err=0 then
'they have a blank password
'open a change password form
DoCmd.OpenForm "frmChangePassword"
Else
'they don't have a blank password
'do nothing
End If

Thanks for providing the code example and the sketch of the form I would
use. Again, more study is needed, but I think I can figure it out. A lot
of new information has been added to my brain in the past few days, and it's
taking a while to incorporate it all.


Since I will also be
using the database, it may be necessary to set up an administrator
who can only administer accounts, but not work directly with data.

That is also covered in the security FAQ. You'd need to create a second
mdw for production, while keeping your first secure mdw for development.
Look in the FAQ.

I saw something about that in Jack MacDonald's article as well. I'll need
to study that some more. I think I understand that only members of the
Admins group may manage user accounts. Permissions are stored in the
database (mdb) file, so when Workgroup File 1 has the same user and group
information as Workgroup File 2, the database will "think" that it is the
same group of users, and all permissions will continue to apply. The
difference is that Workgroup File 2 does not have I still need to mull this
over for a while, but as I will be administering security at first (for
databases in which security is not that big an issue) I don't need to worry
about it right away.
By the way, creating duplicate users and groups seems like a good reason not
to use the PIDs generated by the wizard.


I will try again to comprehend the MS FAQ. I must say it is really
too bad that such important information has not been updated in over
six years. I'm not sure how much to believe (for instance, it is
among the very few documents I have read that mention without any
caveats using a database password), but in any case there is a
discussion of RWOP queries which should be of value now that I know a
little more about how the security works.

I've also got some info at www.jmwild.com/RWOP.htm

Thanks for that link, and for the referring me back to the FAQ. One of the
problems with the FAQ is that there are parts I clearly can skip (about
Access 2.0, for instance), but sometimes I skip too far. This is another
concept I expect I will understand in time. My early grasp of it is that
for somebody to create a query they need permission to the underlying
tables. A RWOP query can let users sort of borrow those table permissions
from the query owner without actually needing permission to the tables.

One thing I'm still trying to sort out has to do with permissions. As I
understand it, a user who is a member of two groups will have the least
restrictive permissions. If one group can add data only, and another can
add or edit but not delete data, the user will be able to add and edit data.
What I can't quite sort out is whether this "least restrictive" rule applies
to users as well. In the example just given, if the user is given
permission to delete data, but that permission is not allowed any group of
with that user is a member, will the user be able to delete data anyhow? I
think so, because the least restrictive permission, whether it is a user
permission or a group permission, "wins". Users don't need any permissions
at all as long as they belong to groups that have permissions. Do I
understand correctly?


The main thing is that neither the Users Group, nor the Admin User
own anything. These two entities are common to every mdw. So if
either owns something, then anyone with Access (i.e. they'd be using
system.mdw) could, as owner, do anything with the object.

I have already banished the Admin user to the Users group, and
removed all permissions from the Users group, thanks in large part to
your instructions and reinforced by other things I have read (Jack
MacDonald's paper in particular).

That may not be sufficient. If you used the wizard in 2002 or 2003, then
you're likely OK. However just double-check that Admin is not the owner
of the Database Object (or any other object either). Even without any
permissions, the 'owner' trumps all. The owner can always take over.

Admin owns nothing.

Joan, thanks again for all of your help. I don't think I could have done
gotten this far, at least not anywhere near this quickly, without it. If
you have a chance to answer the few lingering questions, that would be
great, but I think that I have enough to keep me busy for a while. I have
undertaken several times to learn user-level security, but this is the first
time I feel like I might actually be getting it.


--
Joan Wild
Microsoft Access MVP



.

Loading