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

How to secure an A97 database from being opened w/o the correct system datbase being in place

P: n/a
MLH
I was reading up on A97 security and found a blurb saying
Microsoft Access provides two traditional methods of securing a
database: setting a password for opening a database, or user-level
security, which can be used to limit what parts of the database the
user can access or change.

Which of these two do I configure to prevent opening the database
unless the correct system database is joined?

This topic came up as a result of another thread entirely. I thought
sorting out this topic by itself as a separate thread best.
Nov 13 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
MLH wrote:
I was reading up on A97 security and found a blurb saying
Microsoft Access provides two traditional methods of securing a
database: setting a password for opening a database, or user-level
security, which can be used to limit what parts of the database the
user can access or change.

Which of these two do I configure to prevent opening the database
unless the correct system database is joined?

This topic came up as a result of another thread entirely. I thought
sorting out this topic by itself as a separate thread best.


User Level security (the one that cares about the workgroup) will only allow
you to open the file when the correct workgroup is being used (if done
properly). My estimate is that 3/4 of all "secured" Access files are not
secured properly and most of the people doing the securing are completely
oblivious to that fact.

If you Google on the topic you will find a handful of sites that provide
explicit step by step instructions for implementing security. If you follow
one of those EXACTLY then you will end up with a properly secured file.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #2

P: n/a
.... also you can download the Microsoft Access Security Whitepaper. This
can be confusing to read on it's own (I don't know anybody who read and
understood it in one go) but when combined with the websites Rick reccomends
should ensure a properly secured db.
--
Terry Kreft
MVP Microsoft Access
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:nY***************@newssvr11.news.prodigy.com. ..
MLH wrote:
I was reading up on A97 security and found a blurb saying
Microsoft Access provides two traditional methods of securing a
database: setting a password for opening a database, or user-level
security, which can be used to limit what parts of the database the
user can access or change.

Which of these two do I configure to prevent opening the database
unless the correct system database is joined?

This topic came up as a result of another thread entirely. I thought
sorting out this topic by itself as a separate thread best.
User Level security (the one that cares about the workgroup) will only

allow you to open the file when the correct workgroup is being used (if done
properly). My estimate is that 3/4 of all "secured" Access files are not
secured properly and most of the people doing the securing are completely
oblivious to that fact.

If you Google on the topic you will find a handful of sites that provide
explicit step by step instructions for implementing security. If you follow one of those EXACTLY then you will end up with a properly secured file.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Nov 13 '05 #3

P: n/a
MLH
I'm one of those people. I don't understand. Is there somewhere else
to set security other than by clicking Tools, Security? When I do, I
only get two choices: User and Group Permissions #AND# User
and Group Accounts. Well, there is Set Database Password #AND#
Encryption and a security wizard, but it doesn't sound to me like I
need to use those to do what you are talking about.

User Level security (the one that cares about the workgroup) will only allow
you to open the file when the correct workgroup is being used (if done
properly). My estimate is that 3/4 of all "secured" Access files are not
secured properly and most of the people doing the securing are completely
oblivious to that fact.

If you Google on the topic you will find a handful of sites that provide
explicit step by step instructions for implementing security. If you follow
one of those EXACTLY then you will end up with a properly secured file.


Nov 13 '05 #4

P: n/a
MLH
Is there one simple step to prevent database from being opened w/o
specific system database being joined? At this point, that's all the
additional security I want. All my database objects are satisfactorily
secured.
... also you can download the Microsoft Access Security Whitepaper. This
can be confusing to read on it's own (I don't know anybody who read and
understood it in one go) but when combined with the websites Rick reccomends
should ensure a properly secured db.


Nov 13 '05 #5

P: n/a
MLH wrote:
I'm one of those people. I don't understand. Is there somewhere else
to set security other than by clicking Tools, Security? When I do, I
only get two choices: User and Group Permissions #AND# User
and Group Accounts. Well, there is Set Database Password #AND#
Encryption and a security wizard, but it doesn't sound to me like I
need to use those to do what you are talking about.

Access security is difficult to understand and implement properly, but once you
"get it" it is not that bad. It is sufficiently complex that Microsoft's first
attempts at providing a wizard to "do it all for you" actually did not produce a
properly secured file.

On a certain level security that is not complex to set up is more than likely
going to be easy to break so the complexity is not a reflection on a botched job
by MS in their construction of the security model. It's just a requirement for
having something that offers any protection.

In my opinion Access security falls into the category of "if you have to ask,
then you're not ready for it". Securing the DATA stored in an mdb is a
non-starter since there are numerous utilities on the web for breaking Access
security and for protecting your code using an MDE is a lot easier and more
effective. For these reasons I stopped using Access security years ago.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #6

P: n/a
MLH
Just to be sure it wasn't the Security Wizard, I created a
database under oldSystem.mdw. Then I closed Access
and opened Workgroup Administrator and made a new
system database with a different Workgroup ID, saving
it as newSystem.mdw. I was automatically 'joined' to the
new system database upon closing Workgroup Admin-
istrator.

I was then able to open the recently created database
with no problem - was not prompted for a password. So,
that's a relief. I was hoping the wizard was not program-
med to do something that the developer could not do by
himself.

The database I created has no objects in it.
Nov 13 '05 #7

P: n/a
MLH
<censored>
I can certainly understand your reasoning. And I do create the mde you
mentioned. I sure would like to find out what the 'secret' that stops
a database from even opening w/o the original system database being
in place. That would be clever. I have yet to see one and am wondering
if there is such an mdb or mde example available for download to test.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

In my opinion Access security falls into the category of "if you have to ask,
then you're not ready for it". Securing the DATA stored in an mdb is a
non-starter since there are numerous utilities on the web for breaking Access
security and for protecting your code using an MDE is a lot easier and more
effective. For these reasons I stopped using Access security years ago.


Nov 13 '05 #8

P: n/a
MLH
>Is there one simple step to prevent database from being opened w/o
specific system database being joined? At this point, that's all the
additional security I want. All my database objects are satisfactorily
secured.


Well, digging around myself, I found something that may be a clue...

.... cut from microsoft site ...
Open the new database. Because the Security Wizard removed all
permissions from the Users group for the security-enhanced objects,
you need to create your own custom groups and assign the level of
permissions needed to these groups. Every user is required to be a
member of the Users group (otherwise, a user would not be able to
start Microsoft Access), so only grant permissions to Users that you
want everyone to have. Members of the Admins group have irrevocable
power to administer database objects, so make sure to limit membership
in the Admins group to only those users who are administrators.
....

I did not know the wisdom of taking all permissions from User group
and creating another group to put users in just to administer security
at user level. Sounds redundant to me - but hey, if it works, I'll use
it. Dunno if this will prevent a database from being opened unless
specific system db in place. I guess it might.
Nov 13 '05 #9

P: n/a
MLH wrote:
<censored>
I can certainly understand your reasoning. And I do create the mde you
mentioned. I sure would like to find out what the 'secret' that stops
a database from even opening w/o the original system database being
in place. That would be clever. I have yet to see one and am wondering
if there is such an mdb or mde example available for download to test.


It's pretty simple really. When you open Access with a workgroup that
doesn't require a login prompt then you are ALWAYS doing so as user "Admin"
member of "Users". In a properly secured app neither of these entities
should have necessary authority to open the file. If your app can be opened
with "any old mdw" then this is where you have to look. More than likely
the user "Admin" still has ownership of the database and owners has rights
above and beyond the "permissions" assigned to them.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Nov 13 '05 #10

P: n/a
MLH
<censored>
You hit the nail right on the head! That was just too slippery for me
to realize. Now that you said it, it does seem pretty simple. Actually
I have always made a separate superuser (other than Admin) the
owner of the database and all its objects - since the Access 2.0
days. So that much is secure. But I forgot about Admin being the
default user. There is always a user I suppose - even if one does
not explicitly log in. Say, does that mean if I open a database with
"any old mdw" and go to immediate window and type ?CurrentUser()
that "Admin" will display?

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

It's pretty simple really. When you open Access with a workgroup that
doesn't require a login prompt then you are ALWAYS doing so as user "Admin"
member of "Users". In a properly secured app neither of these entities
should have necessary authority to open the file. If your app can be opened
with "any old mdw" then this is where you have to look. More than likely
the user "Admin" still has ownership of the database and owners has rights
above and beyond the "permissions" assigned to them.


Nov 13 '05 #11

P: n/a
MLH wrote:
<censored>
You hit the nail right on the head! That was just too slippery for me
to realize. Now that you said it, it does seem pretty simple. Actually
I have always made a separate superuser (other than Admin) the
owner of the database and all its objects - since the Access 2.0
days. So that much is secure. But I forgot about Admin being the
default user. There is always a user I suppose - even if one does
not explicitly log in. Say, does that mean if I open a database with
"any old mdw" and go to immediate window and type ?CurrentUser()
that "Admin" will display?


Yep.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.