By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,996 Members | 896 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,996 IT Pros & Developers. It's quick & easy.

AllowBypassKey Function with DDL Set to True

P: n/a
Perhaps someone can share information on the methods to use to effect
the automation process of creating the property to set the
AllowBypassKey function. I was directed to:
http://www.mvps.org/access/general/gen0040.htm and downloaded the
function module that includes setting the fourth DDL part to true. It
initially failed to compile using Access 97 because "PropType As
DAO.DataTypeEnum" is not an automation type that Visual Basic
supports. I received a tip to change "DAO.DataTypeEnum" to "Long" and
that allowed the module to be compiled.

What I need assistance with are the methods (I understand there are
several that can be used) by which to call the function. I have tried
a Public Sub, a macro, a command button on a form, an OnClose
procedure on a form and with variations of them all, but no success.

Does anyone have a piece of code that would work with calling this
Function? Thanks for your assistance. Dalan
Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"Dalan" <ot***@safe-mail.net> wrote in message
news:50*************************@posting.google.co m...
Perhaps someone can share information on the methods to use to effect
the automation process of creating the property to set the
AllowBypassKey function. I was directed to:
http://www.mvps.org/access/general/gen0040.htm and downloaded the
function module that includes setting the fourth DDL part to true. It
initially failed to compile using Access 97 because "PropType As
DAO.DataTypeEnum" is not an automation type that Visual Basic
supports. I received a tip to change "DAO.DataTypeEnum" to "Long" and
that allowed the module to be compiled.

What I need assistance with are the methods (I understand there are
several that can be used) by which to call the function. I have tried
a Public Sub, a macro, a command button on a form, an OnClose
procedure on a form and with variations of them all, but no success.

Does anyone have a piece of code that would work with calling this
Function? Thanks for your assistance. Dalan

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 dbs Is Nothing Then
Set dbs = 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
' ************************************************** ***************
Nov 12 '05 #2

P: n/a
"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
Nov 12 '05 #3

P: n/a
"Dalan" <ot***@safe-mail.net> wrote...
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.
Well, not exactly. It means that only someone with admin permissions on the
database can do so.
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
I am not sure what you mean -- you basically put the code in a module and
call the function. You can run it from the debug window, even. After that
you can even delete the code if you want to....

The key is to not lock yourself out of your database, so be sure you want to
always have the shift key disabled.
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?
See above....
Does anyone have any experience is using this code?


I wrote it, so I support I have some experience.... :-)
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.


Nov 12 '05 #4

P: n/a
"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
' ************************************************** ***************
Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.