Block user ability to change user/group permissions

[Guest]

I'm not quite sure if I have done something wrong or what the problem is. I
created a test database and several test users. Now, I put test user Batman
in a group with no administrative rights and was also sure not to give the
dark knight himself any more rights than the group gives him.

For some reason, though, when I log into my database as Batman, all his
rights work correctly (for example, he can open design view of the form, but
it tells him he cannot change anything), but he is able to change user and
group permissions. This should not be. Only my administrative users should be
able to do that. What's wrong? Is there a permission I may have forgotten to
take away from the caped crusader?

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[Keith]

I'm not quite sure if I have done something wrong or what the problem is.
I
created a test database and several test users. Now, I put test user
Batman
in a group with no administrative rights and was also sure not to give the
dark knight himself any more rights than the group gives him.

For some reason, though, when I log into my database as Batman, all his
rights work correctly (for example, he can open design view of the form,
but
it tells him he cannot change anything), but he is able to change user and
group permissions. This should not be. Only my administrative users should
be
able to do that. What's wrong? Is there a permission I may have forgotten
to
take away from the caped crusader?

Sounds like you may have missed a step in the secure process (eg have you
removed rights from the "Users" group?). Have you read the MS FAQ on
security? It's essential reading and you must follow every instruction in
every step. There's a link to it on my web site along with a worked
example. Always back up your files in case you lock yourself out!

Regards,
Keith.
www.keithwilby.com

 

[John Slattery]

Keith's post is on the mark, however, in the cut-to-the-chase department, is
Batman the owner of the database in question? If so, he will be able to,
among other things, administer the database even though his user and any
groups to which the user belongs lack the permission.

 

[Guest]

Thank you both very much for your help. First, though, I thought you weren't
supposed to give the users group ANY permissions if the typical person
shouldn't have access to your database. I therefore left the users group at
the default of having no rights. The real database we will be creating should
only be accessed by people we set up with a user name and password.
Therefore, the default group shouldn't even be able to open it. This way, if
some random person in our company who has Microsoft Access tries to open it,
it will not even open for them.

Also, Batman is not the owner of any of the objects in my database. I can
definitely see what you both mean, though. When I first started learning how
to set up security, these were mistakes I made, but not the case this time.

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[Joan Wild]

Thank you both very much for your help. First, though, I thought you
weren't
supposed to give the users group ANY permissions if the typical person
shouldn't have access to your database. I therefore left the users group
at
the default of having no rights.

But that is not the default. Double check the permissions for *all* objects
including the database object. Double check that Admin doesn't own any
objects, including the database object.

When you started the process of securing, did you create a new workgroup
file, or simply copy system.mdw and rename it? You *must* do the former.

 

[TC]

Holy cow, Batman!

Methinks the Boy Wonder has BOO-BOO'd !

BOOHOO, BEMUSED BATMAN AND BOYHOOD BUDDY !!

KAPOW! KABLUIE!! etc.

HTH,
TC

 

[Keith]

KAPOW! KABLUIE!! etc.

HTH,
TC

I'll get you for this Top Cat ;-)

 

[Guest]

Neither Admin nor Batman are the owners of anything. I checked all objects.
Two of my users own the objects. Both are set up with Admin rights. They have
completely full permissions to all objects.

Also, I went through the User-level Security Wizard. I'm not an expert on
security, but know a little bit about it. I know enough to get through the
Wizard correctly (unless maybe I am missing something). In other words,
whatever the Wizard defaults to having me do, that is what I did. I'm not
really sure, but doesn't the Wizard have you define a new workgroup?

By the way, TC, that was hilarious! LOL!!! Na na na na na na na na Access!

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[Guest]

Oh fuzz bunnies! I just realized I didn't post my response after the last
repsonse in this thread. I hope folks don't just briefly skim over this and
not notice that my response wasn't the last. I'm hoping somebody knows how to
help me. This is quite the melon scratcher.

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[Guest]

Oh, and I just went back in and noticed that it saved my workgroup as
system1.mdw, not just system.mdw if that helps clear up the situation at all.

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[Joan Wild]

Oh, and I just went back in and noticed that it saved my workgroup as
system1.mdw, not just system.mdw if that helps clear up the situation at
all.

What version of Access? It is very difficult for us to determine which step
you may have missed. Access security is not trivial. There often is more
to it than just 'running the wizard'. Have a look at
www.jmwild.com/AccessSecurity.htm for detailed steps.

 

[Guest]

I have Access 2002. Using the wizard, everything seemed fine but one thing,
and that is that users who should not be able to are able to change
permissions for themselves and others. I actually did find one way of my own.
Using the startup options, I'm able to make it remove all of the stanard menu
options and stuff. I can make it so it won't allow you to get into design
view, or open any other database. If I recall, when I do this, Tools isn't
even available, but I know for sure Security isn't. The only problem with
this solution is nothing more than a minor annoyance (In other words, if
there is no easier solution, this will do). That is that anybody who actually
DOES have administrative rights will have to hold down shift to get into the
backend database.

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[Joan Wild]

I have Access 2002. Using the wizard, everything seemed fine but one thing,
and that is that users who should not be able to are able to change
permissions for themselves and others.

Keep in mind that the owner of any object can change permissions for that
object, regardless of the permissions you assign that user.

If they are not the owner, then you have missed a step in securing the mdb.

The only problem with
this solution is nothing more than a minor annoyance (In other words, if
there is no easier solution, this will do). That is that anybody who
actually
DOES have administrative rights will have to hold down shift to get into
the
backend database.

It likely won't be long before some non-administrator discovers that, and
then you'll have to disable the shiftkey bypass. You really should correct
the problem.

 

[TC]

I can see a last reply from Joan to your other last post. Can you see
that one?

As I understand it, one of your workgroup file users has more
permissions that you think that he should.

With these problems, it sometimes helps to look at the permissions
through code, without using the normal UI.

(untested)

' display permissions to table 'x' ...
with dbengine(0)(0).containers![tables].documents[x]
' ... from user 'y' (ignoring his groups).
.user = "y"
debug.print .permissions
' ... including his groups:
debug.print .allpermissions
end with

To interpret an .[all]permissions value:

if (<that value> AND dbSecReadDef) = dbSecReadDef then
' he has Read Design permission.
endif
etc. for the other constants.

HTH,
TC

 

[Guest]

:

Keep in mind that the owner of any object can change permissions for that
object, regardless of the permissions you assign that user.

I know that. Batman isn't the owner of anything.

If they are not the owner, then you have missed a step in securing the mdb.

I am sure that must be the case even though I do not see how that could be
possible. I followed everything just the way I was supposed to.

As I understand it, one of your workgroup file users has more
permissions that you think that he should.

That seems to be the case, but nowhere in user and group permissions do I
see how to change permissions to change permissions. In the way you are
describing, how do I find the permissions in the code? When I go into the
code, all I can find is the code for specific objects. Also, I'm fairly new
to actually directly typing the code. What was all that you were giving me?
Is that what to look for, or a code used to find it?

Good gravy! Setting up the security shouldn't be this difficult and
involved. If Access could just add right into the user and group permissions
the ability to set whether or not any specific group and/or user can alter
permissions, it would be so much easier. It WOULD be really easy if it
weren't for this part of it being burried deep in some mysterious cave. I
appreciate everybody's continued help.

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[Guest]

GROOVY!!! I got it. Thanks again for all your help, everybody.

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[Joan Wild]

GROOVY!!! I got it. Thanks again for all your help, everybody.

For the benefit of others, why don't you share what was wrong?

 

[Guest]

For two reasons. One: I feel slightly silly now, two: I'm not sure exactly
when or how the problem was fixed. See, it turns out that, for a while, I was
just assuming the folks could change permissions since it let me get into the
user/group permissions as them, and even let me select or de-select stuff. I
should have thought to actually click "Apply," but I was just worried that
I'd actually change their permissions. I should have just done it since I
could easily have changed them back if I messed anything up. When I actually
made anything different, then clicked apply, an error message told me I did
not have the rights to change permissions.

Somewhere along the lines, as you folks helped me, we achieved the desired
result, and I just assumed everything would be greyed out. My guess, though,
is that the only thing I had to actually do was remove administrative rights
from the users/groups in question. That was one of the first things this
thread sparked me to do, and I'm betting that did it right away. Thanks again
and sorry I didn't catch this sooner. I'll be more careful in the future to
be sure whether or not the problem has actually been solved. Silly me, I just
expected to either not be able to get into the user/group permissions as the
effected users, or for it all to be greyed out.

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy

 

[TC]

Paul (ESI)
"Charting the future of pharmacy"
wrote:

Good gravy! Setting up the security
shouldn't be this difficult and involved.

I went to a pharmacy once. They checked labels, filled out forms, asked
me what else I was taking .... Good grief, why is it so difficult &
involved? Why can't they just give me the friggin' things & be done
with it?

HTH,
TC

 

[Guest]

LOL. No, my point was just that it shouldn't be so difficult to implement
correctly. I know why it is important for it to be hard to crack. I mean,
duh. My point was just that, if it is so hard to implement, a lot of people
will be implementing it incorrectly, defeating the purpose of having security
in the first place. It'd be like a car alarm. You just hope that potentinal
criminals will think "Oh no, it has a car alarm. I can't steal this car," but
you know you're not really fooling anybody. Well, as it turns out, it was
rather easy to implement. I just didn't realize I had gotten it.

--
Have a nice day!

~Paul
Express Scripts,
Charting the future of pharmacy