Mystery security group setting changes.

29 Nov 2006 10:43 PM

eagle

When I first set up user-level security, I removed Admin user from Admins
group, and removed all permissions from Admin user. I also removed all
permissions from Users group. Today (2 years later) I noticed Admin user was
back in the ADMINS group. How can this happen? I mentioned this to the top
IT person here, and she says that when microsoft updates and service packs
are installed, it can cause stuff to go back to default settings. This
doesn't make sense to me because the workgroup file is a separate file (like
a doc) and that is where the changes were made. Can updates and service pack
installs make changes to a workgroup file like that? Even if, wouldn't it
reset all the groups and users I created back to nothing?

Anyway, if the Admin user were successfully removed from ADMINS group, HOW
could it get back in there? This is what I need to know. I am the database
developer/administrator/support/everything. Thanks. :-)

30 Nov 2006 4:16 PM

Joan Wild

Updates can sometimes set your default mdw back to factory i.e. back to
system.mdw that ships with Access. And in that mdw Admin is a member of the
Users Group. Are you certain of the mdw file you are using? You can double
check by opening Access, hitting Ctrl-G and typing DbEngine.SystemDb

--
Joan Wild
Microsoft Access MVP

Show quoteHide quote

"eagle" wrote:

> When I first set up user-level security, I removed Admin user from Admins
> group, and removed all permissions from Admin user. I also removed all
> permissions from Users group. Today (2 years later) I noticed Admin user was
> back in the ADMINS group. How can this happen? I mentioned this to the top
> IT person here, and she says that when microsoft updates and service packs
> are installed, it can cause stuff to go back to default settings. This
> doesn't make sense to me because the workgroup file is a separate file (like
> a doc) and that is where the changes were made. Can updates and service pack
> installs make changes to a workgroup file like that? Even if, wouldn't it
> reset all the groups and users I created back to nothing?
>
> Anyway, if the Admin user were successfully removed from ADMINS group, HOW
> could it get back in there? This is what I need to know. I am the database
> developer/administrator/support/everything. Thanks. :-)

30 Nov 2006 6:56 PM

eagle

The .mdw file I use for this workgroup is called "share.mdw" and the default
mdw is called "system.mdw." Sometimes when there are updates, a few users'
computers get set back to the default system.mdw -- but I'm talking about
changes taking place in the workgroup file I created, share.mdw. Nothing has
ever changed, before, in the share.mdw file, even after updates -- but now,
suddenly the Admin user rejoined the ADMINS group within share.mdw. I don't
think installing updates can change the contents of the mdw file I created
(share.mdw), right? This share.mdw file has been in use for over 2 years (I
created it), and this is the first time I've seen the Admin user mysteriously
rejoin the ADMINS group. There are only two users who are part of the
ADMINS group: myself and the IT manager. I am the one who does all the
development, security, etc., and the manager knows Access, but doesn't really
do anything with the data system. But yesterday, I found the Admin user also
in this ADMINS group -- and was shocked to see it there -- and this is all in
the Workgroup called share.mdw. So I'm not talking about access reverting
back to the default system.mdw file, but rather a change occuring within the
share.mdw file I created as a security workgroup for our data system. Does
this make better sense?

Show quoteHide quote

"Joan Wild" wrote:

> Updates can sometimes set your default mdw back to factory i.e. back to
> system.mdw that ships with Access. And in that mdw Admin is a member of the
> Users Group. Are you certain of the mdw file you are using? You can double
> check by opening Access, hitting Ctrl-G and typing DbEngine.SystemDb
>
> --
> Joan Wild
> Microsoft Access MVP
>
>
> "eagle" wrote:
>
> > When I first set up user-level security, I removed Admin user from Admins
> > group, and removed all permissions from Admin user. I also removed all
> > permissions from Users group. Today (2 years later) I noticed Admin user was
> > back in the ADMINS group. How can this happen? I mentioned this to the top
> > IT person here, and she says that when microsoft updates and service packs
> > are installed, it can cause stuff to go back to default settings. This
> > doesn't make sense to me because the workgroup file is a separate file (like
> > a doc) and that is where the changes were made. Can updates and service pack
> > installs make changes to a workgroup file like that? Even if, wouldn't it
> > reset all the groups and users I created back to nothing?
> >
> > Anyway, if the Admin user were successfully removed from ADMINS group, HOW
> > could it get back in there? This is what I need to know. I am the database
> > developer/administrator/support/everything. Thanks. :-)

30 Nov 2006 8:09 PM

Joan Wild

eagle wrote:

> The .mdw file I use for this workgroup is called "share.mdw" and the
> default mdw is called "system.mdw." Sometimes when there are
> updates, a few users' computers get set back to the default
> system.mdw -- but I'm talking about changes taking place in the
> workgroup file I created, share.mdw. Nothing has ever changed,
> before, in the share.mdw file, even after updates -- but now,
> suddenly the Admin user rejoined the ADMINS group within share.mdw.
> I don't think installing updates can change the contents of the mdw
> file I created (share.mdw), right?

Right.I have never heard of spontaneous changes in the mdw file.

> There are
> only two users who are part of the ADMINS group: myself and the IT
> manager. I am the one who does all the development, security, etc.,
> and the manager knows Access, but doesn't really do anything with the
> data system.

One of you *must* have made the change. I'll just say that it's often that
the user that knows 'just a bit', knows enough to do damage (even
unknowingly).

--
Joan Wild
Microsoft Access MVP