Workgroup file security failure?

[Guest]

I've created several workgroup files to secure different databases. While
testing different scenarios I noticed the following

I renamed the workgroupfile that I was joined to, lets say from abcd.mdw to
abcd.old and when I started access and open the DB, it DID NOT asked me for
any user/password, and now the Acess was joined to a system3.mdw created on
the default directory for workgroup files.

Is this a normal behavior?

Is this a security breach?

Thanks

 

[Joan Wild]

I've created several workgroup files to secure different databases.
While testing different scenarios I noticed the following

I renamed the workgroupfile that I was joined to, lets say from
abcd.mdw to abcd.old and when I started access and open the DB, it
DID NOT asked me for any user/password, and now the Acess was joined
to a system3.mdw created on the default directory for workgroup files.

Since it couldn't find the mdw that was set as the default, it automatically
created a new system.mdw (normal behaviour)

If this worked (i.e. you were able to open your 'secure' mdb), then you did
not secure it properly. You should only be able to open the mdb using the
appropriate mdw.

 

[Guest]

Yes, that's my concern, my DBs are not secure.

If the normal behavior is to create a new mdw file when the default file
does not exist, I think that the new mdw file has an Admin user with blank
password and that's why it allowed me to open the DB. Is this assumption
correct?

Is it possible to disable the new mdw file creation?

Thanks

 

[Joan Wild]

No you can't disable the new mdw file creation. That really isn't the
issue. If you follow the steps in the security FAQ (every step, in order,
missing none), then they won't be able to open your mdb using any mdw file.
They *must* use the mdw you created to secure the database with. You've
missed a step somewhere.
Security FAQ
http://support.microsoft.com/?id=207793

Security Whitepaper
http://support.microsoft.com/?id=148555

Although the whitepaper is old, it contains information to help you
understand security.

I've also outlined the detailed steps at
www.jmwild.com/AccessSecurity.htm

 

[Guest]

Okay. Let me take a look to this documents, I used the one on
http://support.microsoft.com/kb/823927/en-us
to secure my databases, thinking this was the correct one.

Maybe I can find differences with yours.

Anyway, let's think I made something wrong, the fact is that I could open my
DB with no user/password at all, don't you think this is a problem with
Access security?

Thanks

 

[Joan Wild]

Anyway, let's think I made something wrong, the fact is that I could
open my DB with no user/password at all, don't you think this is a
problem with Access security?

No it isn't. The problem is that you did not secure it properly - it's not
a fault with Access security.

 

[Guest]

Okay.

Can I create several mdw files for different databases? Is this the correct
way to protect differente DBs or you recommend other way?

I'm using the DBs from Visual Basic and C# applications, is the procedure
for securing DBs the same or there is another procedure for these cases? Any
recommendations?

Thanks

 

[Guest]

I've checked all documents and the part I was missing is the part regarding
the use of the Wizard. I applied the procedure on your website
(www.jmwild.com/AccessSecurity.htm) and it seems to be working fine. What I
can conclude is that you can have all DBs secured in a single mdw file, is
this correct?

Now I have 3 more questions:
1. What is the procedure to convert the rest of my DBs (each one with its
own mdw file) to s single file schema? I noticed that when I tried to do
that, the wizard told me that the DB was created with another user.

2. How can I change to the single mdw file in production environments, just
replacing the mdw file with the new one?

3. Can I have the mdw file and the DB in a mapped drive for a network
environment and run the wizard from it, in order to have my multiuser
application running with the secured DB?

Thanks

 

[Joan Wild]

What I can conclude is that you can have all DBs
secured in a single mdw file, is this correct?

Yes, you can secure many mdb files with a single mdw. The mdw contains
users, groups, passwords - so think of it in that context. You would create
a separate mdw only if you had a completely different set of groups/users.

Now I have 3 more questions:
1. What is the procedure to convert the rest of my DBs (each one with
its own mdw file) to s single file schema? I noticed that when I
tried to do that, the wizard told me that the DB was created with
another user.

You would first unsecure the mdb. Login in using the mdw it was secured
with. Give full permissions to all objects to the Users Group. Rejoin the
standard system.mdw workgroup. Close/re-open Access (no login) and create a
new database. Import all objects from your mdb. This new mdb is unsecured.
Now join the workgroup you wish to secure it with and proceed to re-secure
it. You might find the utility at www.daiglenet.com (dbutilities 1.0)
helpful in scripting out the permissions and reapplying them.

2. How can I change to the single mdw file in production
environments, just replacing the mdw file with the new one?

That and also replacing the mdb, as it contains the changed permissions.

3. Can I have the mdw file and the DB in a mapped drive for a network
environment and run the wizard from it, in order to have my multiuser
application running with the secured DB?

Not necessary, and could create problems. You can secure it on your
computer, and then just copy the mdw and mdb to the network share. Give
each user a desktop shortcut to launch the mdb. The target would look like
"path to msaccess.exe" "path to mdb" /wrkgrp "path to secure mdw"

Also you can use UNC pathnames (\\server\share )rather than using a mapped
drive.

You should split your mdb into frontend/backend. The frontend contains
everything except tables/relationships; the backend just the tables. A copy
of the frontend is put on each user's computer, and contains linked tables -
linked to the backend on the server. Since you've secured the mdb, you'll
want to split it manually - more details on my site.

 

[Guest]

After re-securing my DBs, is it possible to put mdbs and mdws in different
paths (different from where they were created and secured, and different
between them) in my production environment and just provide the new paths to
the VB (no VBA)applications that use this DBs?

Thanks

 

[Rick Brandt]

After re-securing my DBs, is it possible to put mdbs and mdws in
different paths (different from where they were created and secured,
and different between them) in my production environment and just
provide the new paths to the VB (no VBA)applications that use this
DBs?

MDW do not "care" where MDBs are located nor do MDBs "care" where MDW fiels
are. There is no link between them.

If you use a command line argument to specify which MDW file to use and
which MDB to open then that command line certainly cares about the location
of both files, but that should be the only thing that matters.

 

[Joan Wild]

Sure, the mdbs and mdws are not 'linked' in any way. The mdw just
authenticates a user for a session. The permissions are stored in the mdb.

It does not matter where they are stored. One caveat - if they will be in
the same folder, ensure you give them different names. Each need to create
a ldb file, and can't if they both have the same name.

 

[Guest]

I've just changed one of my DB to the single workgroup file schema, following
step by step your procedure and I'm having problems. My comments on your
procedure below.

1. After Importing the objects of the old DB to the new DB and after joining
to the new wrkgp, I received a message stating that the DB is corrupt or in
another format. (Obviously that is not true, I could open it after restarting
Access). I don't know if before joining the wrkgp, Access should be restarted.

2. You said "As a final test, open Windows Explorer, locate your secure mdb
and double-click it. You should not be able to open the database at all."

I could open the DB with no username/password, and it makes sense to me,
because when you double click the DB, it launches Access, and it is attached
to the defaul wrkgrp, becasue thats what we made in a previous step.

Finally, I don't know if this kind of security should protect DB against
open it with other program. For instance I Open the DB with NOTEPAD and I
could erase parts of what was showed in the screen (encrypted) and could save
it.

Thanks

 

[TC]

I haven't read this whole thread, so apologies if this has been covered
before:

I could open the DB with no username/password, and it makes sense to me,
because when you double click the DB, it launches Access, and it is attached
to the defaul wrkgrp, becasue thats what we made in a previous step.

No. You should /not/ join the securing workgroup file. If you do, then,
everyone is prompted to enter a username/password, even when they try
to open an /unsecured/ database. That is generally not what you want.
Instead, you should stay joined to the default (unchanged) workgroup
file. Then, to start a secured database, you use a shortcut of the
following format:

(all on one line)

"full path to MSACCESS.EXE"
"full path to secured database file"
/wrkgrp "full pah to securing workgroup file"

Finally, I don't know if this kind of security should protect DB against
open it with other program. For instance I Open the DB with NOTEPAD and I
could erase parts of what was showed in the screen (encrypted) and could save it.

If you do that, then, it probably won't open or run correctly. There's
no way you could successfully edit an encrypted database file - secured
or otherwise - using a text editor.

HTH,
TC [MVP Access]

 

[Joan Wild]

1. After Importing the objects of the old DB to the new DB and after
joining to the new wrkgp, I received a message stating that the DB is
corrupt or in another format. (Obviously that is not true, I could
open it after restarting Access). I don't know if before joining the
wrkgp, Access should be restarted.

Well you should join the new workgroup (and login as the user you want to
own everything) before creating the new DB and import objects from the old
one.

2. You said "As a final test, open Windows Explorer, locate your
secure mdb and double-click it. You should not be able to open the
database at all."

I could open the DB with no username/password, and it makes sense to
me, because when you double click the DB, it launches Access, and it
is attached to the defaul wrkgrp, becasue thats what we made in a
previous step.

But the previous step (#3 in Final Steps), says to rejoin the standard
system.mdw that ships with Access. So you are correct if you didn't follow
step 3. Try it again, but first rejoin system.mdw.

Finally, I don't know if this kind of security should protect DB
against
open it with other program. For instance I Open the DB with NOTEPAD
and I could erase parts of what was showed in the screen (encrypted)
and could save it.

Using the wizard will encrypt the database, but since you secured it
manually, it's not encrypted. You need to use Tools, Security, encrypt.