"Dalan" <ot***@safe-mail.net> wrote in message
news:50**************************@posting.google.c om...
"Fletcher Arnold" <fl****@home.com> wrote in message news:<buolu5$kq8
Thanks again Fletch. I did try the original code and it does work as
intended, and will try it again with your noted changes, but I'm a
little confused so perhaps you can clear the air so to speak.
I'm not certain that it set the 4th part (DDL) to true as I was able
to defeat the Disabled Shift ByPassKey by accessing the database from
running code using another DB. Apparently, it was reset, as I held
down the Shift Key and got right into the database window. As I
understand it, the original information and code provided by MS is
flawed in that it did not set DDL to true, but left it at false. If it
was set to true, then only Admins could reset it within the database
only, and no code that is run outside of the DB would be effective.
What is your opinion regarding this matter?
Thanks, Dalan
I imagine you have created a second database to sneakily change the
bypass key of the first. You can, in fact, prevent this but you must realise
that there programs available which can now crack *any* of these security
measures. You should use Access security to keep out the nosey and
curious, but not rely on it to keep out those who would be prepared to take the
database and apply one of these security crackers to it.
It is a matter of understanding user-level security. If you want to see
it work you need to use the Workgroup Administrator, which can be accessed
from the Tools>Security menu from XP, and separate exe with earlier versions
(wrkgrp.exe?).
Assuming you have not created a new mdw file for this database and you
are happy to make some fully reversible changes to your db (take backups of
both the mdb and mdw file if you are unsure) you could try this.
From Tools>Security>User & Group Accounts go to "Change Logon Password"
(this should be for the Admin account) and change it to say "admin". If
you now close Access and re-start your db you will find that you are
prompted to login - which you can do as admin/admin. Now go back to User & Group
Accounts and create a user name="Fred" pid="Fred" which will, by default
be in the Users group, not the Admins.
Now go to the User & Group permissions tab and set List="Groups" Object
Type="Database". From here, select the Users and remove their
permissions to Administer or Open Exclusive. Now log on to your second database as
"Fred" (who does not have administer rights for the first database) and
try and change the bypass key - You will not be able to.
To put things back to how they were, log back on as admin, change the
logon password back to blank. Put back users' rights to administer and open
exclusive and lastly, delete user "Fred".
Hope that makes sense.
Thanks Fletch for taking the time to illustrate a method for securing
a database. When I have a chance, I will try your recommendation. But
if I may, I would like to migrate back to my original post. From what
I understand, if the 4th argument (DDL) of the AllowByPassKey is set
to True, then no code that is run outside of the database can reset
the Key to enabled. However, I have been unsuccessful in finding a
method to use in order to call the function based on the code posted
at: http://www.mvps.org/access/general/gen0040.htm
So if the 4th argument of the AllowByPassKey is set to true does it
make easier, more difficult or the same to defeat it either running
code or using a suspect crack program? Does anyone have any experience
is using this code?
Any suggestions on how to call this function and get it to work would
be appreciated. Thanks, Dalan
The steps provided in the first post (repeated below with that minor
amendment) do give a reasonably comprehensive guide to implementing this.
The thing that I think you have missed is this: If you have not secured your
database using user-level security then anyone can do anything with your
database - including deleting all the tables and including deleting or
re-setting the Bypass key. It is only once you create groups and users that
you can specify who can and who can't re-set this key. If you follow the
steps to create the user Fred and amend the database permissions, then you
will find that if you log in as "Admin" you can re-set the key, but if you
log in as "Fred" then you can't.
Other things to note are:
1. If you have never used Access user-level security, it can be a lot to
take in. I didn't find it too difficult but some people don't seem to get
it. From the FAQ for this group, you could try this:
Microsoft Access Security FAQ:
http://support.microsoft.com/support.../Q165/0/09.asp http://download.microsoft.com/downlo...-US/Secfaq.exe
(This is the Security FAQ for *ALL* version of Access)
http://support.microsoft.com/support...ent/secfaq.asp
(On-Line version of the Security FAQ)
2. Access user-level security has been broken. That is, there are programs
available which I could use to remove the permissions which you had set up
to only allow the user "Dalan" (with a secret password) to re-set the Bypass
key.
In my opinion, user-level security is still an extremely useful tool and in
the typical office setup it works well to stop people going places and doing
things they shouldn't be doing. After all, your boss may lock the door to
his office but you might well be able to kick it in. It doesn't mean that
locking the door is a stupid idea.
You just need to use it to appropriately. For example, you may want to
specify that 'standard users' of your application can view, say, Purchase
Orders but only a member of the Purchasers group can create a new order.
If I created such an application, I would not be worried that Annie from
Accounts would try to hack into the system to create a new purchase order.
If I was worried about this possibility, then I would move the data to a
server-based database like SQL Server. It all comes down to this: Who are
you trying to lock out and why?
' ***********
From first post:
Here is my implementation of that idea: Create a form with 2 buttons:
cmdAllow and cmdForbid and paste the code below into the form's module.
Two warnings:
1. Take a backup before taking advice from strangers.
2. If you have also taken steps to hide the database window, then make sure
you can get to this form another way (e.g. a button on some startup form) to
avoid locking yourself out.
' ************************************************** ***************
Option Compare Database
Option Explicit
Private Function SetBypassKey(Allow As Boolean) As Boolean
On Error GoTo Err_Handler
Dim dbs As DAO.Database
Dim prp As DAO.Property
Set dbs = CurrentDb
dbs.Properties.Delete "AllowBypassKey"
Set prp = dbs.CreateProperty("AllowBypassKey", dbBoolean, Allow, True)
dbs.Properties.Append prp
SetBypassKey = True
Exit_Handler:
On Error Resume Next
If Not prp Is Nothing Then
Set prp = Nothing
End If
If Not dbs Is Nothing Then
Set dbs = Nothing
End If
Exit Function
Err_Handler:
Select Case Err.Number
Case 3265
' Ignore attempt to delete non-existant property
Resume Next
Case Else
MsgBox Err.Description, vbExclamation, "Error Number: " & Err.Number
Resume Exit_Handler
End Select
End Function
Private Sub cmdAllow_Click()
If SetBypassKey(True) Then
MsgBox "Bypass Key Is Enabled", vbInformation
End If
End Sub
Private Sub cmdForbid_Click()
If SetBypassKey(False) Then
MsgBox "Bypass Key Is Disabled", vbInformation
End If
End Sub
' ************************************************** ***************
