Asking for Security

[accessman2]

Hi,

I have a question for user-level security and workgroup.

Suppose we setup user-level security and have a workgroup with storing all username, password, and groups,
if adminstrator want to change one user permission, let's say that change the user permission from update to read permission only, then the user should only have read permission, right. However, previously, the user copied the workgroup file himself before adminstrator change his permission, if he apply to his copied workgroup file, and log in the database, he can still have update permission.

So, how do I prevent the user using his copied workgroup file for the database?

How can I solve it?

Thanks.

 

[The_Doc_Man]

First and foremost, NO user should EVER get permissions. Only groups should get permissions. Define groups (think "roles") and give them permissions, then assign who is a member of that group. Users should always always ALWAYS get permissions via group membership.

As to the other problem, that is an interesting bypass that is going to be hard to resolve. My best solution is to publish a list of system "no-no" actions. Then, the first time you find that a user has done that, place a formal reprimand in his personnel jacket. If he does it again, fire him. Very publicly and very loudly.

Or there is always execution?

Seriously, unless you wanted to get REALLY kinky, I don't know how to tell you how to stop it. Here's a thought... there are Access functions that let you read the registry. So write a splash form that has code behind it. In that code, read the registry key that tells you to which workgroup you are currently joined. If it is not the "blessed" copy, quit Access. You can probably just parse the path to your database and require that the workgroup be in the same path with the same name as the .mdb file. That should not be TOO hard a parse.

 

[john471]

This is not something you need to solve (if you have PROPERLY secured your DB).

However, previously, the user copied the workgroup file himself before administrator change his permission, if he apply to his copied workgroup file, and log in the database, he can still have update permission.

As I understand it, that is incorrect. The security file houses the users, passwords, groups, & user's group memberships; not the rights of those users or groups. The rights (permissions) are stored in a system table (MSysACEs) in the database to which they pertain.

If you believe you are able to demonstrate differently, I suspect you have not fully and correctly secured your database, following ALL the required steps. Search this forum and/or the Microsoft site for the MS ACCESSES SECURITY FAQ and read it and follow its instructions to the letter in order to secure your DB (to the extent that MS ACCESS is secure - of course, that is a different matter all together).

If the user has a copy of the security file, and knowledge of a username that is a member of the Admins Group, and its password, that is a different matter, and yes if you change the account's password it will have no effect on a different copy of the security file.

I do concur with The_Doc_Man, that ALL permissions should ALWAYS be assigned to groups, and users made members of the relevant groups in order to attain the permissions which they require.


HTH

Regards

John.

 

[The_Doc_Man]

John, it has been so long since I looked at where permissions are kept that I wasn't sure - but I concur that if you have an incompletely secured MDB, you would also see the indicated effect.

 

[john471]

Of course I had the realisation this morning that if 'Person' was a member of 'Group' which has permissions, and 'Person' has a copy of this security file; then 'Administrator' removes 'Person' from 'Group'; 'Group' permissions have not changed, and 'Person' uses private copy of Security File (according to which he/she is still a member of 'Group') then 'Person' will have permissions 'Administrator' expects them not to (any longer) have.

Your idea of parsing location of security file and comparing to acceptable locations / database location would solve this.

e.g. Parse each of DBEngine.SystemDB and CurrentDB.Name to determine if their paths are the same, and exit the database if they are not.