"Jeff Schneider" <JeffSchnei***@discussions.microsoft.com> wrote in message
news:D78DCCB8-C539-430E-887C-5D83433C2231@microsoft.com...
> 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?

"Joan Wild" wrote:

> 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.
> --
> Joan Wild
> 520630
> "Jeff Schneider" <JeffSchnei***@discussions.microsoft.com> wrote in message
> news:D78DCCB8-C539-430E-887C-5D83433C2231@microsoft.com...
> > 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?
>
>
>

"Jeff Schneider" <JeffSchnei***@discussions.microsoft.com> wrote in message
news:0CC207B1-B3AD-4C0D-AEA9-DBA2E326A6BD@microsoft.com...
> 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.
>
> "Joan Wild" wrote:
>
>> 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.
>> --
>> Joan Wild
>> 520630
>> "Jeff Schneider" <JeffSchnei***@discussions.microsoft.com> wrote in
>> message
>> news:D78DCCB8-C539-430E-887C-5D83433C2231@microsoft.com...
>> > 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?
>>
>>
>>

"Paul Overway" wrote:

> What are the permissions on the file/folder holding the MDW?
>
> --
> Paul Overway
> Logico Solutions
> http://www.logico-solutions.com
>
>
> "Jeff Schneider" <JeffSchnei***@discussions.microsoft.com> wrote in message
> news:0CC207B1-B3AD-4C0D-AEA9-DBA2E326A6BD@microsoft.com...
> > 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.
> >
> > "Joan Wild" wrote:
> >
> >> 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.
> >> --
> >> Joan Wild
> >> 520630
> >> "Jeff Schneider" <JeffSchnei***@discussions.microsoft.com> wrote in
> >> message
> >> news:D78DCCB8-C539-430E-887C-5D83433C2231@microsoft.com...
> >> > 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?
> >>
> >>
> >>
>
>
>

"TC" wrote:

> 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.
>
> 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
>
>

"TC" wrote:

>
> Jeff Schneider wrote:
>
> > We all used the same shortcut, how could that not point to the same
> 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.
>
> 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
>
>

"TC" wrote:

> 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
>
>

"TC" wrote:

> 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
>
>