Why are all access database I open asking for log on?

[Guest]

I recently added security to an existing 97 Access database. Now when I log
on to all of my other databases (both 97 and 2000) they are asking me for a
username and password. These databases previously did not require usernames
and passwords. Any idea why this happening and how to fix it?

 

[Joan Wild]

When you secured your 97 Access database, you create a new workgroup file.
The workgroup administrator made this the default mdw to use for all
sessions.

Run the workgroup administrator again and click on join, and rejoin the
standard system.mdw that ships with Access. For your secure mdb, create a
desktop shortcut that overrides the default. The target would look like:

"path to msaccess.exe" "path to secure mdb" /wrkgrp "path to secure mdw"

 

[Rick Brandt]

I recently added security to an existing 97 Access database. Now
when I log on to all of my other databases (both 97 and 2000) they
are asking me for a username and password. These databases
previously did not require usernames and passwords. Any idea why
this happening and how to fix it?

The databases are not asking you for a login, your workgroup is.

Access workgroup file usage is established at the session level, not by the
files you open. This means as soon as you open Access you are doing so
using your default workgroup file (unless you use a command line argument to
specify a different one). If you have set your default workgroup to one
that requires a login then you are prompted regardless of what file you
might choose to open.

The usual practice is to leave your default workgroup as System.mdw. Then
you create shortcuts for your secured files that specify a non-default
workgroup file as a command line argument. The target would look like...

"path to MSAccess.exe" /wrkgrp "path to MDW" "path to MDB"

 

[Guest]

Rick, I have a follow up question on this issue.
Using the command line (in a shortcut) to specifiy the work group will
secure the database using the mdw you specify and secure the database as set;
however, what is to keep a user from browsing their directory structure and
opening your database directly? Since they opened the database using
System.mdw, which has no security settings, have they now bypassed security

 

[Rick Brandt]

Rick, I have a follow up question on this issue.
Using the command line (in a shortcut) to specifiy the work group will
secure the database using the mdw you specify and secure the database
as set; however, what is to keep a user from browsing their directory
structure and opening your database directly? Since they opened the
database using System.mdw, which has no security settings, have they
now bypassed security on the database?

Only if you setup security incorrectly. If you did it right then anyone
trying to open the file with the wrong workgroup file will be denied access.
Unfortunately, a high percentage of files that people "think" are secured
will not pass that test.

 

[Joan Wild]

Rick, I have a follow up question on this issue.
Using the command line (in a shortcut) to specifiy the work group will
secure the database using the mdw you specify and secure the database
as set; however, what is to keep a user from browsing their directory
structure and opening your database directly? Since they opened the
database using System.mdw, which has no security settings, have they
now bypassed security on the database?

If they are opening the mdb while joined to system.mdw, then it wasn't
secured properly. That is in fact a good test to see if you did it right.

 

[Guest]

Thanks, Rick.

I have the world's worst kind of user. That is the one who has an once of
technical knowledge and wants to make design decisions. He once tried to use
security and locked all his databases up, so is saying "We need good
security, but Access Security is to cumersome and hard to use, let's write
our own. And, I don't want us to have to enter a password if we are using
other Access mdbs on our own."

I, of course, am campaigning for using Access security. The problem is,
that even though I have been writing Access Apps for 7 years, I have never
had the opportunity to use Access Security. Home grown has always been
imposed on me.

The short of it is, I know I have a learning curve, but I have to convince
the powers that be it is the best method.

 

[jacksonmacd]

The most important step for understanding security is to read some
third-party documentation. Here are a number of links about security:

http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html#Security

Once you understand how it works when properly configured, you should
be able to convince the powers-that-be that Access security is better
than any roll-your-own solution.

 

[Rick Brandt]

Thanks, Rick.

I have the world's worst kind of user. That is the one who has an
once of technical knowledge and wants to make design decisions. He
once tried to use security and locked all his databases up, so is
saying "We need good security, but Access Security is to cumersome
and hard to use, let's write our own. And, I don't want us to have
to enter a password if we are using other Access mdbs on our own."

I, of course, am campaigning for using Access security. The problem
is, that even though I have been writing Access Apps for 7 years, I
have never had the opportunity to use Access Security. Home grown
has always been imposed on me.

The short of it is, I know I have a learning curve, but I have to
convince the powers that be it is the best method.

My opinion only, but I think the biggest problem for people trying to learn
security is trying it on the big complete app that they just spent a lot of time
creating. If you start out by just trying to get a completely empty file
properly secured then you are 90% home.

You create a new MDW. Open a new blank file using the new MDW and set up a
password on Admin, create a new "master" group with one user and then strip
Admin and Users from all rights (including rights on newly created objects).
Then you throw that file away (because Admin owns it), and restart Access using
the new user and try it out on a another new file.

The above steps might not be complete, but my point is that once you accomplish
the basic task of having an MDB file (even an empty one) that cannot be opened
with any workgroup file except the secured one you created then you can easily
progress from that point. Any new files you create while using that workgroup
will automatically be secured. All that is left is setting permissions on
individual objects which might be "tedious", but is not complex or difficult.

For existing apps you just start with a new blank secured file, make sure that
Admin and Users have no rights to "new" objects of any kind and then import
everything from the desired file. Since all of the imported objects are "new"
then they should automatically be inaccessible to Admin and Users and your
database object ownership is already taken care of since you created the file
with your new master account.