Security

[jake7363]

Since any user is able to hold the Shift Key then double-click an Access file to open to the object panel and/or code, is there any way to prevent this other than a file password or using Access Security?

I can password the code, but the object panel still is available.

Thanks in advance,
Jake

 

[Ed2020]

Jake,

You can disable the shift key using the code posted below, however any user who knows what they're doing can re-enable it.

Public Sub DisableShiftKeyBypass()
On Error GoTo Errorhandler
'Disables the Shift Key

Const strProcedureName As String = "DisableShiftKeyBypass"

'Declare variables
Dim ThisDB As DAO.Database
Dim prpAllowBypass As DAO.Property

'Return reference to current database
Set ThisDB = CurrentDb()

'Disable the Shift Key
ThisDB.Properties("AllowBypassKey") = False

'Close database and set object variables to nothing to release system resources
ThisDB.Close
Set prpAllowBypass = Nothing
Set ThisDB = Nothing

ExitHere:
Exit Sub

Errorhandler:
If Err.Number = 3270 Then
Set prpAllowBypass = ThisDB.CreateProperty("AllowBypassKey", dbBoolean, False)
ThisDB.Properties.Append prpAllowBypass
Resume Next
Else
Call MyErrorLogger(Err.Number, strProcedureName, Err.Description)
Resume ExitHere
End If

End Sub


Ed Metcalfe

Please do not feed the trolls.....

 

[jake7363]

I understand. Thanks, this should work.

 

[Ed2020]

Jake,

You should only treat this as an interim measure. Learn workgroup security as a matter of urgency and implement it ASAP.

For what it's worth I include the following security measures when deploying a system:

1. Workgroup security.
2. Disable Shift key bypass.
3. VBA password.
4. Hide all menus and toolbars other than those I explicitly want the users to see.
5. Ensure non-developer users can only open the system in Runtime Access.
6. Disable F11 key with an AutoKeys macro.
7. Ensure non-developer users cannot open the system exclusively.
8. All operations within the system are controlled by my own security system that checks the user's Windows logon ID as authentication.

HTH,

Ed Metcalfe.

Please do not feed the trolls.....

 

[jake7363]

I did give that a try, but it is still a little beyond my scope.

However, in this particular case, is there a way to bypass the need for the users' password, since I am the only one involved in the design? I am thinking just to password my access and let all the others be able to access data entry/edit without a password.

Is that possible?

jake

 

[Ed2020]

Jake,

Yes.

1.Add a new user and assign full permissions to all objects. This will be your account.

2. Add a password to the Admin user account. This will be the account for all other users.

3. Close and reopen Access. Log in with your account. Add a password. Remove design rights from the Admin user. Remove the Admin user password.

When you open the database you will need to use a shortcut that specifies the MDB and MDW file paths and also your user name and password (otherwise it will default to using the Admin user (as it has no password).

Ed Metcalfe

Please do not feed the trolls.....

 

[jake7363]

Super! I really appreciate this. Thanks a lot!!

 

[Ed2020]

You're welcome.

Ed Metcalfe.

Please do not feed the trolls.....

 

[lameid]

Jake,

Assuming you did not create a new workgroup file and you are using the system default workgroup, you need to ensure you remove the same permissions from the Admins group as you do for Admin.

The Admins group is specific to the workgroup file but all default workgroups are the same so anyone using the default workgroup could have the perimission of the Admins group.

Group memebership is maintained in the workgroup file, and admin is a member of Admins by default. So even if you remove admin from admins in your workgroup, everyone else's default workgroup is still a member and I have permission.

Going beyond the scope of the question, the PID's specified in the creation of the workgroup control permission not the workgroup files themselves. The workgroup files are only keepers of PID's. I could have several Workgroups with the same PID's. The PID of the workgroup is the PID of the Admins group.

If I copy a workgroup file, then you change your password and then you tell me what your old password is, I can use my copy of the workgroup to log in with your old password. This makes workgroup security relatively weak.

 

[jake7363]

lameid,
I get what you're saying. The fact is, I am only using the Access securtiy because I have no other options. For my applications, it is almost overkill, since the Company has set Access as a secondary database (Oracle being the primary). Hence, not a lot of support for the Access end of it.

Just trying to have one password user in a locked app seems to be a big deal with Access. Because my users are 'basic', all I want to do is make sure this app doesn't get messed up by somebody "experimenting" so I don't have to keep redoing it.

Thanks for the input...much appreciated...

 

[lameid]

Jake,

I wasn't trying to say Workgroup security is useless just to be aware that it is easier to breach than one might hope.

The one thing I really wanted you to note was removing permissions from the Admins Group as well as the Admin user if you did not ceate your own workgroup. Otherwise your users will still be able to muck things up. If you create a workgoup file, so much the better.

One more tip for you... You can actually set the permissions for new objects. Set it once, always go in with your shortcut and you won't have to worry about permissions in that database again. The only thing to note here is that the new object permissions are MDB specific and not Access or Workgroup wide.