Newly added user can't login; password rejected

[Frank Herman]

On an Access 2000 database which I previously successfully
ran the user security wizard weeks earlier, I am trying to
add a new user/password. The tools/security/user and group
accounts function lets me add the new user and password.
When I then close the database and try to log back in
under the new user, the database says the password is not
valid. When I log back in under my own password (and I am
in the admins group with full permissions to everything),
it shows the new user as being created. Do I need to re-
run the user security wizard to get this new user's
password "into" the system? Shouldn't I be able to just
add a new user/password without it, or do I need to add
this user under admins?

 

['69 Camaro]

Hi, Frank.

The tools/security/user and group
accounts function lets me add the new user and password.

Not quite. This dialog window allows one to add a new user, as well as
change/add a password to the currently logged in user. For security
reasons, no user, not even a member of the Admins group, can change the
password of another user through that GUI. You wouldn't want me to log in
as me and be able to change _your_ password, now would you?

So, the password you were changing was the password for the user you logged
in as when you created the new user.

After creating the new user, one must log out of the database, then log back
in as the new user with _no_password_, then open the User and Group Accounts
dialog window to assign a password to that user.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Frank]

Gunny,

Thanks for the clarification. I realize now that while I
thought I was creating a _password_ for the new account,
it was really a _personal ID_, which is not the same. The
problem remains, however, that when I try to log back
into the database with the new account name _without_ a
password, Access says I don't have the right password and
won't let me in. That's the original problem. Any other
thoughts?

 

['69 Camaro]

Hi, Frank.

Make sure that you are joined to the workgroup that you think you are.
Being joined to the wrong workgroup is probably the most common problem when
a user can't log into the workgroup.

When you verify that you are joined to the correct workgroup (or are using
it in a shortcut), open a database and log into the workgroup as an member
of the Admins group. Open the User and Group Accounts dialog window, then
select this new user's UserID in the combo box. Next, select the "Clear
Password" button. Close the window by selecting the "OK" button and exit
out of Access. Open the database again and log into the workgroup as the
new user, without a password. Once logged in, you can create a password for
this user by using the User and Group Accounts dialog window.

If you still can't log in with this UserID, then I would suggest deleting
this UserID and then recreating it again.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Frank]

Gunny,

Thanks again so much - I'll try it now. Once I have run
the user level security wizard to do my initial setup of
accounts/passwords (which I did months ago), I assume
that any subsequent account additions do not require me
to run the security wizard again to make my new account
additions "take hold", correct?

 

['69 Camaro]

Hi, Frank.

I assume
that any subsequent account additions do not require me
to run the security wizard again to make my new account
additions "take hold", correct?

Correct. Just use the User and Group Accounts dialog window to clear the
new user's password.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[Frank]

Gunny,

I got it to work. The problem was that not only did I have
to give the user permission to run the various forms and
tables - I also needed to give him permission to run the
database itself, which I had neglected to do. Once I did
that, everything you told me worked great. Thanks so much!

Frank

 

['69 Camaro]

You're welcome! Glad it helped.

Three more things:

1.) Assign permissions to groups, not individual users. That way, if one
has ten users at the same level of database access permissions and needs to
make a change, say adding "delete data" permissions for a table, that one
change will quickly and easily be made to the group's permissions, not each
of the ten users, one by one.

2.) Especially if this new user is not a member of the Admins group, one
should remove all permissions to the tables for this new user, as well as
for the other non-Admins groups that this new user is a member of, then base
access to the tables on queries that have "Run With Owner's Permissions"
(RWOP), then make these queries the record sources for the forms and
reports.

3.) Jet follows the "least restrictive permissions" assigned to the user.
If one assigns a whole truckload of permissions to a user, then puts
restrictions on an object for the group that the user is a member of, Jet
will apply the user's individual permissions to use that object. Each
individual user should have the bare minimum of permissions to use the
database application. (As you found out, Open/Run Database permissions are
an absolute must!) It's the groups that the individual user is a member of
that should provide the security permissions to the user.

I would advise making a copy of the database file and the workgroup
information file and experimenting with these copies to teach yourself
exactly which permissions are the minimum needed to enable your database
application to operate as intended for each separate group. That way, even
if you lock yourself out of the test workgroup or test database, your "real"
database remains accessible to your administration. And you'll learn
valuable information while experimenting.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

 

[david epsom dot com dot au]

database itself, which I had neglected to do. Once I did

Notice how you have to scroll UP in the list to see the
database permission setting. I think that it is a general
problem with Windows Combo Boxes, but seldom is it so
clearly a problem as it is with that security form. Perhaps
when an object is not selected in the database window,
that drop down list should default to Database instead of
Tables

(david)

 

[Joan Wild]

Notice how you have to scroll UP in the list to see the
database permission setting. I think that it is a general
problem with Windows Combo Boxes, but seldom is it so
clearly a problem as it is with that security form. Perhaps
when an object is not selected in the database window,
that drop down list should default to Database instead of
Tables

Actually in 2002/2003 you don't have to scroll up. It was that way in
version 97, and I'm not sure about 2000.

 

[david epsom dot com dot au]

2000 was pretty much the same as 97, except that when you
had the module pane selected, you got table permissions
displayed.

(david)