MDE file/Security Groups Operation

[Casey]

Can an MDE secured database operate freely as far as
being able to add and delete users from already achieved
groups. I have a program that I am about to change to an
MDE file, and have security groups already built. Also, I
have forms in that program which allow the user to change
a password. For the administrators, I have forms which
allow adding and deleting of user accounts related to
already achieved groups, and creating new accounts and
adding them to groups. The reason I am making the file
MDE is because I do not want the administrators that are
able to deal with security be able to change my objects of
the program (forms, reports, macros, table structures and
so on. Will the changing the program to an MDE file
affect the the security account changing action related
capability of the program as it is now?

I appreciate any second opinions.

Thank you,

Casey

Casey

 

[TC]

MDEs have no affect on security. They just stop you viewing or changing the
design of forms, reports, etc.

In passing, you might not realize the following fact.

If certain users must be able to create new users, reset passwords, & so on,
it is actually not necessary for them to be members of the Admins group.
Instead, they can be *non* Admin users who have permission to execute a code
module which:
- uses the CreateWorkspace method to create a workspace for a "hidden" admin
username/password, then
- executes the relevant VBA statements (CreateUser etc.) via that workspace.

By that means, selected non-privilged users can execute priviliged
operations under program control. Of course, you must stop those uses from
viewing the program code, otherwise they will be able to see the "hidden"
Admins username/password, & log on manually with that username/password! One
way to stop them viewing the code is, to make the database an MDE.

Googling for CreateWorkspace will doubtless tell you more about this.

HTH,
TC

 

[Casey]

Thank you TC. I appreciate the advice.

Casey

-----Original Message-----
MDEs have no affect on security. They just stop you viewing or changing the
design of forms, reports, etc.

In passing, you might not realize the following fact.

If certain users must be able to create new users, reset passwords, & so on,
it is actually not necessary for them to be members of the Admins group.
Instead, they can be *non* Admin users who have permission to execute a code
module which:
- uses the CreateWorkspace method to create a workspace for a "hidden" admin
username/password, then
- executes the relevant VBA statements (CreateUser etc.) via that workspace.

By that means, selected non-privilged users can execute priviliged
operations under program control. Of course, you must stop those uses from
viewing the program code, otherwise they will be able to see the "hidden"
Admins username/password, & log on manually with that username/password! One
way to stop them viewing the code is, to make the database an MDE.

Googling for CreateWorkspace will doubtless tell you more about this.

HTH,
TC






.

 

[Albert D. Kallal]

You are correct, as along that those security settings you change are NOT in
the mde.

Often, when new to setting up security, people start assigning what form
belongs to what users. You really don't want to do that, since when you
update, or change security, you need to re-distribute a new mde to each
user.
(or worse, existing settings will be lost when you update to a newer
version).

So, yes, you do want to be most careful here. As long as you only create
users, and assign those users to security groups, then you will have no
problems. If you start assigning users to actual forms, then those settings
exist in the mde file, and that is no good....

 

[TC]

You are correct, as along that those security settings you change are NOT in
the mde.

Often, when new to setting up security, people start assigning what form
belongs to what users. You really don't want to do that, since when you
update, or change security, you need to re-distribute a new mde to each
user. (or worse, existing settings will be lost when you update to a newer
version).

So, yes, you do want to be most careful here. As long as you only create
users, and assign those users to security groups, then you will have no
problems. If you start assigning users to actual forms, then those settings
exist in the mde file, and that is no good....

Sorry, but none of that is true.

The MDB (or MDE) contains a system table along the following (simplified)
lines:

Object SID Permissions
MyForm 123 View, Add, Delete
MyTable 456 View only
etc.

Absent any workgroup file, the MDB (or MDE) can not possibly know which (if
any) of those SIDs are for users, and which (if any) are for groups.

Then, the selected workgroup file provides the SID for each user & group
defined in that workgroup file:

Name Type SID
Dick user 123 << 123 is a USER
Clerks group 456

But, in theory, a different workgroup file might say:

Name Type SID
Males group 123 << 123 is a GROUP
Clark user whatever

So it isn't the case that user & group permissions are stored in "different
places". They are *both* stored as the conjunction of:
- an object/SID/permissions matrix in the MDB/MDE, and
- a name/type/SID matrix in the selected workgroup file.

Of course, there are definite pro's & con's to assigning permissions to
users, as opposed to assigning them to groups - but that does not seem to be
what you are saying here.

TC

 

[TC]

So in the absence of any rebuttal,

"I rest my case, your honour!"

TC