Where to place the workgroup file

  • Thread starter Thread starter rdemyan via AccessMonster.com
  • Start date Start date
R

rdemyan via AccessMonster.com

My application is workgroup secured. I'd like to know where others are
placing the workgroup file. In a folder on the server where the back-end is
located or on the local PC where the front-end is?

Thanks.
 
Hi.
I'd like to know where others are
placing the workgroup file.
Click to expand...

It's usually placed in the same directory as the back end, unless the files
share the same name (i.e., MyDB.MDB and MyDB.MDW). In that case, the MDW
file is put in a separate directory, because both the MDW file and MDB file
will produce LDB files, and you don't want them both sharing the same LDB
file (i.e., MyDB.LDB). MDW files are commonly named Secure.MDW, to prevent
this and, well, to easily identify them, too. ;-)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
 
Thanks, Gunny:


So, what about my remote users that have a downloaded backend file and
workgroup file on their laptops. My specific issue is: how would you
recommend resetting their passwords if they forget them. The workgroup file
is on their local laptop. Without access to that laptop, I can only reset
the password on the workgroup file located on the server, but I can't think
of any reliable way to propagate (file copy) this modified workgroup file to
their laptop.

I do have an app launching program. I'm considering adding a button to the
launcher that will allow users to download the workgroup file located on the
server to the local PC file where the front end is. This would primarily be
used by remote users. Not an elegant method, but after the password is
reset by an administrator on the server workgroup file, all the remote user
has to do is press the button when they are connected to the LAN to copy the
server workgroup file to their local remote hard drive. Then after the
workgroup file is copied down, the launching program will launch my
application.

Also, if the workgroup file for all users is located on their local PC, there
are two advantages:

1) Faster access in opening my application because the workgroup file is on
the local PC
2) If the local PC workgroup file ever becomes corrupted, it would be an easy
matter to simply filecopy a new copy from the server to the user's local PC
(using my launching application proposed button).

Just some ideas for discussion.
 
Hi.
My specific issue is: how would you
recommend resetting their passwords if they forget them. The workgroup
file
is on their local laptop.
Click to expand...

Either:

1.) You clear their passwords in the common workgroup file located on the
server and they reconnect to the server to download it and copy it over
their existing workgroup file; or

2.) They bring their laptops to any member of the Admins group (hint:
that's you!) who can log into the workgroup on their laptops, and can then
clear their passwords for them.
I can't think
of any reliable way to propagate (file copy) this modified workgroup file
to
their laptop.
Click to expand...

You introduce lots of potential problems when the copy of the database and
the user is disconnected from the main database and the rest of the users.
This is one of those cases where you knew the job was dangerous when you
took it. ;-)
Then after the
workgroup file is copied down, the launching program will launch my
application.
Click to expand...

Sounds like that plan will work. The less manual work for the user, the
better, because automation avoids common user errors and user guesses.
Also, if the workgroup file for all users is located on their local PC,
there
are two advantages:
Click to expand...

.. . . as well as disadvantages:

1.) The user can work at his leisure to break security, because both the
database and the workgroup file can leave the building on that laptop.

2.) You can't prevent a user from logging in by removing his User ID from
the workgroup of the main workgroup, because his laptop workgroup still has
his former User ID and password.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
 
'69 Camaro said:
Hi.


Either:

1.) You clear their passwords in the common workgroup file located on the
server and they reconnect to the server to download it and copy it over
their existing workgroup file; or

2.) They bring their laptops to any member of the Admins group (hint:
that's you!) who can log into the workgroup on their laptops, and can then
clear their passwords for them.
Click to expand...

Exactly what I'm trying to avoid :)
You introduce lots of potential problems when the copy of the database and
the user is disconnected from the main database and the rest of the users.
This is one of those cases where you knew the job was dangerous when you
took it. ;-)


Sounds like that plan will work. The less manual work for the user, the
better, because automation avoids common user errors and user guesses.


. . . as well as disadvantages:

1.) The user can work at his leisure to break security, because both the
database and the workgroup file can leave the building on that laptop.
Click to expand...
I only see this as a problem if a user isn't an administrator. After all,
they can already logon. Of course, the workgroup file that I distribute does
not contain any User ID/PWD info for the Owner and I only distribute .mde
files.
2.) You can't prevent a user from logging in by removing his User ID from
the workgroup of the main workgroup, because his laptop workgroup still has
his former User ID and password.
Click to expand...
Hadn't given this too much thought. About 18 months ago, I added code that
would prevent My app from opening if the license expired. Despite the
workgroup issue, it's really not that hard for users to steal an app and
workgroup file off the server. Maybe I'll dust off that code and use it.
Maybe I could assign a different license type to remote users that would
cause their copies of MyApp to expire. So even if they steal it, they would
have a limited time to cause mischief or steal proprietary designs (assuming
they can't get to the code since it is an .mde; although I heard there is a
little-known way to disable the .mde protection).

Thanks.
 
Hi.
I only see this as a problem if a user isn't an administrator. After all,
they can already logon. Of course, the workgroup file that I distribute
does
not contain any User ID/PWD info for the Owner and I only distribute .mde
files.
Click to expand...

All a user needs is the database, the workgroup file, and a tool (hint:
they're widely available on the Internet) to retrieve a User ID and password
of any member of the Admins group. The user can then create a new database,
import the tables into it (becoming the owner of those tables in the new
database) and then link to the tables in the new database.
Maybe I could assign a different license type to remote users that would
cause their copies of MyApp to expire.
Click to expand...

Expired Access database applications aren't too difficult for someone to
find the trigger that makes them expire and "fix" it.
So even if they steal it, they would
have a limited time to cause mischief or steal proprietary designs
Click to expand...

A good Access developer can copy the design, so it's really not that safe.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
 
Well, let's see. I use RWOP queries in combination with no permissions on
the back-end tables, so I don't think anyone (except the Owner) can import
the front-end table links from MyApp. Since the Owner's UserID/PWD isn't in
the workgroup file distributed, these $30 internet password-cracking programs
shouldn't present a problem for that (but could for other things).

Also, I have a homegrown security that I use on my back-end files. Right now
only I (the Owner) can get in to the back-end files. But given enough time,
clever people can crack the security.

Still, when I first started working with Access, I was appalled at how poor
the security is. I remember, that I spent some time setting up my
application to use a database password. I thought it was fairly secure until
I realized that anyone could easily import everything out of my supposedly
secure app into a new database. That pushed me into RWOP with no permissions
 
Hi.
I use RWOP queries in combination with no permissions on
the back-end tables, so I don't think anyone (except the Owner) can import
the front-end table links from MyApp.
Click to expand...

Log in as a member of the Admins group (not the database owner) and
experiment with what can be done, despite not being the owner. You'll
eventually realize that it doesn't matter that you've secured the tables and
are using RWOP queries to limit access to the data in those tables.
Also, I have a homegrown security that I use on my back-end files. Right
now
only I (the Owner) can get in to the back-end files. But given enough
time,
clever people can crack the security.
Click to expand...

Yes, they can.
Substantially harder to implement, but, at least I
feel like my app is more secure.
Click to expand...

It is more secure than a database password provides, but it's not secure.
Don't use Access (Jet) to store data that requires security. Use a
client/server database engine for secure data storage. A desktop database
file just can't provide that security.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
 
Back
Top