Permissions problem.

  • Thread starter Thread starter Ivar Svendsen
  • Start date Start date
I

Ivar Svendsen

Hello.

In order to speed up user account creation, I had each
user to select its own user name and PID. I did not write
down this information.

Now I have to fire one of the superusers of this database,
but he has already deleted his account from the workgroup
file.

My problem is that I cannot find a way to disable his
database rights, because I can only view and set
permissions for users and groups already included in the
workgroup file. If he enters the username into any new
workgroup file he will be granted access again.

Is there any way to ensure that there is no such hidden
access rights in the database?



Regards,
Ivar Svendsen
 
That is an interesting problem!

If you do not know his PID, you will definitely not be able to recreate his
user account by any normal means.

The way to proceed will depend to some extent on how he got his permissions.
Were they assigned to him (the user) directly, or did he get them through
group membership, or some mixture of the two?

- If he got them directly, he will indeed be able to recreate himself, & get
them back. And you will not be able to take them away, unless/until he *has*
recreated himself! Catch 22.

- If he got them through group membership, perhaps you could:
o create new groups with the desired permissions;
o move all (remaining) users from the old groups, to the new ones, then
o remove all permissions from the old groups.
Then, when he recreated himself, he would not regain his previous group
permissions.

Probably the safest approach would be to re-secure the database using a new
WID, and new PIDs for all users.

And, as Joseph said, do *not* tell the users their PIDs.

You may wish also to consider the issue of what happens if a user keeps
their own copy of the workgroup file. Say you assign permissions to groups
(not users). Say you delete a user from the workgroup file. There is nothing
to stop that user from re-accessing the database, using his own saved copy
of the workgroup file! This problem can be avoided if you assign permissions
to users, instead of to groups - because then you can remove permissions
from that user, & it doesn't matter if he tries to use a saved workgroup
file. Unfortunately, assigning permissions to users (instead of to groups)
increases the maintenance effort when adding new users.

Truly, MS Access security is a strange device, wonderous to behold, but
terrible in its wrath when confronted :-)

HTH,
TC
 
True. I guess I was making some assumptions. Which is another reason
not to allow people to set up their own accounts.

Ivar, if you want, it is possible to change things around to fix it. It
can be a bit of work, but if security is important it can be done.

--
Joseph E. Meehan

26 + 6 = 1 It's Irish Math


TC said:
What you describe "If he enters the username into any new workgroup file
he will be granted access again." if true means the database in not properly
secured.
Click to expand...

That is not really so. If he created a new workgroup file with the same
file- and user- level details (PIDs etc), the new user would be
indistinguishable to the old (deleted) one.

TC

I also suggest you don't allow uses to chose their own PIDs. If you use
a standard method you will know what they are from the name.

I suggest you start by reading
http://support.microsoft.com/default.aspx?scid=kb;[LN];207793

Access security is a great feature, but it is, by nature a complex product
with a very steep learning curve. Properly used it offers very safe
versatile protection and control. However a simple mistake can lock
everyone including God out.

Practice on some copies to make sure you know what you are doing.


--
Joseph E. Meehan

26 + 6 = 1 It's Irish Math


Ivar Svendsen said:
Hello.

In order to speed up user account creation, I had each
user to select its own user name and PID. I did not write
down this information.

Now I have to fire one of the superusers of this database,
but he has already deleted his account from the workgroup
file.

My problem is that I cannot find a way to disable his
database rights, because I can only view and set
permissions for users and groups already included in the
workgroup file. If he enters the username into any new
workgroup file he will be granted access again.

Is there any way to ensure that there is no such hidden
access rights in the database?



Regards,
Ivar Svendsen
Click to expand...
Click to expand...
Click to expand...
 
Back
Top