How to implement user-level security in Access 2007

Question

So after some digging I realize that there is no built in user level security option for Access 2007. What I need to do is restrict records that users can edit based on who

Answer 1

Assigning username/passwords in Access (especially with an access back end) has a number of critical issues that are worth pointing out. Firstly, if you don't encrypt your DB, then any of your users who are savvy enough to go looking for it will be able to find it, and therefore get full access to it. If you encrypt the DB, if anyone can get access to your source code you're toast, since they will be able to see the DB user/passwords stored in the code. This issue persists if you use other SQL db's, but at least in those cases you can restrict the user supplied to the Access .accdb file to have certain permissions.

For my case, I have 3 levels of security. Firstly, I heavily restrict what I send out to make it very difficult to access the source code, which you kind of have to do no matter what. Secondly, I distribute different levels of access with different DB passwords (I'm using a MySQL back-end, you could do the same with a SQLServer back-end, but with Jet you're out of luck), so even if users could see the DB user and password, they are limited in what they can do. Thirdly, since I deploy on a corporate network, I take advantage of windows groups, and use those to filter out what is visible to different users. That way, users can only use the forms if they are authenticated onto our network. If the file discovers it's not on the network, it deletes itself and terminates.

Function IsMember(strDomain As String, strGroup _
As String, strMember As String) As Boolean
    Dim grp As Object
    Dim strpath As String

    strpath = "WinNT://" & strDomain & "/"
    Set grp = GetObject(strpath & strGroup & ",group")
    IsMember = grp.IsMember(strpath & strMember)
End Function

Function GetCurrentUser() As String
    GetCurrentUser = VBA.Environ$("USERNAME")
End Function

Function GetCurrentDomain() As String
    GetCurrentDomain = VBA.Environ$("USERDOMAIN")
End Function  

Answer 2

For user privileges for read-only, read-write on forms in the database, we implemented following tables, logic.

I created a privilege table along with log-in table. Each screen in the database will have Read-only or Read-write privilege to each user. I inserted all the screen names into privilege table. Another table UserPrivilege will have users and their privileges. Assigning privilege to an user will be done only by Admin user.

A function at start of each form check swhether a specified user is allowed to view or edit form. If he/she is given read-only, we will lock all controls looping thr' controls on the form. Else, nothing to do. OR keep all the controls read-only at design them and unlock them thr' code for write privilege.

The database window is kept hidden when a version to end user is delivered. This prevents usual , simple view to tables in the database, opening forms , reports object in database window. After making mde/accde few more tweaks can be done so that user is not easily able to view tables directly. by-passing startup, special keys etc.

Answer 3

I have been facing this problem too. My solution (which hasn't been broken yet) is to do exactly that. Make a user's table with passwords and a log in form which reads the table for User name, password and user type. I have used two ways to proceed from there: Case statement to open specific navigation forms for that user's functions or a global variable (in a module (enumeration helps)) and an getter function that is checked within each form's open events and changes properties like AllowEdits, and AllowAdditions and even cancel the form opening if it's administrative stuff.

The most important part of this set up is making sure the users are using Access Runtime. If they use the Access version you are developing in they can snoop a little bit and get around this.

Make sure you hide the user's table.

Access runtime can be forced by making a shortcut to the DB and adding /runtime to the end of the shortcut path (with a space).

It's not perfect, but it works for my purposes and It might work for your's.

I did dot this in 2010, but 2007 should be pretty much the same.