Access 2002 Security

[Guest]

I have secured an Access 2002 database that is used by multiple users via
Terminal Server for some time with Access' native user and group security. I
did not use the Security Wizard to do this a long while ago as I was under
the impression that it has some undesirable consequences. I have also known
for some time that if you double-click on the db by mapping to the network
share that the Access db resides on you can bypass the security and I have
not been able to change ownership of the db away from admin, even by logging
into a new Access database as the account that I want to have ownership of
the db and importing all the database objects into it. I have several
questions.
1) Is the wizard the only way to change ownership?
2) Do I have to create a brand new mdw and recreate all the users and groups
to change ownership?
3) If the db is replicated, as it is, does other users using that mdw stop
ownership from being able to be changed--ie, do you have to be the only one
using the mdw to change ownership?
Thank you in advance for your time and replies.

 

[Joseph Meehan]

I have secured an Access 2002 database that is used by multiple users
via Terminal Server for some time with Access' native user and group
security. I did not use the Security Wizard to do this a long while
ago as I was under the impression that it has some undesirable
consequences. I have also known for some time that if you
double-click on the db by mapping to the network share that the
Access db resides on you can bypass the security and I have not been
able to change ownership of the db away from admin, even by logging
into a new Access database as the account that I want to have
ownership of the db and importing all the database objects into it.
I have several questions. 1) Is the wizard the only way to change
ownership? 2) Do I have to create a brand new mdw and recreate all
the users and groups to change ownership?
3) If the db is replicated, as it is, does other users using that mdw
stop ownership from being able to be changed--ie, do you have to be
the only one using the mdw to change ownership?
Thank you in advance for your time and replies.

I suggest you start by reading
http://support.microsoft.com/default.aspx?scid=kb;[LN];207793

Access security is a great feature, but it is, by nature a complex product
with a very steep learning curve. Properly used it offers very safe
versatile protection and control. However a simple mistake can easily lock
you out of your database, which might require the paid services of a
professional to help you get back in.

Practice on some copies to make sure you know what you are doing.

 

[Joan Wild]

I have secured an Access 2002 database that is used by multiple users via
Terminal Server for some time with Access' native user and group security.
I
did not use the Security Wizard to do this a long while ago as I was under
the impression that it has some undesirable consequences. I have also
known
for some time that if you double-click on the db by mapping to the
network
share that the Access db resides on you can bypass the security and I have
not been able to change ownership of the db away from admin, even by
logging
into a new Access database as the account that I want to have ownership of
the db and importing all the database objects into it.

That is the usual way to change ownership. Perhaps you did not implement
security properly or you were not joined to the mdw you thought you were.

I have several
questions.
1) Is the wizard the only way to change ownership?

No, what you've done is the usual method.

2) Do I have to create a brand new mdw and recreate all the users and
groups
to change ownership?

Not at all.

3) If the db is replicated, as it is, does other users using that mdw stop
ownership from being able to be changed--ie, do you have to be the only
one
using the mdw to change ownership?

Quite likely, but you should not replicate the whole mdb. You should split
it into frontend/backend. The BE contains just the tables/relationships,
and the FE has links to the tables in the backend. Replication is meant for
data only (tables). You should not replicate the frontend. Give each user
a copy of the frontend. Even in a TS environment, each user should have
their own copy of the FE.

I'm curious why you need replication, if you are using TS?

 

[Guest]

I know that I should have split the database some time ago, but quite frankly
I use replication to apply new design changes( I really don't see a need
right now for multiple sets of the same tables)--the production database is
in a constant state of development and working on it while there is no one
using it is not an option. Also, since we have three offices, in Kansas,
Illinois, and California, I know that it is not feasible to distribute a copy
of the front end to all the workstations and also I believe that distributing
a new front end with new design changes would be a nightmare. As such, I am
trying to investigate using a network share with the users having almost no
permissions on the server but using that network share instead of running
what I consider to be basically a built-in backdoor for any would-be hacker
to utilize (ie, terminal services)--let alone the continuing licensing costs
of terminal services. The problem is that the typical one that directly
opening the database bypasses the mdw file--I also think that distributing
this would be not feasible, as undoubtably someone would be missed and I have
no way of physically making that mdw file the one for the client systems,
short of potentially compromising their systems using remote management. I
suppose that I could try using the old school method from Access 2000 of
putting the path to the mdw in the shortcut but, oddly enough, it seemed that
my database was much less stable when I had it set up that way more than six
months ago. I hope that wading through this big post is not too much hastle
for anyone. Thank for your responses and your time.

 

[Joan Wild]

I know that I should have split the database some time ago, but quite
frankly
I use replication to apply new design changes

Replication was not meant for design changes (except in tables). You will
likely regret this at some point.

Also, since we have three offices, in Kansas,
Illinois, and California, I know that it is not feasible to distribute a
copy
of the front end to all the workstations and also I believe that
distributing
a new front end with new design changes would be a nightmare.

Just using TS should work in this case. Tony Toews' FE updater works for TS
setups as well.
http://www.granite.ab.ca/access/autofe.htm
Also look at
http://www.granite.ab.ca/access/terminalserver.htm

The problem is that the typical one that directly
opening the database bypasses the mdw file

If that's the case, then you missed a step in securing it. If done
properly, they shouldn't even be able to open the mdb without using the
proper mdw.

 

[Guest]

Joan, I thank you for your responses. I think that in the company that I
work for, getting rid of terminal services is a goal. As such, we will
probably be going with a MySQL backend and Access front end in the near
future (sadly, not SQL Server). We had to use this never to me quite
satisfactory TS setup a few years ago because the WAN VPN connection is just
too slow to move the database through. What will probably happen in the
future is a replicated MySQL backend on servers in all three locations and
somehow getting that front-end to the different workstations. But, this is
all still a while off. I am curious, though, what you mean by each TS user
having their own FE--do you mean putting a separate copy of the FE in the my
documents or some such folder specific to each user account? Thank you again
for your time and responses.

 

[Joan Wild]

I am curious, though, what you mean by each TS user
having their own FE--do you mean putting a separate copy of the FE in the
my
documents or some such folder specific to each user account? Thank you
again
for your time and responses.

Precisely.