Tearing my hair out - Security for end/back end database

[john471]

Hi Keith,

I know that in newer versions of access you join/create WIFs from a menu option within Access itself. In AC97, you had to run a separate exe, the "WorkGroup Administrator" which for a default WIN2K install is found in C:\WINNT\system32\WRKGADM.EXE (i.e. not from an Access menu option).

If running as a separate exe, you might a) not be running any instance of Access, or b) be running several instances of Access, each referring to an independent WIF. In such circumstances (particularly "b"), how would the "WorkGroup Administrator" determine what WIF to display as the one "in use" (as opposed to the one "joined to") ?

The possibilities may be a little different under newer versions, but just thought you might appreciate a possible explanation.... not making any excuses for the Redmond residents though, and certainly agree with your point, just saying that it may not be feasible in this situation, even if for legacy reasons.


Regards

John.

 

[Keith Nichols]

Hi Keith,

If running as a separate exe, you might a) not be running any instance of Access, or b) be running several instances of Access, each referring to an independent WIF. In such circumstances (particularly "b"), how would the "WorkGroup Administrator" determine what WIF to display as the one "in use" (as opposed to the one "joined to") ?

Hi John,

Thanks for the feedback and thoughts. More complexities than I imagined.

Situation a) It doesn't matter to me what wifs are where, if no instance of Access is running.

Situation b) Each database openned in separate instances of Access must have 'known', when they were launched, which wif was 'used'. So, for my money, it must be possible to have the workgroup adminstrator show the file joined to, and the file used for that instance of Access. This would be where the information could be of use - i.e. telling you what was going on with the particular database you are looking at.

Does it not seem odd to you that you look in the workgroup administrator to see which wif you are joined to, then go to user accounts/permissions and are infact seeing the information pertinent to a completely different wif? How are you suposed to keep track?

Whilst wading through this, there have been times when I have had a number of databases with similar names open using different wifs. Coupled with my inexperience, it's no wonder I got confused.

The code GHudson offered may provide this information but I haven't had time to play around.

Kind regards,

Keith.

 

[ghudson]

The code GHudson offered may provide this information but I haven't had time to play around.

Yes, the funcion I posted will tell you which wrokgroup file the current database is using. Just copy the function as-is into a module and run it. It is that simple.

 

[john471]

Situation b) Each database openned in separate instances of Access must have 'known', when they were launched, which wif was 'used'. So, for my money, it must be possible to have the workgroup adminstrator show the file joined to, and the file used for that instance of Access. This would be where the information could be of use - i.e. telling you what was going on with the particular database you are looking at.

Yes, but my point, which was perhaps a bit obscured, was that if the Workgroup Administrator were launched externally to Access (as was necessary in AC97), it wouldn't be "relateable" to any specific Access instance, to "know" which "in use" file to display. (Yes, Access "knows" which WIF it is using, and GHudson's code will reveal that, but how could an external, and externally launched application know.) In newer versions where it is run from a menu internal to a specific instance, perhaps that obstacle could now be overcome. I do not know if it is still running a seperate exe, or if it is all wrapped up inside the MSACCESS.EXE now ???? This may, or may not, be relevant.

Does it not seem odd to you that you look in the workgroup administrator to see which wif you are joined to, then go to user accounts/permissions and are infact seeing the information pertinent to a completely different wif? How are you suposed to keep track?

With many a trial and tribulation, followed by the slapping of one's own forehead, and expressions of "Doh!".

Access security is not for the fainthearted, and is also of limited use; akin to chaining up your bicycle to a fence post - anyone with bolt-cutters and a little effort can still steal it. I recently saw an Oracle presentation where they said something along the lines of "if your data is only worth fifteen dollars, then Access is a good place to store it"; further elaborating that on the internet you can purchase software that will readily crack Access security, for about $15. This is true. Of course, if you just want to prevent casual passers-by from stealing your bicycle, then chaining it to a fence post will probably be a sufficient deterrent. Horses for courses, I guess.

Regards

John.

 

[Keith Nichols]

"if your data is only worth fifteen dollars, then Access is a good place to store it";

Thanks for the feedback and thoughts gents. I have reflected on this as I progress my security and try to resolve other problems (see other threads with my moniker).

I can't speak for earlier versions of Access and the internal/exteral workgroup administration, but I have now refined my opinion as to where the WIF "used" information should be displayed in A2k and later versions - in the User & Group Accounts dialogue. This window shows the information from the used WIF, rather than the joined WIF, and it would only be poilite to identify the file actually being viewed and/or modified. If they can show the contents of the WIF, they can show the name.

As to the general point on security, I did not want to secure the database at all. It runs on a corporate network with the relevant security and is accessed only by professional people with a reasonable level of integrity. As long as back ups are made on a regular basis, I was happy to have the thing unlocked. However, one of the managers insisted that one or two of the tables could only be updated by managers. This could have been achieved by work practices rather than security, but there you have the real world.

Incidentally, the woefully inadequate spreadsheet that this database supersedes resided on a shared drive with no protection!

Once again, thanks.

Keith.

It may be that this situation is due to legacy issues from earlier versions

 

[razaqad]

what if some one deleted the backebd from the shared drive ??

 

[Keith Nichols]

Why would they?

what if some one deleted the backebd from the shared drive ??

Hi Raza,

The back end is backed up on a regular basis and the IT department do some sort of cacheing of the drive. I think I could get the previous day's version or, in a worst case scenario, a week old copy. This would mean minimal or manageable changes to update the backup.

All database users have read/write/delete access to the shared drive that the database back end sits on, so it is possible for one of them to malicioulsy, or otherwise, delete it I suppose. I'm not sure the protection Access provides is meant to protect against this, only preventing someone unauthorised reading/altering data.

But why would they?

In the final analysis, this database contains tracking information on the actual work we do. None of it is vital or sensitive although it is very useful to a great number of people.

Regards,

Keith.

 

[ghudson]

Just to answer the previous question...

Your network security folks could set the file permission to the backend file [not all files for the .ldb file needs to go away each time the last user exits the db] so that it can not be deleted.

 

[Robert88]

Secure a Database.............

Hi All,

There is some pretty interesting reading here

The 10 security steps summarized

http://www.ltcomputerdesigns.com/The10Steps.htm

Access 2002/2003 Security Step by Step

http://www.jmwild.com/security02.htm

Good reading .

Robert88