Workgroup Information File

[tdfreeman]

I could really use an explanation of the workgroup information file (WIF in this document). I have read documentation from books and the web and it leaves me with questions. Can anyone help?

The following is the issue that led to my questions:

A couple of days ago my co-worker and I were working on understanding security. Now, my co-worker was the driver of our test and he was not very organized in his approach. So, we were opening and closing different databases and playing with the WIFs not totally understanding what we were doing. Anyway, we changed the security on a database and for some reason he tried to go into an unsecured database (the production database on the lan), or so we thought. When he opened the unsecured database, it prompted him for the security as we had previously set up on earlier databases.

So, there does not seem to be a link from the database to the WIF. If you click on the database file, it uses the WIF that was the last one the user used, regardless of the database the user last opened.

Isn't this poor security. Shouldn't the database be associated with a WIF? The user's open up the mdb file, not a shortcut. How do you associate the WIF with the database when they directly open up the database? If a user wants to bypass security, couldn't he use his default system.mdw and bypass security.

Now there was something about removing the admin user from the database and reassigning all objects to the workgroup administrator. Maybe this solves the problem.

I could sure use an experts analysis on this. If you can spell this out more clearly for me I would really appreciate it.

Thank you in advance for your help.

Tammy

Thank you for your help.

Tammy

 

[FACETS]

yep this is how it works. the WIF is for any database for that PC profile. Limitations are put on an individual by the "ADMIN" of that database seting the restrictions in "USER AND GROUP PERMISSIONS"

 

[RickSpr]

Some more information:

Your analysis is correct: a database is not attached to any specific WIF. The user specifies which WIF to use by "joining" a workgroup, using the Workgroup Administrator utility.

The concept was that an enterprise would create a separate WIF for each department or similar unit (the "workgroup", hence the name) and that permissions for a given database would be set up in each WIF separately, if any of the users defined in that WIF should have non-default ("USERS" group) permissions on the database. This department-centric approach to WIF creation works very well where security is centrally or departmentally administered. For the user, once they join the appropriate WIF for their workgroup, there is no longer any need to use the Workgroup Administrator, because the last WIF selected remains in effect forever.

In practice, many installations use a separate WIF for each database, presumably because security administration winds up being the responsibility of the developer or the application owner. This complicates things because a given user often needs to have an account in each of several WIFs, and to switch WIFs before opening each database.

You can create desktop or start menu shortcuts that specify a particular WIF to use when opening a database, by including the /wrkgrp command-line argument when starting Access. This temporarily overrides the joined workgroup, just for the one instance of Access that's being opened. Many installations use these shortcuts, or equivalent .BAT files, to make it easier on the user. However, if the user double-clicks on the database itself, the currently joined WIF will still be used and the user will probably not be able to log on or will not get the correct permissions.

You are right that the user can use the default system.mdw file to evade security--if you haven't set up the security correctly. By default, the Admin user is a member of the Administrators group, and is also the default owner of all databases and objects. This allows Admin to make the changes necessary to reassign ownership and permissions when securing a database. (In reality, the security system is always active, but until you "secure a database", Admin has full permissions so you never see the security working.) But it also implies that Admin has to have all this power revoked at the end of the security setup, because the Admin user can't be deleted from the system (Access uses the presence or absence of Admin's password to determine whether to display the startup logon dialog) and is the same in every WIF.

The correct setup involves changing the owner of the database and of all the objects in it to something other than the Admin user, removing the Admin user from the Administrators group in the WIF, and removing any permissions of the Admin user on the database and its objects. This is very detailed and complicated to do manually, so you should use the User-Level Security Wizard.

It's also crucial that the Administrators group in a secure WIF not be the same as that in the default system.mdw. If it is, then anybody with a default WIF will be able to give him/herself permissions in any database that was secured with the non-default WIF. To ensure that the Administrators group is different, the WorkgroupID you specify when creating the secured WIF must be different from the WorkgroupID specified (or defaulted) when Access was installed. (This WorkgroupID must be kept secret.)

You suggested that it would be better if Access determined the WIF on the basis of the database being opened. That approach could work ok in an environment where security is administered by the developer or application owner, but where security is partly or fully centralized it would force the SecAdmin to jump from WIF to WIF when setting up a new hire or removing a terminated employee. No solution seems to work best for all environments. It's no surprise that MS would choose the solution that works best for larger enterprises with more centralized security--they represent bigger profit potential.

There's also the problem of the chicken or the egg. If the location of the WIF were stored in the database, Access would have to open the database to find out where the WIF is--but Jet won't let Access open the database until it checks the logon user's permission. So you have to look up the user in the WIF before you open the database to discover where the WIF is. The only way around this would be to use some kind of file/folder naming convention to associate a database with a WIF, which wouldn't be very flexible.

One final note: There is a subtle problem that becomes possible when separate WIFs are used for each database. A given user, say "Rick", can be (and often will be) defined separately in several WIFs for databases he uses. If security isn't centralized, it's likely that Rick's PID (Personal ID) will be different in each WIF. Unfortunately, to Jet these are different users who happen to have the same name. Typically, Rick will keep his passwords the same for all his databases, to make logon easier. So whichever WIF he's currently joined to, Rick sees the same logon box and enters the same information. If he happens to be joined to the wrong WIF when he opens a database, Jet will see him as a different user with no permissions in this database, and the application will reject or restrict his abilities. Rick doesn't know he's joined to the wrong workgroup, so he complains to the developer/application owner--who checks his permissions against the correct WIF, naturally, sees that they're correct, and is totally stumped why they don't seem to be working. This problem can be a big time waster!

I hope this explains what you were asking.

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[Toby1kenobe]

Hi

Thanks Rick, this is helping me also. I'm just earwigging!

If i install my DB on the target Network and Secure it, will it make all other DB's they might have use my passwords?

What i want to do is set up security on this machine, create a new WIF, put this file and my DB on the target network then point my DB to it (using a batch file like you suggest, which would meet my needs). Can i do this and will affect the Access stuff on the target network?

Thanks, sorry again for butting in!

Toby

 

[RickSpr]

Toby,

Yes, you can do what you described, and no, it won't interfere with other databases or their security setups. As long as your WIF is on the network with your database, and the batch file/shortcut uses the /wrkgrp switch to specify your WIF, each user's default WIF (set in the Workgroup Administrator program) will be the same as it was before. They can even have your database and another one, using their default WIF, open at the same time (in different instances of Access, of course) and there will be no interference.

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein