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

Multi user enviroment - part II

P: n/a
I have a multi user database and users were created by user level security
wizzard - as I mentioned in message before. Everything works fine for those
users, but now I have another problem. I have another database with linked
tables from secured database.
How can I approach secured database from the unsecure one?

Thx
Dec 5 '07 #1
Share this Question
Share on Google+
31 Replies


P: n/a
"zdenko" <zs******@gmail.comwrote in message
news:fj*********@ss408.t-com.hr...
>I have a multi user database and users were created by user level security
wizzard - as I mentioned in message before. Everything works fine for those
users, but now I have another problem. I have another database with linked
tables from secured database.
How can I approach secured database from the unsecure one?
You can't, otherwise security wouldn't be much use. You'd need to open your
*unsecured* database whilst joined to your custom workgroup so that the
linked tables would work.

Keith.
www.keithwilby.com

Dec 5 '07 #2

P: n/a
OK, but how can I join workgroup from unsecured database to secured?

You can't, otherwise security wouldn't be much use. You'd need to open
your *unsecured* database whilst joined to your custom workgroup so that
the linked tables would work.

Keith.
www.keithwilby.com

Dec 5 '07 #3

P: n/a
"zdenko" <zs******@gmail.comwrote in message
news:fj**********@ss408.t-com.hr...
OK, but how can I join workgroup from unsecured database to secured?

Use a desktop shortcut to open your unsecured mdb using the "/wrkgrp"
switch:

"Full path to MSACCESS.EXE" "Full path to your unsecured database.mdb"
/wrkgrp "Full path to your workgroup file.mdw"

including quotation marks.

Keith.
www.keithwilby.com

Dec 6 '07 #4

P: n/a
Thanks for correct answer. It crosses my mind before and I've tried it but
shortcut was misspelled.
I have billing application whitch conists of two databases. Employers are
entering data in first and the other
database should be triggered once a day and make some file for delivering.
Idea is triggering by scheduler.
Now I have issue concerning security of "usecured" database because every
time it's triggered username / password dialog pops up.
Is there a way to avoid this pop up window?
"Keith Wilby" <he**@there.comwrote in message
news:47**********@glkas0286.greenlnk.net...
"zdenko" <zs******@gmail.comwrote in message
news:fj**********@ss408.t-com.hr...
>OK, but how can I join workgroup from unsecured database to secured?


Use a desktop shortcut to open your unsecured mdb using the "/wrkgrp"
switch:

"Full path to MSACCESS.EXE" "Full path to your unsecured database.mdb"
/wrkgrp "Full path to your workgroup file.mdw"

including quotation marks.

Keith.
www.keithwilby.com

Dec 6 '07 #5

P: n/a
Your problem is that you are trying to perform Enterprise operations
with a Micro database system (Access).

Access is quite remarkable for a Micro database system, but it is still
a Micro database system and does not have Enterprise capabilities. For
that you need to step up to an Enterprise system like MS Sql Server.

Rich

*** Sent via Developersdex http://www.developersdex.com ***
Dec 6 '07 #6

P: n/a

"zdenko" <zs******@gmail.comschreef in bericht news:fj**********@ss408.t-com.hr...
Thanks for correct answer. It crosses my mind before and I've tried it but
shortcut was misspelled.
I have billing application whitch conists of two databases. Employers are
entering data in first and the other
database should be triggered once a day and make some file for delivering.
Idea is triggering by scheduler.
Now I have issue concerning security of "usecured" database because every
time it's triggered username / password dialog pops up.
Is there a way to avoid this pop up window?
If I understand you correctly you want to open the database scheduled, but you need passwords and a login ??
You can avoid the pop-up by providing the password and user with switches in your shortcut like /user "Username" /pwd "Password"

BUT of course security might be ALL gone now .... (everyone can read the shortcut)
BUT maybe this helps ...

Arno R
Dec 6 '07 #7

P: n/a
I will try your suggestion tomorow. Second database has linked tables to
secure one and
this database/application is on secured computer. All I need is starting
application/database when
computer is locked.

Dec 6 '07 #8

P: n/a
Just tried and it works! That's all I want this application to do. Thank's
very much!
Dec 6 '07 #9

P: n/a
Rich P wrote:
Your problem is that you are trying to perform Enterprise operations
with a Micro database system (Access).

Access is quite remarkable for a Micro database system, but it is still
a Micro database system and does not have Enterprise capabilities. For
that you need to step up to an Enterprise system like MS Sql Server.

Rich

*** Sent via Developersdex http://www.developersdex.com ***
Absolutely agreed. It's amazing how much time we as developers have to
spend trying to get Access, which was originally designed as a desktop
database, to behave as though it were a large scale Enterprise-level db
system like SQL Server or Oracle.

It's just that it's so much cheaper and simpler. And that's not even the
worst part. It's that it makes it so easy for users who don't really
know what they're doing to create really badly designed databases and
applications. Then, a year and a half later, after it's completely
broken down, is when they call us and ask us to fix "just this one
thing", and it turns out that the only way to do that is to completely
re-design the entire thing from the ground up.

Which, of course, requires the users to sit down and actually think
things all the way through, which is something they really don't like to do.

But, of course, if they'd been spending big bucks and deploying SQL
Server or Oracle, they would have *had* to do that.

Access...MS's little gift to us all!
Dec 9 '07 #10

P: n/a
Keith Wilby wrote:
"Full path to MSACCESS.EXE" "Full path to your unsecured database.mdb"
/wrkgrp "Full path to your workgroup file.mdw"

including quotation marks.
That reminds me of another question...is there a group policy in Windows
2003 that prevents the users from right clicking on a desktop icon and
viewing its properties? Because, if there isn't, then how does one
prevent some enterprising young power user from reading the target
property and simply using Windows Exploder to navigate to the
application file directly, thus completely bypassing the app's dedicated
mdw file? Wouldn't you basically have to turn off access to Windows
Explorer and all it's manifestations, including My Computer?
Dec 9 '07 #11

P: n/a
Fester Bestertester <wh*********@mad.netwrote in
news:pn*******************@newsfe11.phx:
Keith Wilby wrote:
>"Full path to MSACCESS.EXE" "Full path to your unsecured
database.mdb" /wrkgrp "Full path to your workgroup file.mdw"

including quotation marks.

That reminds me of another question...is there a group policy in
Windows 2003 that prevents the users from right clicking on a
desktop icon and viewing its properties? Because, if there isn't,
then how does one prevent some enterprising young power user from
reading the target property and simply using Windows Exploder to
navigate to the application file directly, thus completely
bypassing the app's dedicated mdw file? Wouldn't you basically
have to turn off access to Windows Explorer and all it's
manifestations, including My Computer?
If you set up Access security correctly, using any other .mdw will
not allow the database to open.
--
Bob Quintal

PA is y I've altered my email address.

--
Posted via a free Usenet account from http://www.teranews.com

Dec 9 '07 #12

P: n/a
Fester Bestertester wrote:
That reminds me of another question...is there a group policy in
Windows 2003 that prevents the users from right clicking on a desktop
icon and viewing its properties? Because, if there isn't, then how
does one prevent some enterprising young power user from reading the
target property and simply using Windows Exploder to navigate to the
application file directly, thus completely bypassing the app's
dedicated mdw file? Wouldn't you basically have to turn off access to
Windows Explorer and all it's manifestations, including My Computer?
You clearly don't know how Access security works. That is, when it is done
properly which I estimate to be less than 5% of the time.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Dec 9 '07 #13

P: n/a
"Fester Bestertester" <wh*********@mad.netwrote in message
news:pn*******************@newsfe11.phx...
Keith Wilby wrote:
>"Full path to MSACCESS.EXE" "Full path to your unsecured database.mdb"
/wrkgrp "Full path to your workgroup file.mdw"

including quotation marks.

That reminds me of another question...is there a group policy in Windows
2003 that prevents the users from right clicking on a desktop icon and
viewing its properties? Because, if there isn't, then how does one prevent
some enterprising young power user from reading the target property and
simply using Windows Exploder to navigate to the application file
directly, thus completely bypassing the app's dedicated mdw file? Wouldn't
you basically have to turn off access to Windows Explorer and all it's
manifestations, including My Computer?
Are you really the same poster as the one who posted security advice in the
"Thinking about going multiuser with user security,..." thread?

Dec 10 '07 #14

P: n/a

"Keith Wilby" <he**@there.comschreef in bericht news:47**********@glkas0286.greenlnk.net...
"Fester Bestertester" <wh*********@mad.netwrote in message
news:pn*******************@newsfe11.phx...
>Keith Wilby wrote:
>>"Full path to MSACCESS.EXE" "Full path to your unsecured database.mdb"
/wrkgrp "Full path to your workgroup file.mdw"

including quotation marks.

That reminds me of another question...is there a group policy in Windows
2003 that prevents the users from right clicking on a desktop icon and
viewing its properties? Because, if there isn't, then how does one prevent
some enterprising young power user from reading the target property and
simply using Windows Exploder to navigate to the application file
directly, thus completely bypassing the app's dedicated mdw file? Wouldn't
you basically have to turn off access to Windows Explorer and all it's
manifestations, including My Computer?
Are you really the same poster as the one who posted security advice in the
"Thinking about going multiuser with user security,..." thread?
Amazing indeed.
This reminds me of another 'resource' who once posted here...

Arno R
Dec 10 '07 #15

P: n/a
"Arno R" <ar****************@planet.nlwrote in message
news:47***********************@text.nova.planet.nl ...

"Keith Wilby" <he**@there.comschreef in bericht
news:47**********@glkas0286.greenlnk.net...
>"Fester Bestertester" <wh*********@mad.netwrote in message

Are you really the same poster as the one who posted security advice in
the
"Thinking about going multiuser with user security,..." thread?
Amazing indeed.
This reminds me of another 'resource' who once posted here...
<shudder>

Some prospects don't even bear thinking about ;-)

Dec 10 '07 #16

P: n/a
Keith Wilby wrote:
Are you really the same poster as the one who posted security advice in
the "Thinking about going multiuser with user security,..." thread?
I deeply appreciate all the technical feedback actually answering my
question. Since it's now so obvious that I'm an incompetent fool who
shouldn't be anywhere near a computer, let's review.

Let's say for the sake of discussion that I have a multi-user database
that's split between a back end (data only) and a front end
(application). The back end resides on a server and the front end is on
the user's machine.

Let's further say for the sake of discussion that I've already added and
tested a set of modules triggered by an AutoExec macro that verifies
that the link from front to back is valid, and, if not, raises a File |
Open dialog that allows the user (or a sysadmin) to point the front end
to the correct path if necessary.

Now let's suppose that I want security which is specific to that
application only, and does not affect any other instances of Access on
the local machine, even though, in that same thread, "Thinking about
going multiuser with user security..." one "Lyle Fairfield" posted,
"Many developers do almost none of the above, with the exception of
splitting their applications. I am one of them."

To accomplish this, I would perform the following steps:

1. Open an empty session of Access.

2. Select Tools | Security | Workgroup Administrator...

3. Select Create...

4. Give the new security file an ID, note the User, Organization, and ID
information, and click OK.

5. Browse to the appropriate location where I wish to store the mdw file
and name the file, i.e., MyApp.mdw.

6. Select Tools | Security | Workgroup Administrator, select Join, and
navigate to the new mdw file.

7. Select Tools | Security | User and Group Accounts, and create the
users and groups I wish to have.

8. Select Tools | Security | User and Group Permissions, and configure
the permissions for the groups.

9. Select Tools | Security | Workgroup Administrator, select Join, and
re-join the default System.mdw file.

10. For distribution, copy the backend database file to a shared
directory, copy the front end application file to the user's machine,
and copy the security file to a shared directory.

11. At this point, according to MSKB article 305542, "Understanding the
role of workgroup information files in Access security":

"To associate specific secured database files with their workgroup
information files, you must create desktop shortcuts. Each desktop
shortcut must have the Command-Line option set to start a specific
database and use the specific workgroup information file secured with
that database.

"To start a secured Access database named MyApp.mdb in a folder named
MyAppFolder with the workgroup information file used when establishing
security on MyApp.mdb, the command-line syntax must include the /WrkGrp
command-line switch, for example:

"C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
"C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\System.MDW"

"You can create a shortcut and enter this syntax as the target of the
shortcut."

12. The result is that there is now security which is specific to this
particular application and does not affect other sessions of Access on
the user's machine.

The user can still run Access, with the default System.mdw, file to open
or create mdb files, but if the user double clicks the desktop shortcut
to the "MyApp.MDB" application, they will get a password prompt using
the security file that is specific to that application.

Unfortunately, this security does not apply if the user opens an empty
session of Access, or opens Windows Explorer, and navigates directly to
the MyApp.mdb file. So it appears that the only way to defeat this would
be to turn off Windows Explorer and/or remove all Access-related icons
from the desktop except the shortcut to MyApp.mdb.

Or, is there something unrelated to desktop lockdown, and specific to
Access security, that I'm missing? It's already been effectively pointed
out that I'm incompetent, so what, exactly, was so obvious about Access
security that anyone should have been able to see it?
Dec 10 '07 #17

P: n/a
Fester Bestertester wrote:
"C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
"C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\System.MDW"
The above was just pasted directly from the article. To clarify for
purposes of my example, the correct target property would be:

"C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
"C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\MyApp.MDW"
Dec 10 '07 #18

P: n/a
"Fester Bestertester" <wh*********@mad.netwrote in message
news:fj**********@gondor.sdsu.edu...
Keith Wilby wrote:
<snip>
>
Unfortunately, this security does not apply if the user opens an empty
session of Access, or opens Windows Explorer, and navigates directly to
the MyApp.mdb file. So it appears that the only way to defeat this would
be to turn off Windows Explorer and/or remove all Access-related icons
from the desktop except the shortcut to MyApp.mdb.
If users can do this then you've missed one or more steps in the securing
process, likely you haven't denied access to the "users" group and left the
"Admin" user as part of the "Admins" group. ULS would be completely useless
if the scenario was as you've stated.
>
Or, is there something unrelated to desktop lockdown, and specific to
Access security, that I'm missing? It's already been effectively pointed
out that I'm incompetent, so what, exactly, was so obvious about Access
security that anyone should have been able to see it?
This probably:

http://support.microsoft.com/default...t%2Fsecfaq.asp

Dec 11 '07 #19

P: n/a
"Fester Bestertester" <wh*********@mad.netwrote in message
news:fj**********@gondor.sdsu.edu...
Fester Bestertester wrote:
>"C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
"C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\System.MDW"

The above was just pasted directly from the article. To clarify for
purposes of my example, the correct target property would be:

"C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
"C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\MyApp.MDW"
It doesn't look like you've taken ownership of the database object in your
example either.

Dec 11 '07 #20

P: n/a
Fester Bestertester wrote:
I deeply appreciate all the technical feedback actually answering my
question. Since it's now so obvious that I'm an incompetent fool who
shouldn't be anywhere near a computer, let's review.
[snip]

Following the procedure you outlined the resulting database would still be
"owned" by the default user "Admin" and THAT is why anyone using any workgroup
would be able to open it.

Step 6 would make the new workgroup file your default, but it would not make it
the workgroup file currently in use. You have to close Access and then re-open
it using the new workgroup file logging in as a user that is NOT "Admin" before
you create your database. When securing an existing file you would need to
create a new one and import all objects from the existing one. Otherwise you
are still using a file where all objects are owned by "Admin".

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Dec 11 '07 #21

P: n/a
Keith Wilby wrote:
If users can do this then you've missed one or more steps in the
securing process, likely you haven't denied access to the "users" group
and left the "Admin" user as part of the "Admins" group. ULS would be
completely useless if the scenario was as you've stated.
This probably:

http://support.microsoft.com/default...t%2Fsecfaq.asp
So remember back in 2004 when James Carville put a bucket on his head
after predicting that Kerry was going to win in a landslide? Looks like
I'm wearing the bucket. I probably read this way back when and forgot
it. Just shows to go how long it's been since I set one of these up.

From Step #6: "Remove the Admin user from the Admins group so that
Admin is a member only of the Users group."

From Step #7: "Open the database that you want to secure and run the
Security Wizard. Note that the Access 2000 (2K3) security wizard does
not create a new database—it simply creates a backup copy of the
original. One flaw with this arrangement is that not all permissions to
open the database are removed from the Admin user and Users group to
open the database, even though they appear to have been removed."

From Step #10: "The Access 2000 (2K3) Security Wizard removes
permissions to the point where they are not visible on the security
menus, but testing has revealed that in Access 2000 it is possible to
open a database by using the default workgroup information file
regardless of the menu settings. The cure for both versions of Access is
to create a new, empty database while logged on as a member of the
Admins group and import all of the objects from the secured database.
You should take this step before spending too much time securing objects
because Access considers imported objects to be “new” and loses the
permission information that was stored in the source database."

In addition it does appear that if you follow Step #6 and log then in
under the new Admin member's credentials, when you run the security
wizard it assigns ownership of the database to the new Admin account.
And this does seem to defeat the ability to open the file while
bypassing security. But it still seems you'd want to have the mdw file
and the source data file tucked away somewhere where people can't get at
it easily anyway.

Guess I'll punch a couple of holes in that bucket.
Dec 12 '07 #22

P: n/a
"Fester Bestertester" <wh*********@mad.netwrote in message
news:fj**********@gondor.sdsu.edu...
>
In addition it does appear that if you follow Step #6 and log then in
under the new Admin member's credentials, when you run the security wizard
it assigns ownership of the database to the new Admin account.
I see no need for the wizard once you've fully understood the methods.
And this does seem to defeat the ability to open the file while bypassing
security. But it still seems you'd want to have the mdw file and the
source data file tucked away somewhere where people can't get at it easily
anyway.
It's good practice to put the workgroup and data files on a hidden share.
Dec 12 '07 #23

P: n/a
"Gerry Hatrick" <a@b.comwrote:
>And this does seem to defeat the ability to open the file while bypassing
security. But it still seems you'd want to have the mdw file and the
source data file tucked away somewhere where people can't get at it easily
anyway.

It's good practice to put the workgroup and data files on a hidden share.
Security by obscurity is only an illusion.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Dec 14 '07 #24

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:el********************************@4ax.com:
Security by obscurity is only an illusion.

Tony
Osama could come to Red Deer?

--
lyle fairfield
Dec 14 '07 #25

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:el********************************@4ax.com:
"Gerry Hatrick" <a@b.comwrote:
>>And this does seem to defeat the ability to open the file while
bypassing security. But it still seems you'd want to have the
mdw file and the source data file tucked away somewhere where
people can't get at it easily anyway.

It's good practice to put the workgroup and data files on a hidden
share.

Security by obscurity is only an illusion.
If it's all you're doing, sure, but anything that will slow down the
knowledgable (even as little as this would) and stymy the ignorant
seems like worth doing. Sometimes this type of thing just keeps out
the bumblers who might accidentally cause problems, which is, I
think, worth it.

By the way, have you ever considered incorporating a SYSTEM.MDW
copying routine into your Auto Updater? I have one major app where
the workgroup file is copied to the local machine because there were
problems sharing it on the server. But to push out changes to it, I
have to tell people to upgrade their whole front end (the batch file
to do that includes copying the workgroup file).

Or does it already handle that? Does it copy everything in the
designated folder on the server? As you can see, it's been a while
since I've mucked around with the setup on my implementations of
your updater!

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Dec 14 '07 #26

P: n/a
"David W. Fenton" <XX*******@dfenton.com.invalidwrote:
>Security by obscurity is only an illusion.

If it's all you're doing, sure, but anything that will slow down the
knowledgable (even as little as this would) and stymy the ignorant
seems like worth doing. Sometimes this type of thing just keeps out
the bumblers who might accidentally cause problems, which is, I
think, worth it.
Yeah, so long as you understand that this will only keep out the bumblers.
>By the way, have you ever considered incorporating a SYSTEM.MDW
copying routine into your Auto Updater? I have one major app where
the workgroup file is copied to the local machine because there were
problems sharing it on the server. But to push out changes to it, I
have to tell people to upgrade their whole front end (the batch file
to do that includes copying the workgroup file).

Or does it already handle that? Does it copy everything in the
designated folder on the server? As you can see, it's been a while
since I've mucked around with the setup on my implementations of
your updater!
Yes, it does copy every file in the designated folder.

FWIW the two enhancements highest on my list for the Auto FE Updater are the ability
to copy sub folders and their contents and a GUI so you no longer need to use cryptic
commands in Notepad.

Copying sub folders and thier files is not a trivial task. Finding a list of files
to be updated requires that you go through all the sub folders files on the server
and then go through all the sub folders and files on the target system. Then you
need to figure out which files need to be deleted on the target system because they
were deleted on the server. Now what about stray files created by the user on the
target system? There are one or two other factors as well that I can't recall right
now.

Also how do I store those files inside VB to ensure I can efficiently locate them in
memery later? A simple array which would give good performance for 100 files but
would be terrible for 1000 files. That is 100 items might require going through the
array 100*99 times. But 1000 would require going through the array 1000*999. So
you're suddently going from 9,900 lookups to 990,000. Very uncool.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Dec 15 '07 #27

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in message
news:ip********************************@4ax.com...
"David W. Fenton" <XX*******@dfenton.com.invalidwrote:
>>Security by obscurity is only an illusion.

If it's all you're doing, sure, but anything that will slow down the
knowledgable (even as little as this would) and stymy the ignorant
seems like worth doing. Sometimes this type of thing just keeps out
the bumblers who might accidentally cause problems, which is, I
think, worth it.

Yeah, so long as you understand that this will only keep out the bumblers.
Which is precisely why I suggested it :)

There's always someone who likes to "tidy up" the server ;-)
Dec 16 '07 #28

P: n/a
On Dec 10 2007, 10:33 am, Fester Bestertester <whatmewo...@mad.net>
wrote:
Keith Wilby wrote:
Are you really the same poster as the one who posted security advice in
the "Thinking about going multiuser with user security,..." thread?

I deeply appreciate all the technical feedback actually answering my
question. Since it's now so obvious that I'm an incompetent fool who
shouldn't be anywhere near a computer, let's review.

Let's say for the sake of discussion that I have a multi-user database
that's split between a back end (data only) and a front end
(application). The back end resides on a server and the front end is on
the user's machine.

Let's further say for the sake of discussion that I've already added and
tested a set of modules triggered by an AutoExec macro that verifies
that the link from front to back is valid, and, if not, raises a File |
Open dialog that allows the user (or a sysadmin) to point the front end
to the correct path if necessary.

Now let's suppose that I want security which is specific to that
application only, and does not affect any other instances of Access on
the local machine, even though, in that same thread, "Thinking about
going multiuser with user security..." one "Lyle Fairfield" posted,
"Many developers do almost none of the above, with the exception of
splitting their applications. I am one of them."

To accomplish this, I would perform the following steps:

1. Open an empty session of Access.

2. Select Tools | Security | Workgroup Administrator...

3. Select Create...

4. Give the new security file an ID, note the User, Organization, and ID
information, and click OK.

5. Browse to the appropriate location where I wish to store the mdw file
and name the file, i.e., MyApp.mdw.

6. Select Tools | Security | Workgroup Administrator, select Join, and
navigate to the new mdw file.

7. Select Tools | Security | User and Group Accounts, and create the
users and groups I wish to have.

8. Select Tools | Security | User and Group Permissions, and configure
the permissions for the groups.

9. Select Tools | Security | Workgroup Administrator, select Join, and
re-join the default System.mdw file.

10. For distribution, copy the backend database file to a shared
directory, copy the front end application file to the user's machine,
and copy the security file to a shared directory.

11. At this point, according to MSKB article 305542, "Understanding the
role of workgroup information files in Access security":

"To associate specific secured database files with their workgroup
information files, you must create desktop shortcuts. Each desktop
shortcut must have the Command-Line option set to start a specific
database and use the specific workgroup information file secured with
that database.

"To start a secured Access database named MyApp.mdb in a folder named
MyAppFolder with the workgroup information file used when establishing
security on MyApp.mdb, the command-line syntax must include the /WrkGrp
command-line switch, for example:

"C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
"C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\System.MDW"

"You can create a shortcut and enter this syntax as the target of the
shortcut."

12. The result is that there is now security which is specific to this
particular application and does not affect other sessions of Access on
the user's machine.

The user can still run Access, with the default System.mdw, file to open
or create mdb files, but if the user double clicks the desktop shortcut
to the "MyApp.MDB" application, they will get a password prompt using
the security file that is specific to that application.

Unfortunately, this security does not apply if the user opens an empty
session of Access, or opens Windows Explorer, and navigates directly to
the MyApp.mdb file. So it appears that the only way to defeat this would
be to turn off Windows Explorer and/or remove all Access-related icons
from the desktop except the shortcut to MyApp.mdb.

Or, is there something unrelated to desktop lockdown, and specific to
Access security, that I'm missing? It's already been effectively pointed
out that I'm incompetent, so what, exactly, was so obvious about Access
security that anyone should have been able to see it?
I had the same problem securing my database. The work-around that I
used to prevent unauthorized access to the original database was to
remove permissions for the admin user, the default user for any access
database, in the database I secured and linked the private
Security.MDW to.
I then inserted a little chunk of code that executes on startup that
checks the username. If the username is "admin", the code displays a
message telling the user that they must open the database using the
designated shortcut. The code then closes the database.
This method has worked for me. It's not pretty but it works.

-- Enoch Norton
Jan 15 '08 #29

P: n/a
I heard Access-Vista does not use MDW files or security, and Microsoft now
expects the security to be based on User Access Rights. If you want
security then they expect you to use SQL Server.

Is that a vicious rumour?? I know I might have some facts wrong, but I'm
sure security has changed in some way.
Dominic

<en**********@gmail.comwrote in message
news:1d**********************************@h11g2000 prf.googlegroups.com...
On Dec 10 2007, 10:33 am, Fester Bestertester <whatmewo...@mad.net>
wrote:
>Keith Wilby wrote:
Are you really the same poster as the one who posted security advice in
the "Thinking about going multiuser with user security,..." thread?

I deeply appreciate all the technical feedback actually answering my
question. Since it's now so obvious that I'm an incompetent fool who
shouldn't be anywhere near a computer, let's review.

Let's say for the sake of discussion that I have a multi-user database
that's split between a back end (data only) and a front end
(application). The back end resides on a server and the front end is on
the user's machine.

Let's further say for the sake of discussion that I've already added and
tested a set of modules triggered by an AutoExec macro that verifies
that the link from front to back is valid, and, if not, raises a File |
Open dialog that allows the user (or a sysadmin) to point the front end
to the correct path if necessary.

Now let's suppose that I want security which is specific to that
application only, and does not affect any other instances of Access on
the local machine, even though, in that same thread, "Thinking about
going multiuser with user security..." one "Lyle Fairfield" posted,
"Many developers do almost none of the above, with the exception of
splitting their applications. I am one of them."

To accomplish this, I would perform the following steps:

1. Open an empty session of Access.

2. Select Tools | Security | Workgroup Administrator...

3. Select Create...

4. Give the new security file an ID, note the User, Organization, and ID
information, and click OK.

5. Browse to the appropriate location where I wish to store the mdw file
and name the file, i.e., MyApp.mdw.

6. Select Tools | Security | Workgroup Administrator, select Join, and
navigate to the new mdw file.

7. Select Tools | Security | User and Group Accounts, and create the
users and groups I wish to have.

8. Select Tools | Security | User and Group Permissions, and configure
the permissions for the groups.

9. Select Tools | Security | Workgroup Administrator, select Join, and
re-join the default System.mdw file.

10. For distribution, copy the backend database file to a shared
directory, copy the front end application file to the user's machine,
and copy the security file to a shared directory.

11. At this point, according to MSKB article 305542, "Understanding the
role of workgroup information files in Access security":

"To associate specific secured database files with their workgroup
information files, you must create desktop shortcuts. Each desktop
shortcut must have the Command-Line option set to start a specific
database and use the specific workgroup information file secured with
that database.

"To start a secured Access database named MyApp.mdb in a folder named
MyAppFolder with the workgroup information file used when establishing
security on MyApp.mdb, the command-line syntax must include the /WrkGrp
command-line switch, for example:

"C:\Program Files\Microsoft Office\Office\MSAccess.Exe"
"C:\MyAppFolder\MyApp.MDB" /wrkgrp "C:\MyAppFolder\System.MDW"

"You can create a shortcut and enter this syntax as the target of the
shortcut."

12. The result is that there is now security which is specific to this
particular application and does not affect other sessions of Access on
the user's machine.

The user can still run Access, with the default System.mdw, file to open
or create mdb files, but if the user double clicks the desktop shortcut
to the "MyApp.MDB" application, they will get a password prompt using
the security file that is specific to that application.

Unfortunately, this security does not apply if the user opens an empty
session of Access, or opens Windows Explorer, and navigates directly to
the MyApp.mdb file. So it appears that the only way to defeat this would
be to turn off Windows Explorer and/or remove all Access-related icons
from the desktop except the shortcut to MyApp.mdb.

Or, is there something unrelated to desktop lockdown, and specific to
Access security, that I'm missing? It's already been effectively pointed
out that I'm incompetent, so what, exactly, was so obvious about Access
security that anyone should have been able to see it?

I had the same problem securing my database. The work-around that I
used to prevent unauthorized access to the original database was to
remove permissions for the admin user, the default user for any access
database, in the database I secured and linked the private
Security.MDW to.
I then inserted a little chunk of code that executes on startup that
checks the username. If the username is "admin", the code displays a
message telling the user that they must open the database using the
designated shortcut. The code then closes the database.
This method has worked for me. It's not pretty but it works.

-- Enoch Norton

Jan 16 '08 #30

P: n/a
Dominic Vella wrote:
I heard Access-Vista does not use MDW files or security, and
Microsoft now expects the security to be based on User Access Rights.
If you want security then they expect you to use SQL Server.

Is that a vicious rumour?? I know I might have some facts wrong,
but I'm sure security has changed in some way.
Access 2007 utilizes user level security if you stay with the MDB file format.
If you use the new Accdb file format then it does not. None of which has
anything to do with Vista.

ULS security was never very secure anyway so (IMO) it's no big loss.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com


Jan 17 '08 #31

P: n/a
Rick Brandt wrote:
Dominic Vella wrote:
>I heard Access-Vista does not use MDW files or security, and
Microsoft now expects the security to be based on User Access Rights.
If you want security then they expect you to use SQL Server.

Is that a vicious rumour?? I know I might have some facts wrong,
but I'm sure security has changed in some way.

Access 2007 utilizes user level security if you stay with the MDB file format.
If you use the new Accdb file format then it does not. None of which has
anything to do with Vista.

ULS security was never very secure anyway so (IMO) it's no big loss.
One should never invoke ULS only GLS. Give groups the permissions you
want them to have, then assign users to your groups.
Jan 17 '08 #32

This discussion thread is closed

Replies have been disabled for this discussion.