Share Workgroup Information File

[Guest]

I've studied the steps for securing a database and have successfully executed
it on my PC. However, the database is on a shared server.

Can it be that anyone who chooses to use his own Workgroup Information File
can use the database without security? Is there no way to lock the database
so that I don't have to set every user's machine to look to a new WIF? A
shortcut won't work guarantee security because the users all have the MS
Access Application installed and know where to find the database.

Thanks.

 

[Douglas J. Steele]

If security is properly applied, the answer is no.

The critical step is removing the Admin user from the Admins group so that
Admin is a member only of the Users group.

 

[Guest]

I did remove the admin user. So I think you're saying, I must go to each
user and point them to the new workgroup file. Thanks for your help.

 

[Guest]

I think the wizard additionally removes permissions from the Users group.

The Wizard removes the UserName: Admin from the Admins group.

 

[Douglas J. Steele]

I don't understand your comment "A shortcut won't work guarantee security
because the users all have the MS Access Application installed and know
where to find the database."

The shortcut should be something like:

"C:\Program Files\Microsoft Office\Office11\MSAccess.exe"
"\\server\share\folder\file.mdb" /wkgrp \\server\share\folder\secure.mdw

 

[TC]

No, that would affect /all/ their local databases - not just your
secured one.

Use the shortcut approach as Douglas suggested. Then, they'll be using
the proper workgroup file when they open your secured database, but the
/standard/ workgroup file when they open all their local databases.

HTH,
TC

 

[Eric]

Is there a way to prevent a user from viewing the shortcut target? For
example, if the secured database is on a network drive and a shortcut
has been created to point to the appropriate workgroup file (also on
the network drive), what is to prevent a user from going to the
properties of the shortcut, looking up the path and navigating to the
network location where they can open up the actual secured file instead
of via the shortcut. I'm probably missing something simple, but I've
been struggling with this question for a few days. I can't put the db
on a restricted drive, otherwise it wouldn't be accessible via the
shortcut. Do I need to come up with a completely different
architecture? Thanks!

 

[Jeff Conrad]

If you apply security properly, then if someone simply
navigates to the secured file, attempts to open it up while
joined to their default Access system workgroup file,
they will simply get an error saying they do not have
permissions to open the file.

--
Jeff Conrad
Access Junkie - MVP
http://home.bendbroadband.com/conradsystems/accessjunkie.html
http://www.access.qbuilt.com/html/articles.html

in message:

 

[Eric]

I think this is where I'm getting hung up----I'm having trouble
figuring out how to "cause an error" if a user opens up the secured
database (on the shared drive) with their default workgroup file (on
their hard drive). I've got the shortcut working properly, but I'm
having trouble securing the target file so that not anyone can open it
with their default workgroup file. I've tried to remove the Admin user
from the Admins group within the target file, but then it changes the
workgroup settings on my own hard drive, and I have to log-on for every
access database I have. I don't know why I'm having so much trouble
with this. I've read through about 100 messages on how to do this, but
I must be overlooking something. Thanks!!!

 

[Joan Wild]

I think this is where I'm getting hung up----I'm having trouble
figuring out how to "cause an error" if a user opens up the secured
database (on the shared drive) with their default workgroup file (on
their hard drive).

If you implement security properly, then you don't have to 'cause an error',
it will just happen. It's a good test to see if you have implemented
security properly. If you can even open your secure mdb using the standard
system.mdw, then you missed a step in securing it. Every step is essential,
or the database won't be secured.

Security FAQ
http://support.microsoft.com/?id=207793

Security Whitepaper
http://support.microsoft.com/?id=148555

I've also outlined the detailed steps at
www.jmwild.com/AccessSecurity.htm

 

[Eric]

I was able to get this to work using the security wizard. Thanks for
the excellent detailed steps, Joan! Probably should have used the
wizard from the beginning. Just out of curiousity, would it even have
been possible for me to secure the database on a network drive without
using the security wizard? I couldn't find a way to change any
security settings for the network database without it manipulating my
default system.mdw file. For example, when I opened the unsecured
database on the network in an attempt to secure it, I would try to
remove the Admin user from the Admins group, but this would change my
system.mdw file settings, which I was trying to avoid. Only through
the wizard (on the first page of the wizard) was I able to specify a
particular workgroup information file for that particular database to
use.

 

[Joan Wild]

I was able to get this to work using the security wizard. Thanks for
the excellent detailed steps, Joan! Probably should have used the
wizard from the beginning. Just out of curiousity, would it even have
been possible for me to secure the database on a network drive without
using the security wizard?

Sure, there's always a manual way to do what a wizard does for you.

I couldn't find a way to change any
security settings for the network database without it manipulating my
default system.mdw file.

The key is to either join another workgroup first, using the workgroup
administrator (Tools, security, WA), or to create a desktop shortcut that
specifies the workgroup file to use for that session. The latter is the
preferred method, since you'd have to rerun the WA to switch back -
certainly doable but you might forget.

 

[TC]

I guess you could write a small program that started your database
(using the right workgroup file) through code. That would certainly
stop a casual user from seeing where those two files were. But there
are lots of tools that would let an experienced user find them anyway.

HTH,
TC

 

[Guest]

I have the same problem as mentioned above. the db is secured but when other
users try to open it through their access and not through the link they do
not encounter any security.

from what i gathered is because the their access is using the local WIF
instead of the one created when i secured it.

I have allocated the admin user to the users group and not the admins but
still the problem exists.

I have created everything through the wizard.

Any suggestions how to overcome this and secure the db from everybody?

I have read what you are saying

 

[Rick Brandt]

I have the same problem as mentioned above. the db is secured but
when other users try to open it through their access and not through
the link they do not encounter any security.

from what i gathered is because the their access is using the local
WIF instead of the one created when i secured it.

It also means that you did not secure it properly. If they use the wrong
workgroup file they should NOT be able to open the file.

 

[Guest]

hi rick

it looks like i have cracked it.

It also means that you did not secure it properly. If they use the wrong
workgroup file they should NOT be able to open the file.