467,889 Members | 1,408 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,889 developers. It's quick & easy.

Access Security?

Hello All,

What are the best ways to implement security for Access databases (i.e.
..MDB files)?

I ask the question from a general perspective. Why? Well I had written
a prototype database which I split. So I thought that I'd implement
security on it. The security worked great for both groups (i.e. Admins
& Users), but after looking at the detail I took it a little further.

What I did was move the .MDW file that I created in Access 2k.
Afterward both the front and back end database files (.MDB files) that
I created and secured with the .MDW file were accessible. I was able
to change the name of tables. So without spending much more time I
thought that I'd ask the general question from the perspective of only
using .MDB files. I have read about the use of .MDE files, but haven't
looked at them in detail.

I will state that security is relative, and nothing is ever totally
secure. From the brief exposure that I've had it looks like security
really is twofold. If I'm wrong please correct me. First, on network
you have to be able to administer the distribution of a .MDW file to
replace the System.MDW file for users to facilitate the group and user
security within Access. Second, the back end .MDW files can be secured
by the OS's path user's/group's permissions or rights. Also I should
state that I haven't really looked into the .MDW file administration
issue, so I maybe missing a big piece of the puzzle.

I have done some reading and know that I need to read the whole Security
FAQ per http://support.microsoft.com/kb/q207793/, but I thought this
would be a good question to ask the experienced users. I'm not looking
for the great debate, just some good guidance.

Am I looking at this correctly? Am I missing a large piece of the
puzzle? Or what?

Thanks!

--
Regards,

Greg Strong

Nov 13 '05 #1
  • viewed: 1800
Share:
5 Replies
"Greg Strong" <NoJunk@NoJunk4U≤.com> wrote in message
news:8b********************************@4ax.com...
Hello All,

What are the best ways to implement security for Access databases (i.e.
.MDB files)?

I ask the question from a general perspective. Why? Well I had written
a prototype database which I split. So I thought that I'd implement
security on it. The security worked great for both groups (i.e. Admins
& Users), but after looking at the detail I took it a little further.

What I did was move the .MDW file that I created in Access 2k.
Afterward both the front and back end database files (.MDB files) that
I created and secured with the .MDW file were accessible. I was able
to change the name of tables. So without spending much more time I
thought that I'd ask the general question from the perspective of only
using .MDB files. I have read about the use of .MDE files, but haven't
looked at them in detail.

I will state that security is relative, and nothing is ever totally
secure. From the brief exposure that I've had it looks like security
really is twofold. If I'm wrong please correct me. First, on network
you have to be able to administer the distribution of a .MDW file to
replace the System.MDW file for users to facilitate the group and user
security within Access. Second, the back end .MDW files can be secured
by the OS's path user's/group's permissions or rights. Also I should
state that I haven't really looked into the .MDW file administration
issue, so I maybe missing a big piece of the puzzle.

I have done some reading and know that I need to read the whole Security
FAQ per http://support.microsoft.com/kb/q207793/, but I thought this
would be a good question to ask the experienced users. I'm not looking
for the great debate, just some good guidance.

Am I looking at this correctly? Am I missing a large piece of the
puzzle? Or what?


Hi Greg,

The piece of the puzzle that you're missing is that the default "system.mdw"
should be left alone so that "non-secured" apps can still open and that your
custom workgroup information file (mdw) should be stored on a server where
all of your users can access it. Users would then join your workgroup on a
session by session basis using a desktop shortcut to the mdb with the
"/wrkgrp" switch in the command line. No "administration" of the mdw file
necessary other than the upkeep of the users and groups.

I might add that if you can still open your mdb app without joining your
workgroup then you've missed a step, probably the denying of access to the
"users" group to the database object. My web site has a step-by-step
example which might help your understanding in conjunction with the FAQ.

Access security is good but it can be broken by a determined hacker with the
right tools. If you need "real" security then you need to upsize to
something like Oracle.

HTH - Keith.
www.keithwilby.com
Nov 13 '05 #2
On Fri, 11 Nov 2005 08:52:44 -0000, "Keith W" <he**@there.com> wrote:
The piece of the puzzle that you're missing is that the default "system.mdw"
should be left alone so that "non-secured" apps can still open and that your
custom workgroup information file (mdw) should be stored on a server where
all of your users can access it. Users would then join your workgroup on a
session by session basis using a desktop shortcut to the mdb with the
"/wrkgrp" switch in the command line. No "administration" of the mdw file
necessary other than the upkeep of the users and groups.


Do the users only have read writes to the MDW file on the server? I
don't know where the password is stored. Where ever the password is
stored the user would have to be able to update that file. I'm just
thinking out loud, so correct me if I'm wrong. Thanks!

--
Regards,

Greg Strong
Nov 13 '05 #3
On Fri, 11 Nov 2005 20:44:17 GMT, Greg Strong <NoJunk@NoJunk4U≤.com>
wrote:
Do the users only have read writes to the MDW file on the server? I
don't know where the password is stored. Where ever the password is
stored the user would have to be able to update that file. I'm just
thinking out loud, so correct me if I'm wrong.


Per
http://support.microsoft.com/default...#_Toc493299661
the workgroup file includes password, so users would have to have update
permissions/rights.

--
Regards,

Greg Strong
Nov 13 '05 #4
"Greg Strong" <NoJunk@NoJunk4U≤.com> wrote in message
news:iu********************************@4ax.com...
On Fri, 11 Nov 2005 20:44:17 GMT, Greg Strong <NoJunk@NoJunk4U≤.com>
wrote:
Do the users only have read writes to the MDW file on the server? I
don't know where the password is stored. Where ever the password is
stored the user would have to be able to update that file. I'm just
thinking out loud, so correct me if I'm wrong.


Per
http://support.microsoft.com/default...#_Toc493299661
the workgroup file includes password, so users would have to have update
permissions/rights.


Users need RWXD permissions to the folder to where the mdb and mdw reside
and RWX to the files themselves.
Nov 14 '05 #5
Br
Keith W wrote:
"Greg Strong" <NoJunk@NoJunk4U≤.com> wrote in message
news:iu********************************@4ax.com...
On Fri, 11 Nov 2005 20:44:17 GMT, Greg Strong <NoJunk@NoJunk4U≤.com>
wrote:
Do the users only have read writes to the MDW file on the server? I
don't know where the password is stored. Where ever the password is
stored the user would have to be able to update that file. I'm just
thinking out loud, so correct me if I'm wrong.
Per
http://support.microsoft.com/default...#_Toc493299661
the workgroup file includes password, so users would have to have
update permissions/rights.


Users need RWXD permissions to the folder


In order to be able to dynamically create the LDB file....
to where the mdb and mdw
reside and RWX to the files themselves.

--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response
Nov 14 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

32 posts views Thread by Mike MacSween | last post: by
13 posts views Thread by BigDaDDY | last post: by
7 posts views Thread by Mark Thiel | last post: by
3 posts views Thread by mar10 | last post: by
17 posts views Thread by DaveG | last post: by
23 posts views Thread by Reggie | last post: by
reply views Thread by MrMoon | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.