Workgroup File

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

 

[anoyse]

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

 

[anoyse]

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