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

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" <(E-Mail Removed)> wrote in message
news:028801c369de$f06cbc60$(E-Mail Removed)...
> 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?

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
>
>
>"Casey" <(E-Mail Removed)> wrote in message
>news:028801c369de$f06cbc60$(E-Mail Removed)...
>> 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?
>
>
>
>.
>

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


--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.attcanada.net/~kallal.msn

"Albert D. Kallal" <(E-Mail Removed)> wrote in message
news:yHb2b.19779$(E-Mail Removed)...

> 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

So in the absence of any rebuttal,

"I rest my case, your honour!"

TC