Security - Defualt MDW

[GUIDO22]

Hi there!

I have an occasional issue with workgroup security, whereby if the network goes down when users are logged in using their workgroup userid /password - the 'network' workgroup MDW file location details are replaced with those for the local copy of SYSTEM.MDW.

Subsequently, when the user next logs in on the network - the workgroup security config. is avoided and the database opens / defaults to ADMIN! This is not the best scenario.

How can I avoid this? Do I have to delete the local copy of MDW on each client machine or is there some other way easier way ? Coding option?

Thank you in advance.

Guido

 

[Galaxiom]

Only REAL headbangers consider upgrading to Access 2007...!

The first couple of days are difficult but after that I wouldn't want to go back to the older versions.

Ditto with all of MS Office 2007 though it takes longer to learn the new interface on Word and Excel. The new interfaces really are much better.

One way to get around finding the lost commands is using the Classic Menus for Office 2007 plugin.Definitely smooths the transition and I stopped using the legacy menus entirely after a few weeks.

http://www.addintools.com/english/menuoffice/

I found what appears to be a bug in the Access part of a pre V4 release that made Access crash. I reported it and it appears from the release notes that this has probably been fixed.

 

[Galaxiom]

This page has some information that might be useful.
http://www.secnewsgroups.net/group/microsoft.public.access.security/topic10054.aspx

 

[RuralGuy]

I believe if you apply ULS to your db you need to make sure the mdw file is a unique name to avoid this problem.

 

[The_Doc_Man]

Search this forum for articles on Workgroup security and Securing a Database.

The specific problem of SYSTEM.MDW requires two or three explicit actions.

First, NEVER use SYSTEM.MDW at any time after you deploy your DB to the public. You must always use a renamed .MDW file that matches the name of the DB as a matter of consistency for User Level Security (ULS).

Second, before you deploy, create an account that is going to be your administrator account. Change the ownership of every entity in the database to this account. Give the account all the privileges and permissions in the world. Be sure it has a password. Log out. Log in again using the (renamed) MDW file.

Now move the Admin account (no "s" at the end) into the Users group. Be sure that the Admin account has no privileges on its own and that it owns no objects. Add a password to the Admin account even though it is now useless.

The idea here is that you cannot avoid the existence of SYSTEM.MDW because it is created by the installation of MS Office. Can't get around it. BUT you can gut it by making it useless for YOUR database.

Next, when you create user accounts, use the MS Guidelines on rights management. No user (possibly except your special administrator account) has ANY permissions, any privileges, anything. Define some user groups (named anything but Users or Admins) that have the rights and permissions you wanted users to have, based on their roles in the database. Whether we are talking data entry or VBA programming or form design or just report printing, define the roles. When you are done, place users in your site-defined groups and let them gain permissions/privileges that way. It is far easier to manage.

Search this forum for ways to make users come in through an ICON that includes the workgroup name as part of the command-line properties of the icon, which you can see by right-clicking it, of course. That way, even if they have not joined the workgroup correctly via explicit action, the Icon will force the issue as a temporary thing.

Just 'cause I've told you a lot about security a DB, don't stop there. Search this forum for other tips.

 

[GUIDO22]

Search this forum for articles on Workgroup security and Securing a Database.

The specific problem of SYSTEM.MDW requires two or three explicit actions.

First, NEVER use SYSTEM.MDW at any time after you deploy your DB to the public. You must always use a renamed .MDW file that matches the name of the DB as a matter of consistency for User Level Security (ULS).

Second, before you deploy, create an account that is going to be your administrator account. Change the ownership of every entity in the database to this account. Give the account all the privileges and permissions in the world. Be sure it has a password. Log out. Log in again using the (renamed) MDW file.

Now move the Admin account (no "s" at the end) into the Users group. Be sure that the Admin account has no privileges on its own and that it owns no objects. Add a password to the Admin account even though it is now useless.

The idea here is that you cannot avoid the existence of SYSTEM.MDW because it is created by the installation of MS Office. Can't get around it. BUT you can gut it by making it useless for YOUR database.

Next, when you create user accounts, use the MS Guidelines on rights management. No user (possibly except your special administrator account) has ANY permissions, any privileges, anything. Define some user groups (named anything but Users or Admins) that have the rights and permissions you wanted users to have, based on their roles in the database. Whether we are talking data entry or VBA programming or form design or just report printing, define the roles. When you are done, place users in your site-defined groups and let them gain permissions/privileges that way. It is far easier to manage.

Search this forum for ways to make users come in through an ICON that includes the workgroup name as part of the command-line properties of the icon, which you can see by right-clicking it, of course. That way, even if they have not joined the workgroup correctly via explicit action, the Icon will force the issue as a temporary thing.

Just 'cause I've told you a lot about security a DB, don't stop there. Search this forum for other tips.

Thanks for the tips - I did find another posting with a download link for a PDF file with a little more detail on the points that you have raised here - thank you!
However, having done all that - I now find that with the Admin group effectively disabled - my SUPERUSER account that is both the owner and 'seemingly' has full administration access to all areas of the database - when I go into the User and Group Accounts - I am unable to Add/Remove Users / Groups...????

Any ideas , what I have done/not done?

Thank you.
Guido

 

[GUIDO22]

I believe if you apply ULS to your db you need to make sure the mdw file is a unique name to avoid this problem.

Yes - I was aware of that. It is unique! Thanks

 

[Atomic Shrimp]

The first couple of days are difficult but after that I wouldn't want to go back to the older versions.

Ditto with all of MS Office 2007 though it takes longer to learn the new interface on Word and Excel. The new interfaces really are much better.

I must be getting old. I've always been pretty quick to adapt to new systems - but I've been using Office 2007 every day for eight months now and I'm still finding the ribbons awkward and counterintuitive (as well as bulky and intrusive - the large brightly coloured icons add nothing of worth, IMO)

 

[The_Doc_Man]

I am unable to Add/Remove Users / Groups

Possibly forgot to change ownership of some of the hidden tables. You need to be sure that everything is owned by your superuser account. Including the structural tables.

 

[GUIDO22]

Possibly forgot to change ownership of some of the hidden tables. You need to be sure that everything is owned by your superuser account. Including the structural tables.

Nope - that doesnt work. Added the hidden/system tables to the permissions for SUPERUSER / closed and went back in - same thing - user and group add/remove is disabled.....

 

[madEG]

Also, to make sure that the appropriate mdw is used with your app when called, put it in the shortcut...

Goto the properties fr the shortcut your clients call, and in the target have three parameters: The version of office you wish to call (helpful if you have 2003/2007 installed), the wrkgroup file, and the target mdw... e.g.

"C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE" /wrkgrp "H:\dbapps\whatever.mdw" "H:\dbapps\whatever.mdb"

 

[GUIDO22]

Also, to make sure that the appropriate mdw is used with your app when called, put it in the shortcut...

Goto the properties fr the shortcut your clients call, and in the target have three parameters: The version of office you wish to call (helpful if you have 2003/2007 installed), the wrkgroup file, and the target mdw... e.g.

"C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE" /wrkgrp "H:\dbapps\whatever.mdw" "H:\dbapps\whatever.mdb"

Thanks - but I already have - it doesnt make any difference....!

NOTE : havent you got the shortcut text the wrong way round? - shouldnt it be the application, then the DB, then wrkgrp path????

 

[boblarson]

Actually, what has happened is you left the USER account with access to things. They should have NO access to anything. If you do apply the security correctly, if someone even tries to open your database without the shortcut they will see this:

You need to go into TOOLS > SECURITY > USER AND GROUP PERMISSIONS > Click on GROUPS and then remove the permissions for the USER group. Anyone that is joined to their normal System.mdw workgroup has the USER permissions.

 

[Banana]

IMHO, the only ULS guide you need. Read it then read it again and follow it exactly, then you'll get that dialog Bob showed you.

 

[GUIDO22]

IMHO, the only ULS guide you need. Read it then read it again and follow it exactly, then you'll get that dialog Bob showed you.

This is the manual that I read with interest that got me into this mess in the first place.... I will read AGAIN (with a little less interest, I might add) and hope there is something that I have missed.

But what I cant understand with Bob Larsons's earlier posting is - what relevance has removing the USER permissions got with the FULL access permissions that I have already granted to the SUPERUSER? Removing the USER permissions is not going to make any difference to the access of the SUPERUSER as detailed in my original posting.....?
ie. inability to add/remove users & groups....

BTW - I already get the aforementioned dialog when trying to log in as Admin

 

[GUIDO22]

I have re-read Jack MacDonalds handy guide to Security (mentioned above), and I had missed out possibly the most crucial paragraph.... ie. Users of my top-level SUPERUSER group should also be members of the ADMINS group.

Only ADMINS group have the in-built permissions to Add/Remove Users&Groups for the defined the workgroup.

 

[Banana]

Glad you figured it out. I don't blame you for having missed it the first time; the naming schemes for those users/groups are not exactly best name. Users should have been called 'Public' which is what it's called if we use DDL (or was it DAO? I can't remember but I know they use that keyword deep hidden somewhere), while Admin should be anything but 'Admin'. 'Default User' or 'Default Owner' would be more descriptive. But then again, Jack would probably prefer 'This is a giant security hole'.

Good luck.