Security Report

[chaufschild]

I am trying to make a report on security (meaning who has access to what). In other words, I need to know what groups are associated to each user and what those groups have access to what forms, reports, etc. The first one I can get through the security menu, but the other is more difficult.

Thanks in advance for any help!

Chris

 

[RickSpr]

Are you doing this by hand or in code? Your statement, "the first I can get through the security menu" makes it sound like you're doing it by hand.

To get the permissions "by hand", join the controlling workgroup, and open the secured database loggin on as the designated administrator. Then you can review the permissions the same way they were initially set up. Caution: It is possible that a given user may have an account in one or more other workgroups, with different PIDs (personal ID numbers), and that those accounts were given distinct sets of permissions. Talk to the security administrator to see if this was done.

Perhaps an easier way is to download the Security Manager add-in from Microsoft. For Access 97, you can download it from

http://download.microsoft.com/download/access97/addin/1/WIN98/EN-US/Secmgr97.exe.

For Access 2000, use

http://download.microsoft.com/download/access2000/addin/1/WIN98/EN-US/Smgr2000.exe.

If you intend to do this in code, you can get all the available information using the DAO object model. I don't recall whether the Security Manager code is viewable, but I think it is, in which case you can examine it for technique tips. If you need more help here, please ask a more specific question. Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[chaufschild]

Thank you very much for your help.

For clarification I am trying to make a report that other IT personnel will be able to run without editing permissions. I need this report to list all objects in the database and which users have what kind of access to each object.

 

[RickSpr]

There are good security reasons not to share information about other people's permissions--are you sure that's what you want to do?

If that's what you want, you're going to have to write some code. Access won't let a user see another user's permissions, and your code is normally limited to what your user can do. To get around that, you'll have to create a private DAO Workspace object, and use it to log in as an administrator. The downside is that to do this, you'll have to record the administrator's password somewhere, most likely in the database. To keep it safe from compromise, you'll need to encrypt the database, and make sure that whatever it's recorded in (a table or a module) is not reachable in the application by anybody other than your code.

Once you've created the administrator's Workspace, you can open a Database object on it and use that to access the Document objects to get the permissions bits via the AllPermissions properties. Then you'll have to interpret the permissions bits into text for the report. This is all very tedious and complicated. I hope you can use some of the code from the Security Manager.

BTW, you can only get permissions informations for users and groups defined in the current workgroup (.mdw file). If your security is set up for users in different workgroups, you'll have to log on separately using each workgroup to get all the permissions. (The reason is that user and group names aren't stored in the database, they're stored in the workgroup file, so you have no way of knowing who the permissions belong to if you're not connected to the workgroup they're defined in. Since a program has to ask for the permissions by providing the user or group name, you'll never see the permissions for a user or group not defined in the current workgroup.) Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein