Security file not holding changes

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Sorry - this is long.

I sent a copy of a database (split) I made for my office (and that works
fine) to another one of our offices. I sent the same .mdw file as ours, but I
first removed all the users except for myself and the admin user I created
(not the default Admin). I left all of the Groups permissions I created
intact.

My counterpart in the other office updated the linked tables to point to the
copy on his server - not ours. Then he added users and assigned them to the
appropriate groups. These users were able to log into the DB, but did not
have permissions to the objects that their Group should have. Looking deeper
into it, we could see that the Group permissions had changed from what I
first sent. No, problem. I walked him through it over the phone and reset
them.

The users still didn't have permissions. Checking the User & Group
Permissions again - none of the changes we made were there! I even went so
far as to map to his server, log in as myself (w/ admin rights) and made the
changes myself. Logged off, logged back into the DB and checked that the
permissions were still there - and they were there.

A user logged in again but was denied access to the restricted objects. I
checked the Group Permissions I added but once again they were changed!
Anytime an admin user makes a change and a non-admin user logs in, the Group
Permissions revert back to the old settings. Is this one of those "features"
I've heard about?
 
I have never heard of this. It sounds as though different workgroup files
are at play here. You are using a different workgroup file than you think,
and/or a different mdb file.
 
I'm not sure how that could happen. The shortcut we are all using joins us to
the mdw file - that I can verify by seeing the list of users loaded by my
counterpart. The front end mdb would be a different file, though, since a
copy is saved in each person's desktop workstation, but the tables are all
linked to the same back end mdb on the server. How would having separate
front end mdb files affect the security? They are all copies of the same mdb.
Also, I thought all the security info was contained in the mdw file.
 
As Joan says, there's no way that permissions change for no reason.

You've not said how you are staring the database. Perhaps some users
are double-clicking it - which would use the default workgrup file on
that PC, regardless of them having a copy of yours - but other uses are
using a shortcut with the /wkgrp switch?

HTH,
TC
 
Jeff Schneider wrote:

(snip)
The shortcut we are all using joins us to
the mdw file - that I can verify by seeing
the list of users loaded by my counterpart.
Click to expand...

That /does not/ verify what file you are using. You might have two
files with the same users and groups. But if Fred in file #1 has a
different PID to Fred in file #2, those two Freds are /two different
users/, from an Access security viewpoint.

Try this to be /sure/ what workgroup file you are using:

msgbox dbengine.systemdb

HTH,
TC
 
We all used the same shortcut, how could that not point to the same mdw?

I did use your 'msgbox dbengine.systemdb' suggestion and confirmed that
we're all joining the same mdw when we log in.
 
There are only 5 users loaded so far (one for each Group), and it's the other
office's admin who's logging in each of the users through a shorcut with a
/wkgrp switch.
 
Jeff said:
We all used the same shortcut, how could that not point to the same
Click to expand...
mdw?

But you said that the reason you were certain they were using the same
workgroup file, was, that the list of users was the same. I just
pointed out, that this is not a good-enough reason to draw that
conclusion. And even if they have the same shortcut, maybe one of them
is double-clicking the database file, ie. not using the shortcut at
all.
I did use your 'msgbox dbengine.systemdb' suggestion and confirmed that
we're all joining the same mdw when we log in.
Click to expand...

Ok, /now/ you can be sure that they are using the same workgroup file
(assuming that you did the msgbox from every database - not just one of
them!).

Cheers,
TC
 
Are any of the Group Permissions saved as part of the mdb file? Or is
/everything/ security or permissions related saved to the mdw file?
 
Hi Jeff

Those are very good questions :-)

Briefly:

The WORKGROUP file contains:
- the user & group names;
- the encrypted user passwords, and
- the relationship between users and groups.

The workgroup file also contains a so-called Security Identifier (or
SID) for each user and group. This is the key linkage value between the
workgroup file, and the database file. Note that the workgroup file
DOES NOT have any knowledge of the objects in the secured database, or
what permissions are applied to those objects.

The DATABASE file contains a matrix defining which SIDs have what
permissions to which objects in that database. The database DOES NOT
contain the actual names of the user or groups - only their SIDs. As
you can see, the SID is a critical linkage between the two files.

The SID-based scheme is very clever - plugs some potential security
holes - and has some important advantages when there are different
users with the same names. You can find out more about these issues by
googling on posts from me containing the following terms: PID SID
MSYSACES

HTH,
TC
 
That was the piece of the puzzle I needed!

The changes we were attempting to make were on the Front End copy of the
database (on my own hard drive), so none of the user copies got the changes.

I had the other users re-install the FE copy after I made the changes and
everyone's set now.

Thank you all for your help!
 
Back
Top