NT File permissions, 'hardening' Access security

[Mike MacSween]

I'm not talking Access Users & Groups, I may or may not implement that. Even
if I do file/folder rights still need to be managed.

I've searched the archives and read the many postings. The basic problem
seems to be this:

Access is a 'file server' based system. So if you want your users to use the
db they've got to have access to the file. And can do stuff to it you might
not want.

David Fenton had a good idea, ShareName$ hides the Share. But you need admin
privileges to name shares, and in this case I won't ever have them.

So this is what I came up with. The app is FE/BE split. FE on whichever
workstations, BE on a network share. MIS have set the share up for me, and I
have
full control permissions over that. I just tried this on my network, which
is the same config as the one at work (roughly speaking!) - XP clients,
Win2K
Server.

On the folder containing the backend I give users write privileges, but
nothing else, specifically denying them List Folder/Read Data. But letting
them delete subfolders/files (to get rid of the ldb.)

On the backend mdb (which is in that folder) I give them Read, Read &
Execute
rights, and don't allow inherited rights. This is for a user I intend to
only be read only. This seemed to work. Logging on as my 'ReadOnly' user I
could read the data, but couldn't update it, insert or whatever. The ldb
file was created and deleted fine, but I couldn't examine the contents of
the folder. Am I missing something?

Often I've heard it said that you can't stop people simply copying the file,
whatever you do with NT permissions. That doesn't seem to be the case here.
Or am I right in thinking that they could just copy the whole folder?

I'll try it now, and see what happens with my read/write user too......

Nope, neither user could copy the whole folder (to get at the file). Both
users could connect to the data in the way I intend (read only or read
write). The ldb gets created and deleted as the last user logs off.

This seems like a fairly robust setup, as far as the back end data file is
concerned. So what huge hole have I missed?

Yours, Mike MacSween

[Tom van Stiphout]

On Thu, 6 Nov 2003 20:21:51 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote:

Not sure what exactly you are trying to achieve, but it appears
denying the right to copy the BE file is one of them. However, users
can import the BE tables in a local MDB they created. Indeed the file
was not copied, but the precious data is.

-Tom.

I'm not talking Access Users & Groups, I may or may not implement that. Even
if I do file/folder rights still need to be managed.

I've searched the archives and read the many postings. The basic problem
seems to be this:

Access is a 'file server' based system. So if you want your users to use the
db they've got to have access to the file. And can do stuff to it you might
not want.

David Fenton had a good idea, ShareName$ hides the Share. But you need admin
privileges to name shares, and in this case I won't ever have them.

So this is what I came up with. The app is FE/BE split. FE on whichever
workstations, BE on a network share. MIS have set the share up for me, and I
have
full control permissions over that. I just tried this on my network, which
is the same config as the one at work (roughly speaking!) - XP clients,
Win2K
Server.

On the folder containing the backend I give users write privileges, but
nothing else, specifically denying them List Folder/Read Data. But letting
them delete subfolders/files (to get rid of the ldb.)

On the backend mdb (which is in that folder) I give them Read, Read &
Execute
rights, and don't allow inherited rights. This is for a user I intend to
only be read only. This seemed to work. Logging on as my 'ReadOnly' user I
could read the data, but couldn't update it, insert or whatever. The ldb
file was created and deleted fine, but I couldn't examine the contents of
the folder. Am I missing something?

Often I've heard it said that you can't stop people simply copying the file,
whatever you do with NT permissions. That doesn't seem to be the case here.
Or am I right in thinking that they could just copy the whole folder?

I'll try it now, and see what happens with my read/write user too......

Nope, neither user could copy the whole folder (to get at the file). Both
users could connect to the data in the way I intend (read only or read
write). The ldb gets created and deleted as the last user logs off.

This seems like a fairly robust setup, as far as the back end data file is
concerned. So what huge hole have I missed?

Yours, Mike MacSween

[Mike MacSween]

"Tom van Stiphout" <to*****@no.spam.cox.net> wrote in message
news:tk********************************@4ax.com...

On Thu, 6 Nov 2003 20:21:51 -0000, "Mike MacSween"
<mi******************@btinternet.com> wrote:

Not sure what exactly you are trying to achieve, but it appears
denying the right to copy the BE file is one of them.
Yes, that's one of them.
However, users
can import the BE tables in a local MDB they created. Indeed the file
was not copied, but the precious data is.

Sure. But that would be a little harder. They'd have to know about the
bypass key. And I can always disallow that.

The data aren't that precious. More what I want to do is just stop people
messing with this. This is a student marks database at a college I teach at.
At the end of last year, despite me saying specifically that it wasn't set
up for multi user access, one of my superiors told our clerical officer to
'copy the file onto the shared area'. Of course they didn't have a clue what
they were doing, that there were 2 files, consequently it didn't work. Then
one day something else went wrong when I wan't there, the head of MIS had to
be called to rescue the situation (call the cavalry!). He doesn't really
know Access either, but managed to figure out that one file was 'linked' to
another. So copied them both to another 'backup' directory. Now our clerical
officer tells me, 'oh, since that time it went wrong we've been using the
backup that the head of MIS made'. Of course, he didn't change the links, so
the FE that he'd copied still had linked tables in the 'old' BE. No doubt he
assumed you just copied them both about and 'hey presto'. I know that's what
he thought because I asked him if he'd remade the table links to the new
directory and he didn't know what I was talking about.

Upshot is, it's their database, but I developed it. I want to do as much as
I can to stop people copying it about all over the place. People taking the
data isn't really crucial. After students are awarded degrees then it's all
public anyway. But the level of IT knowledge amongst my colleagues is
minimal. I want stop people making umpteen copies, then nobody knowing which
the most up to date one is, replacing the live one etc. etc. At least not
without consulting me first.

I'd not thought about people copying the actual tables, thanks. Presumably
if I dissallow bypass key and don't show the the database window, it's going
to take a pretty sophisicated user to get any data out of that, except
through the interface, yes?

Yours, Mike MacSween