Bak end security over a network

[romanzero]

Hi,

This is probbly more of a networking question than an Access question, but I have always received good advice here...

I have a split db. I want to place the back-end in a different Active Directory folder than the front end so as to prevent users from copying the tables to their hard drive.

The front end only works if I give the user permission to open the back-end folder, but that obviously defeats the purpose.

I am looking for advice.

Thanks!

 

[easyit]

Hi,

-You should place the front end on the users compueter.
-Enable Access security to prevent unwanted tampering
with the tables.
-Let the users have full access to the back end directory.



EasyIT

EasyIT

"Do you think that’s air you're breathing?

 

[Ed2020]

I can't think of a solution to this. Your database won't be usable unless the backend is accessible. If the parent directory isn't accessible the backend won't be either.

Providing the database is adequately secured and access to the database window is restrictedd users won't know where the backend is so won't be able to copy it to their hard drives.

I also find not giving the users their user name and password is a useful technique. I have a launcher application that fires up an instance of access and passes the user names and passwords as a command line parameter

Ed Metcalfe.

Please do not feed the trolls.....

 

[romanzero]

Thanks Ed,

What do you mean by

...access to the database window is restrictedd users won't know where the backend is so won't be able to copy it to their hard drives.

?

My greatest concern is the possibility that someone will copy the back end DB to their hard drive.

 

[DanJR]

you could put a password on the backup db? e.g. a 20 character password that only you know - your users won't know it. The client app will have the password in the code, but if you put the password in a module and turn the app into a mde it should be fine for in-house "security".

would that be sufficient?

 

[Ed2020]

If you secure your frontend database and hide the MS Access database window, plus turn off all the unrequired default menus (esp. the linked table manager) users won't have any way of finding out where the backend database is - store them in separate directories.

It's only a partial solution, but it goes some way to solving your issue.

The database password on the backend is a good suggestion. Either that or not giving the users their workgroup user name and password means they can copy the backend database, but won't be able to do much with it once they have it.

Ed Metcalfe.

Please do not feed the trolls.....

 

[romanzero]

Thank you for the responses.

I have set up users permissions in the mdw file.

If I were to secure the back end with the database password would I put the password in the client app via some VBA code???

 

[jsteph]

romanzero
I have something like Ed had suggested--a simple VB (not VBA) .exe file. You basically call the front-end app via a shell call.

ShellExecute is also a possibility, but both forcing the correct security .mdw and with multiple version of Access on the same machine you'll want to force it to open the correct Access version with the correct .mdw.

So I use Shell, with a quick check for standard MSOffice install locations then if that fails, a file-search for the correct MSaccess.exe version. Anyway, that's the gist of it, you are basically hard-coding the user/password as part of the hard-coded commandline. You could use registry calls or hidden ini files if you want to get elaborate.

This way--if the .mdb is correctly secured--the users can't possibly open the .mdb without going through the .exe proxy stub. This opens up so many more possibilities for securing data. For instance, the .mdw itself need not be known by the user. You can name it lklfdasd.dll for all anyone cares--as long as it's on the hard-coded commandline in your .exe then it is less likely to be found and less likely for those password cracking tools to be used against it.

In addition, you can call a NET USE with a password and make a hidden mapping to the backend drive--it won't show up in Windows explorer, but Access can use the linked tables there. Lot's of other stuff can be done--you can torpedo the registry's MRU list of databases so the users don't even know where the front-end is--again, this could be named lkjlfdsf.dll buried in the system32 directory and noone is the wiser--it's all coded in the exe.
--Jim

 

[Ed2020]

romanzero - I think you will be prompted for the password when you link your tables into the frontend. Once you have entered it once you won't need to again to access tables via the frontend.

It seems Jim has taken the idea a lot further than me!

I have an MS Access launcher that records the details of all of my systems in a table. This launcher is opened via a small VB6 exe so the users do not have the username/password for the launcher either.

The MS Access launcher contains details of all of the system frontends, the relevant MDW file, user names and passwords.

It's preferable for the users as they do not need to remember their own passwords (all my databases use a standard security setup - all users open the database using a common user account).

I have also experimented with not granting the user account any privileges to the data tables. All data operations are performed by a transaction engine which opens database and recordset objects via a separate System account, which contains the necessary rights.

It all works, but to be honest if this level of security is required MS Access is probably not the right tool for the job. Regardless of what security is put in place MS Access security is still very crackable for anyone with a litte knowledge of how to use Google.

Ed Metcalfe.

Please do not feed the trolls.....

 

[romanzero]

Thank you all for your advice.

In addition to the user level security

I have secured the back-end with its own password

Linked the front-end

Removed all of the toolbar options

Hidden all sensitive queries and tables (in both BE and FE)

Created a "blank" pop up form for the BE (I want to take a screen shot of a empty database table screen and put that as the OnOpen pop-up...maybe to momentarily confuse any possible intruder). I have created a hidden button to minimize the form and disabled the bypass key.

Now I am going to work on the shortcut/password syntax to remove the user even one more step from the database.

"A paranoid is someone who knows a little of what's going on."
William S. Burroughs

 

[easyit]

...From your words it seems to me that you have not enforced builtin multiuser security, or am I mistaking? If so, remember that every user is an administrator in your db.

EasyIT

EasyIT

"Do you think that’s air you're breathing?

 

[romanzero]

Every user is logging in as Admin as default, but I have transferred the database to a new Owner and have removed many of the rights that Admin enjoys.

The annoying thing about Access security is that to give Admin rights to view information on a form or report I have to give them access to view the whole table and/or query.

This is my biggest problem.

 

[easyit]

I think you should re do the security.

See my first post; do not use database passwords.

You can chack my replies on this thread:

http://www.tek-tips.com/viewthread.cfm?qid=1282414

(see the reply in th bottom)

Or search the faqs about implementing security.
Whatever you do: Make a backup of FE & BE before you start.

EasyIT

"Do you think that’s air you're breathing?

 

[jsteph]

Romanzero,
You don't need to give access to the whole table for them to view.

You can use "With Owner Access" option in the query. (In properties under Run Permissions).

This way, you create a query that get's records as if it were the owner, but the underlying table can't be opened raw by the user. This query can be hidden and used as a form's data source.

There are other more complex ways of causing that query to not open with any records unless it is part of the form, if a user happens to un-hide it.
--Jim

 

[DanJR]

Given your suituation requires consideration to the finer aspects of securing an MS database/app, then i recommend you purchasing:
"Real World Microsoft Access Database Protection and Security"

It's very thorough, and even discusses things like setting up folder permissions such that users will not be able to browse the folder where the db is located,etc,etc,etc......

User-level security will be gone in MS Access 2007 (ACCDB format)