Security: User Account Problems

  • Thread starter Thread starter David Kistner
  • Start date Start date
D

David Kistner

I'm using Access 2002 in a client/server user-level security model. I
have two problems.

First, I created a few user accounts on the database a long time ago
by logging in as "Admin" and using the "Choose Tools -- Security --
User and Group Accounts" and then clicking on the "Users tab, and then
clicking on "New". Today I tried to add a new user but found that the
"New" button is grayed-out. I'm signed in as "Admin" and on the
server, but am still not allowed to add users. I must be forgetting
to do something, but can't think of what it might be that I'm doing
wrong.

The 2nd problem is that when anyone tries to use the database on the
server machine, they are prompted for a user name and password, while
the same user can sign on to a network client machine and get into the
database without being prompted for a user name and password! They
are only prompted for their user name and password to gain access to
the shared folder (Windows XP "permissions" on the folder). What am I
doing wrong?


Thank you very much in advance for your help with this.

- David Kistner
 
Hi David,

David said:
I'm using Access 2002 in a client/server user-level security model. I
have two problems.

First, I created a few user accounts on the database a long time ago
by logging in as "Admin" and using the "Choose Tools -- Security --
User and Group Accounts" and then clicking on the "Users tab, and then
clicking on "New".

That was not the way to proceed. The 'Admin' user in Access should not have
any permission to do anything. The very first step in securing an Access
database is to create a new workgroup. It doesn't sound as though you did
that, so right off you database isn't secure.
Today I tried to add a new user but found that the
"New" button is grayed-out. I'm signed in as "Admin" and on the
server, but am still not allowed to add users. I must be forgetting
to do something, but can't think of what it might be that I'm doing
wrong.

When you say you signed in as 'Admin', are you referring to an Access
username, or a windows username? You'd need to login to Access as a user
that is a member of the Admins Group (in Access). Note that it doesn't
matter what your windows username is (as long as that user has access to the
folder where the mdb is).
The 2nd problem is that when anyone tries to use the database on the
server machine, they are prompted for a user name and password,

Are they using a shortcut to do this - the shortcut is likely specifying a
workgroup that has a password set for the Admin user.

while
the same user can sign on to a network client machine and get into the
database without being prompted for a user name and password!

This indicates that it isn't secure, as they are not using the correct
workgroup file.
 
Joan Wild said:
Hi David,



That was not the way to proceed. The 'Admin' user in Access should not have
any permission to do anything. The very first step in securing an Access
database is to create a new workgroup. It doesn't sound as though you did
that, so right off you database isn't secure.


When you say you signed in as 'Admin', are you referring to an Access
username, or a windows username? You'd need to login to Access as a user
that is a member of the Admins Group (in Access). Note that it doesn't
matter what your windows username is (as long as that user has access to the
folder where the mdb is).


Are they using a shortcut to do this - the shortcut is likely specifying a
workgroup that has a password set for the Admin user.

while

This indicates that it isn't secure, as they are not using the correct
workgroup file.


Hi and thanks for your help. I have made progress, and am now able to
set user/group permissions etc. so the 1st problem is solved. I also
took your advice and removed Admin's permissions as you suggested. I
established a workgroup as you suggested and have a WIF.

But I still have problem #2:

While users on client machines are required to have Windows XP
folder-level permissions, to access the mdb, once there, they are not
prompted for a username and password to use the database. Here's a
recap of what I did to get this far. When I split the database for
client/server I left the backend of the database on the server in a
shared folder. On the client machines I copied all objects other than
the backend tables -- then I refreshed the "Linked Table Manager" to
refresh the links so that they point to the backend on the server. I
then created an icon that points to the client's mdb file. Once a
user clicks on their icon (and they have the Windows XP shared folder
permissions) they are "in" the database -- they don't get prompted for
anything. It is the same situation on the server......I get prompted
to give my database username and password, but they don't. I set them
up with usernames and passwords just like me (as far as I know). Why
are they exempt from security?

Thank you very much in advance for your help with this.

- David Kistner
 
Hi David,

David said:
Hi and thanks for your help. I have made progress, and am now able to
set user/group permissions etc. so the 1st problem is solved. I also
took your advice and removed Admin's permissions as you suggested. I
established a workgroup as you suggested and have a WIF.

I hope that you did more than just that. I hope you started over with an
unsecured copy of your database. I can't tell from the information you've
given, but it sounds as though you may not have done things in the correct
order (it's important).
While users on client machines are required to have Windows XP
folder-level permissions, to access the mdb, once there, they are not
prompted for a username and password to use the database.
When I split the database for
client/server I left the backend of the database on the server in a
shared folder.

Did you secure it first, or split it first?
On the client machines I copied all objects other than
the backend tables -- then I refreshed the "Linked Table Manager" to
refresh the links so that they point to the backend on the server.

How did you 'copy all objects' - if you imported into a new database, they
will lose all their permissions. But why did you copy the objects? All you
need to do is to create the links in your copy of the frontend, secure it
properly. Then just copy the file to their machines - there is nothing to
do on their computers.

I
then created an icon that points to the client's mdb file. Once a
user clicks on their icon (and they have the Windows XP shared folder
permissions) they are "in" the database -- they don't get prompted for
anything.

What is in the target for their desktop shortcut? It's likely missing
pieces, and therefore they are logging in using their standard system.mdw
workgroup, rather than your secure workgroup. However this is a bigger
problem. They should not even be able to open the mdb unless they are using
the correct workgroup - it's a sign that you missed a step in securing it.


It is the same situation on the server......I get prompted
to give my database username and password, but they don't. I set them
up with usernames and passwords just like me (as far as I know). Why
are they exempt from security?

I don't know what you mean by 'same situation on the server'. You may be
getting prompted, because you are joined by default to your secure mdw (if
this were so you would get prompted for every database you open - even
unsecured ones).

I think that because you started out wrong at the first step, you need to
start over. Some tips:

Secure the database, and then split.
Don't use Tools, Database Utilities, Database Splitter to split the
database; do it manually. See
www.jmwild.com/SplitSecure.htm
Use UNC paths when linking, rather than a mapped drive (when linking, use
Network Neighborhood to locate the backend)
Put the secure workgroup and the backend on the server in a folder that all
users have full permissions on.
Don't name your secure mdw the same as the backend mdb.
Once you have the frontend, login, shortcut, working on your computer, just
copy the frontend and the shortcut to the users' machines.
 
Joan Wild said:
Hi David,



I hope that you did more than just that. I hope you started over with an
unsecured copy of your database. I can't tell from the information you've
given, but it sounds as though you may not have done things in the correct
order (it's important).



Did you secure it first, or split it first?


How did you 'copy all objects' - if you imported into a new database, they
will lose all their permissions. But why did you copy the objects? All you
need to do is to create the links in your copy of the frontend, secure it
properly. Then just copy the file to their machines - there is nothing to
do on their computers.

I

What is in the target for their desktop shortcut? It's likely missing
pieces, and therefore they are logging in using their standard system.mdw
workgroup, rather than your secure workgroup. However this is a bigger
problem. They should not even be able to open the mdb unless they are using
the correct workgroup - it's a sign that you missed a step in securing it.


It is the same situation on the server......I get prompted

I don't know what you mean by 'same situation on the server'. You may be
getting prompted, because you are joined by default to your secure mdw (if
this were so you would get prompted for every database you open - even
unsecured ones).

I think that because you started out wrong at the first step, you need to
start over. Some tips:

Secure the database, and then split.
Don't use Tools, Database Utilities, Database Splitter to split the
database; do it manually. See
www.jmwild.com/SplitSecure.htm
Use UNC paths when linking, rather than a mapped drive (when linking, use
Network Neighborhood to locate the backend)
Put the secure workgroup and the backend on the server in a folder that all
users have full permissions on.
Don't name your secure mdw the same as the backend mdb.
Once you have the frontend, login, shortcut, working on your computer, just
copy the frontend and the shortcut to the users' machines.


Everything is working fine now. You were 100% correct in that I
skipped some steps. I picked up a couple of good books (Access 2002,
The Complete Reference by Virginia Andersen & the Access 2003 Bible by
Prague, Irwin and Reardon) and worked through their step-by-step
instructions and now everything works as it should. Now I finally
understand how security is supposed to work. Thank you for taking the
time to help me. I deeply appreciate your taking the time to help.

- David Kistner
 
David said:
snip<
Now I finally
understand how security is supposed to work. Thank you for taking the
time to help me. I deeply appreciate your taking the time to help.

You're welcome; glad you got it sorted.
 
Back
Top