Re: More security questions

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.

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.

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

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 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

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.

--
Joan Wild
Microsoft Access MVP


.