Workgroup File

[Rick Brandt]

Hi Rick,

I made a copy of the update.mdw (custom workgroup) and placed it out
on the network in the same location as the db. I copied secured path
and pasted it into the Customer shortcut and renamed update.mdw to
customer.mdw. See below.

C:\Program Files\MicrosoftOffice\Office\MSACCESS.EXE" "G:\HAP Shared
Data\MBI Projects\request.mdb" /wrkgrp "G:\HAP Shared
Data\MBIProjects\customer.MDW"

Then I cleared the password on the Admin user. Now the customers are
joining with the secured .mdw and don't have to log in. Everyone is
using the same .mdw and getting the permissions I gave them (i think).

When I check the permissions using the Customer shortcut it logs me
in as Admin. It's working on our desktops and gives the Admin user
the permissions they should have without them having to log in.

Does this sound like the way I should be setting this up out on the
intranet when it's deployed to the company?

Thanks for your previous response. I really appreciate all of the
help this forum has provided! I wouldn't have gotten this far without
your help and expertise. Thanks again.

As I stated before, if you want the base level user to not have to be log in
then you simply give the base level of permissions to either the "Admin"
user or to the group "Users" and then they can run your file with ANY mdw
file and they will be granted those permissions. As such I see no need to
add the complexity of making them use a specific MDW file since that MDW
file is gaining you nothing in terms of how the app will work for them.

 

[Guest]

I'm sorry. I'm not trying to be thick but I don't understand.

Where in the application do I give the User group the permissions when they
use any .mdw? When another user opens the db with their system.mdw they get
all of the permissions because the .mdw doesn't reside on the network. I've
assigned the minimal permissions to the User's group in my custom .mdw.

Please be patient with me.
I really appreciate your time.

 

[Rick Brandt]

I'm sorry. I'm not trying to be thick but I don't understand.

Where in the application do I give the User group the permissions
when they use any .mdw? When another user opens the db with their
system.mdw they get all of the permissions because the .mdw doesn't
reside on the network. I've assigned the minimal permissions to the
User's group in my custom .mdw.

The key here is that the Users group is the same in ALL mdw files. Whatever
permissions you give to the Users group in your MDB file will be granted
regardless of which mdw file they use. The Users group is unique in this
regard. The "Admins" group for instance is not the same in all MDW files,
but it is the same in all of the System.MDW files that are created by Access
or the Office install program.

By "the same" I mean that they have the same PID value which means than all
MDB files will consider them to be identical.

 

[Guest]

Thanks, I understand.

Is there a way to determine what the PID is for the Admin user that is
generated when Access is installed? If so, then how do I make the Admin PID
the same in my MDB?

Thanks for your time & patience. I'm more of a sponge than a rock

 

[Rick Brandt]

Thanks, I understand.

Is there a way to determine what the PID is for the Admin user that is
generated when Access is installed? If so, then how do I make the
Admin PID the same in my MDB?

I don't understand why you need this. I'm not sure, but the PID for the
default Admin user might already be universal.

The "usual" goal when assigning permissions to the "Users" group is so you
can just pass out your MDB file to your normal users and they can use it
without any regard for the workgroup file they might use. However the
permissions granted to Users in this case is limited and in order for
someone to have higher authority they must use a special workgroup file.

Many developers do this so that they can sign in with a secured MDW to
perform design changes, but "any old workgroup" works for data entry and
viewing.

What exactly is your reason for giving the Users group permissions? If it's
so they don't need to log in then they don't need a custom workgroup file
either. There is no way to not require a login and still require a custom
workgroup file (other than to include the login info in a shortcut).

 

[TC]

The Admin user PID is irrelevant. PIDs are used internally, together
with the user name, to generate the SID (Security Identifier) for that
user. But the Admin user is given the same SID, universally, in all
workgroup files.

HTH,
TC

 

[Guest]

Then in theory there is no reason that this shouldn't work the way I have it
set up because I have the Admin user assigned to the Users group and the
Users group can only open the db, insert records and view records. When I
have someone navigate to the db without using the costom workgroup the
permissions aren't working because they can modify and delete records too.

The only way I can get the darn thing to behave like I want it to is to use
a copy of the custom.mdw with the password cleared on the Admin user.

I'm stumped.

Thanks for all of your help.

 

[Rick Brandt]

Then in theory there is no reason that this shouldn't work the way I
have it set up because I have the Admin user assigned to the Users
group and the Users group can only open the db, insert records and
view records. When I have someone navigate to the db without using
the costom workgroup the permissions aren't working because they can
modify and delete records too.

Then either "Admin" or "Users" has more permissions then you think they do.

Did you check to see whether "Admin" owns any objects? Owners have rights
above and beyond their explicit permissions.

 

[TC]

Rick is correct. User level security does work exactly as specified.
It's just that it's so &%$# easy to make a mistake. Also, the security
UI is hopeless imho.

TC