Workgroup files and Open/Run in 2002

  • Thread starter Thread starter Ronald Dodge
  • Start date Start date
R

Ronald Dodge

After the various reading up that I have done for the security side of
Access and what I see so far, I want to have these 2 things cleared up.

Open/Run permission

Was this issue resolved in 2002 entirely?

From what I see in the permissions themselves, the Open/Run permission is
uncheckmarked for every single usergroup, but yet, according to
documentations for Access 2000, this appearance of being unchecked wasn't
necessarily true. Had to disable this via code.



Workgroup files:

From what I see from others, if one is using a SECURED workgroup file, when
openning another DB (which in this case would be the BE side as I have a
total of 5 BE DBs), does this mean from the secured group, it would ask for
a password each and everytime a DB file is open within the same session?

According to what I read in the white papers, this would be a yes, and to
use the UNSECURED workgroup file, but if one is using an UNSECURED workgroup
file, how is this really protecting the data and structure?
 
Ronald said:
After the various reading up that I have done for the security side of
Access and what I see so far, I want to have these 2 things cleared
up.

Open/Run permission

Was this issue resolved in 2002 entirely?
Yes


Workgroup files:

From what I see from others, if one is using a SECURED workgroup
file, when openning another DB (which in this case would be the BE
side as I have a total of 5 BE DBs), does this mean from the secured
group, it would ask for a password each and everytime a DB file is
open within the same session?
Click to expand...

No. The workgroup is attached to the session, not the mdb. If you open a
session using your secured mdw, you'll be prompted once for a
username/password for that session. You can open as many databases as you
like, as long as the username you are logged in as, has permissions to open
those databases. Note that if you open a database that has not been
secured, you'll have no problems. This is because your username is a member
of the Users group, and the Users group is common to all workgroups. In an
unsecured database, the Users group has full permissions, so you can open it
no problem.

To secure the backend, you would secure it using the same workgroup file
that used to secure the frontend.
 
Thank you for the update as this makes a lot more sense to me than what I
read in 1 of the links that was provided to me when dealing with Access
Security system. The way I read that one link, dealing with the link of
http://www.geocities.com/jacksonmacd/AJMAccessSecurity.pdf, it looked to me
as if I'm to join the Default workgroup file as stated on page 15 of the
link, and not the secured one. That particular paragraph didn't make sense
to me from a sound security point of view. I ended up having to disregard
it. I have all 6 of my DB files using the same workgroup file. The only
other thing that I have done, given this is across multiple sites, each site
will have their own copy of the same workgroup file so as not to slow down
the process.
 
Ronald said:
with Access Security system. The way I read that one link, dealing
with the link of
http://www.geocities.com/jacksonmacd/AJMAccessSecurity.pdf, it looked
to me as if I'm to join the Default workgroup file as stated on page
15 of the link, and not the secured one. That particular paragraph
didn't make sense to me from a sound security point of view.
Click to expand...

Actually what it was referring to, is what your *default* workgroup file is.
Every session of Access uses a workgroup file, whether your database is
secured or not. Out of the box, when you open an Access session you are
using the standard system.mdw workgroup file, and you are silently logged in
as the 'Admin' user - which owns all objects and has full permissions to
everything.

Jack's point was that if you have unsecured databases, but are joined *by
default* to your secure mdw, then you'll get a login prompt for the unsecure
databases. Normally one would leave system.mdw as your default workgroup,
and use a desktop shortcut to launch your secure databases. The shortcut
would include the /wrkgrp switch to specify the workgroup. That would
override your default workgroup *for just that session*.

By the way if you are even able to open your secure database, while joined
to the standard system.mdw, then your database isn't secure.
I ended
up having to disregard it. I have all 6 of my DB files using the
same workgroup file. The only other thing that I have done, given
this is across multiple sites, each site will have their own copy of
the same workgroup file so as not to slow down the process.
Click to expand...

That's fine, but are your 6 databases the only ones that users will use?
They may not want to login using your secure mdw for other non-secure mdb
files.
 
Sorry for the long delay as I have been working on setting up forms in my FE
file. Not only that, but pressured to get this done ASAP like by the start
of next month.
By the way if you are even able to open your secure database, while joined
to the standard system.mdw, then your database isn't secure.
Click to expand...

What needs to be done to prevent the Admin user going into the secured
database in Access 2002? After all, it's a default account, and it can't be
deleted for that reason. It's in the Users group, which that can't be
deleted and not only that, but from what I understand, the Admin account
can't even be taken out of the Users group. All users must be in the Users
group in order to open the database.

However, what I have done, I have removed all permissions to everything in
all 5 of the BE files for the Users group. The other person who's helping
me out some with this project (this project was actually assigned to him,
but with him having limited knowledge, the IT department turned to me to
help since I'm the most qualified within the company to work in Access), was
able to get into the FE file without any problems via the default workgroup
file. Security was the main area that I didn't get too much into until
these last 2 weeks, when I was basically given this project. Up to this
point of time, I worked on planning out an MRP type DB system, setup the
table structures down to the NF5 form, and also get some of the FE side to
be functional. BTW, given how the Error Checking is done in Access for
bound forms, this creates problems for mouse users, so I had to unbind my
forms and controls, and also create my own modulated error checking
procedures immulating the error checking procedures in VB6 like the
CausesValidation Property and the Validate Event.
That's fine, but are your 6 databases the only ones that users will use?
They may not want to login using your secure mdw for other non-secure mdb
files.
Click to expand...

Before you even brought this up and as he was able to get into the FE file
silently via the default workgroup file, thus no password came up, I
mentioned to him of that very fact. I did mention to him that we could
alleviate this issue by going through the Security menu *on each
individual's computer* to join the workgroup file that these 6 DB files are
for, but also pointed out to him, if we were to do that and they required to
go into any other DB files such as any that's unsecured, that would create
an issue for the same type of reason that you pointed out here.

Now when he did create the shortcut and used the syntax that I explained to
him, he did get a username and password pop up dialog box.
 
Ronald said:
Sorry for the long delay as I have been working on setting up forms
in my FE file. Not only that, but pressured to get this done ASAP
like by the start of next month.


What needs to be done to prevent the Admin user going into the secured
database in Access 2002? After all, it's a default account, and it
can't be deleted for that reason. It's in the Users group, which
that can't be deleted and not only that, but from what I understand,
the Admin account can't even be taken out of the Users group. All
users must be in the Users group in order to open the database.
Click to expand...

The default group "Users" must have zero permissions and the default user
"Admin" must be removed from the "Admins" group and must not own anything.
That last thing "Ownership" is what most people screw up when setting up
security because owners have permissions above and beyond those that you see
in the permission settings.

If everything is done properly the user "Admin" will not be able to open the
file regardless of the workgroup file being used.
 
Uhm, Rick,

Did you miss something?

The DEFAULT workgroup isn't going to have the Admin user removed from the
Admins group. The secured workgroup file does.

Ownership: I had already taken ownership of all the DB files with my own
superuser account name including the DB file itself by following through the
steps of creating a new DB file with my own user account, and then import
all objects from the OLD DB file to the new one, which then I removed all
permissions from the Users group along with modifying the permissions while
I was in there to other groups.

What we are getting at, how do you prevent the DEFAULT workgroup from
allowing the Admin user getting into the FE DB file, cause remember, when
you have multiple users, they all have the DEFAULT workgroup file BY
DEFAULT, and unless someone goes through the deal of removing such file from
each individual PC and force them to join the secured workgroup, which that
in turn could also cause some other issues too, so there has to be a way to
prevent the admin user of the DEFAULT workgroup without necessarily changing
it in the DEFAULT workgroup and still prevent them from getting into the
secured DB file.
 
Ronald said:
Uhm, Rick,

Did you miss something?

The DEFAULT workgroup isn't going to have the Admin user removed from
the Admins group. The secured workgroup file does.
Click to expand...

The group "Admins" has the same name in different workgroup files, but not
the same PID. So even though a person using the default System.mdw will
show Admin as a member of the Admins group the database won't consider that
the "correct" Admins group and will still evaluate him based solely on the
individual account Admin and his membership in the group Users.
Ownership: I had already taken ownership of all the DB files with my
own superuser account name including the DB file itself by following
through the steps of creating a new DB file with my own user account,
and then import all objects from the OLD DB file to the new one,
which then I removed all permissions from the Users group along with
modifying the permissions while I was in there to other groups.
Click to expand...

That should have done it.
What we are getting at, how do you prevent the DEFAULT workgroup from
allowing the Admin user getting into the FE DB file, cause remember,
when you have multiple users, they all have the DEFAULT workgroup
file BY DEFAULT, and unless someone goes through the deal of removing
such file from each individual PC and force them to join the secured
workgroup, which that in turn could also cause some other issues too,
so there has to be a way to prevent the admin user of the DEFAULT
workgroup without necessarily changing it in the DEFAULT workgroup
and still prevent them from getting into the secured DB file.
Click to expand...

I can only tell you that when all the steps are done properly the default
workgroup WILL NOT allow access to the file. Somewhere something is still
incorrect.
 
The group "Admins" has the same name in different workgroup files, but not
the same PID. So even though a person using the default System.mdw will
show Admin as a member of the Admins group the database won't consider that
the "correct" Admins group and will still evaluate him based solely on the
individual account Admin and his membership in the group Users.
Click to expand...

Yes, the Admins group has different SIDs (I do believe that is what you
meant) for different workgroups, but remember, it only takes the Users group
to open up the DB file. This is a requirement for a user to be able to open
the DB file, they must be in the Users group. Secondly, since both, the
Admin user and the Users group have the same SIDs for every single workgroup
file that's out there, this is the hole that still exists which allows the
file to be openned by the admin user of a default workgroup file. Source of
reference for this information is:

http://www.geocities.com/jacksonmacd/AJMAccessSecurity.pdf Pages 8 and 15.

The one thing that wasn't checked out was if the admin user could do
anything after it openned the DB file, which I suspect no, cause all
permissions been locked out. But in this case, I'm talking about the mere
fact that it can open the DB file. Page 15 of the above reference only
talks about using objects, not about opening up the DB file. Note: Even
though the DB file itself is an object, there is no dialog box to set
permission on the DB file itself like there is for the DB objects in the DB
file.
 
Ronald said:
Yes, the Admins group has different SIDs (I do believe that is what
you meant) for different workgroups, but remember, it only takes the
Users group to open up the DB file.
Click to expand...

The "Users" group does NOT need to have permissions to open the file. That
permission should be explicitly removed. While it is true that all users
(lower case intended) need to be able to open the file they should acquire
that permission by virtue of being a member of some other group besides
"Users". It is absolutely true that if "Users" has permission to open the
file then ANY user will be able to open it with ANY workgroup file.
This is a requirement for a user
to be able to open the DB file, they must be in the Users group.
Click to expand...

It is a requirement that all users be in the Users group but this is not
required for them to open the file. It is just impossible for them NOT to
be in this group. As long as that group has zero permissions it is not
relevant to the issue.
Secondly, since both, the Admin user and the Users group have the
same SIDs for every single workgroup file that's out there, this is
the hole that still exists which allows the file to be openned by the
admin user of a default workgroup file. Source of reference for this
information is:
http://www.geocities.com/jacksonmacd/AJMAccessSecurity.pdf Pages 8
and 15.
Click to expand...


I just read that page and that is NOT what is says. It says that the user
Admin is the same in all workgroups but that groups (except for "Users") are
not the same (which is why Admin must be stripped of all permissions).
 
--
Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000

Rick Brandt said:
The "Users" group does NOT need to have permissions to open the file. That
permission should be explicitly removed. While it is true that all users
(lower case intended) need to be able to open the file they should acquire
that permission by virtue of being a member of some other group besides
"Users". It is absolutely true that if "Users" has permission to open the
file then ANY user will be able to open it with ANY workgroup file.
Click to expand...

Then how do you remove this permission as there's no objects shown in the
permissions dialog box that deals with the DB File Object. Remember, I
already did the ownership thing.
It is a requirement that all users be in the Users group but this is not
required for them to open the file. It is just impossible for them NOT to
be in this group. As long as that group has zero permissions it is not
relevant to the issue.
Click to expand...

In the Access 2000 Security FAQ, Section 38, Page 34, it does imply that the
user "MUST" be in the "Users GROUP" before the user can have access to the
file as quoted below by the very question it asks:

"38. I created a user in code but the user isn't in the Users group
and can't start Microsoft Access

The most likely cause of this is that you need to add the user to the Users
group as a separate step in your code. When you create a user through the
user interface, this step is taken care of for you automatically. The
following function will create a new user account and add it to the Users
group."

By the way this is asked and answered, the user isn't able to open Access
(the application file, thus can't open the DB file), but the moment the user
is put in the "Users" group, the user can then open Access, which then
allows the user to open the DB file.
I just read that page and that is NOT what is says. It says that the user
Admin is the same in all workgroups but that groups (except for "Users") are
not the same (which is why Admin must be stripped of all permissions).
Click to expand...

Geesh, looks like you didn't read my statement too well as you just repeated
what I said. I did say "Admin USER" and "Users GROUP" both have the same
SIDs in all workgroups. This didn't imply that *ALL* or *ANY OTHER* groups
have the same SIDs.
 
Ronald said:
Then how do you remove this permission as there's no objects shown in
the permissions dialog box that deals with the DB File Object.
Remember, I already did the ownership thing.
Click to expand...

The "Database" object handles this. If you have zero permissions to the
database you are not allowed to open the file.
In the Access 2000 Security FAQ, Section 38, Page 34, it does imply
that the user "MUST" be in the "Users GROUP" before the user can have
access to the file as quoted below by the very question it asks:
Click to expand...

I don't know why it would make that statement because it is impossible to remove
a user from the Users group. What permissions a user would or would not have
were they to be removed from the Users group is a meaningless thing to discuss
since they cannot be removed from that group.
 
DOH, I could shoot myself for this, I didn't change the "Object type" drop
down for the different types of object. I must have been out of it to not
notice that before, but then working on average, 4 to 5 hours of sleep each
night and working 12 hour days doesn't help. Even the DB file object is
included in that list.

Anyhow, you right, it's impossible to remove users from the "Users" group,
but what that statement was getting at, it is possible to add a user to the
list of users without adding to the "Users" group, when done via code.
 
Back
Top