It is not a "gaping hole". It demonstrates, with 100% confidence, that your
database is not secured correctly.

There is no way to "tie" a particular database to a particular workgroup
file. Access selects which workgroup file to use (or is told that via a
shortcut) *before* it has actually opened any database. So the workgroup
file is a "per session" thing, not a "per database" thing.

A user can use *any* workgroup file in an attempt to open a database. But if
the database has been secured correctly, only the right workgroup file will
let him into the database. No other workgroup file will let him into the
database. If some other workgroup file *does* let him into the database,
this demonstrates (with 100% confidence) that the database has not been
secured correctly.

HTH,
TC


"Jack Cannon" <(E-Mail Removed)> wrote in message
news:069101c371db$7fe582b0$(E-Mail Removed)...
> I have an application with various groups and users which
> are assigned different security levels depending on the
> object of concern. It all appears to work properly.
> The link to secured.mdw is accomplished via the
> command line on a desktop icon.
> However if a user attempts to open the application file
> (mdb or mde) directly from Windows Explorer the
> secured.mdw file is bypassed and the application is
> opened with no restrictions placed on the user.
> Obviously this is a gaping hole. It would seem resonable
> that the application should have a mechanism that ensures
> a link to secured.mdw before the application can be
> opened. Does such a mechanism exist?

I have an application with various groups and users which
are assigned different security levels depending on the
object of concern. It all appears to work properly.
The link to secured.mdw is accomplished via the
command line on a desktop icon.
However if a user attempts to open the application file
(mdb or mde) directly from Windows Explorer the
secured.mdw file is bypassed and the application is
opened with no restrictions placed on the user.
Obviously this is a gaping hole. It would seem resonable
that the application should have a mechanism that ensures
a link to secured.mdw before the application can be
opened. Does such a mechanism exist?

To expand on what TC said, I would encourage you to download and
read-read-read the MS Access Security FAQs at
http://support.microsoft.com/default...ent/secfaq.asp .
There are specific steps you must take in order to properly secure your
application, and it's obvious you missed some. Jack McDonald also has a very
good section on security at his web site:
http://www.geocities.com/jacksonmacd...sSecurity.html

--
Scott McDaniel
CS Computer Software
Visual Basic - Access - SQL Server - ASP
www.thedatabaseplace.net

"Jack Cannon" <(E-Mail Removed)> wrote in message
news:097501c3720e$9fd34e80$(E-Mail Removed)...
> Thanks very much TC.
>
> You make the point, "if the database has been secured
> correctly, only the right workgroup file will let him
> into the database". I felt that I had done everything
> correctly and I haven't found anything, so far, in my
> online searches to indicate otherwise. Could you offer
> any guidance on where I might go for information on
> securing the datatbase correctly so that only the right
> workgroup file will let a user into the database?
>
> Jack Cannon

While I would also encourage you to get the security FAQ from MS and read it
thoroughly (several times), your basic problem can be defined this way...

When a user opens Access with a workgroup file that does not prompt them for a
password then they MUST be logging in as the user "Admin". If your database has
granted any permissions to this user then this is a security error that you should
correct.

The user "Admin" is also a member of the "Users" group in ALL workgroup files (as is
any other user). The group "Users" must therefore be stripped of all permissions in
your file.

Owners of databases and the objects contained therein are granted permissions by
virtue of their owner status irrespective of any permissions they have or don't have
on their own or due to memberships in groups. Therefore, the user "Admin" should not
be the owner of your secured database or any of the objects within it.

If you verify these three things then you should at least be to the point where the
default System.mdw file cannot be used to open your database. This does not
guarantee that you have everything concerning security set up correctly, but you will
have achieved the minimum requirement for most applications; that any old body
double-clicking your file won't get in.

Rick,

This is great information. I really appreciate the
detail you provided on the issue. It is clear at this
point that you have correctly diagnosed my problem and I
am well on my way to getting it properly implemented. As
a consequence of your assistance I will also be able to
avoid similar situations in the future.

As far as I am concerned the issue is solved and I really
appreciate your input.

Jack Cannon





>-----Original Message-----
>"Jack Cannon" <(E-Mail Removed)> wrote in message
>news:097501c3720e$9fd34e80$(E-Mail Removed)...
>> Thanks very much TC.
>>
>> You make the point, "if the database has been secured
>> correctly, only the right workgroup file will let him
>> into the database". I felt that I had done everything
>> correctly and I haven't found anything, so far, in my
>> online searches to indicate otherwise. Could you offer
>> any guidance on where I might go for information on
>> securing the datatbase correctly so that only the right
>> workgroup file will let a user into the database?
>>
>> Jack Cannon
>
>While I would also encourage you to get the security FAQ
from MS and read it
>thoroughly (several times), your basic problem can be
defined this way...
>
>When a user opens Access with a workgroup file that does
not prompt them for a
>password then they MUST be logging in as the
user "Admin". If your database has
>granted any permissions to this user then this is a
security error that you should
>correct.
>
>The user "Admin" is also a member of the "Users" group
in ALL workgroup files (as is
>any other user). The group "Users" must therefore be
stripped of all permissions in
>your file.
>
>Owners of databases and the objects contained therein
are granted permissions by
>virtue of their owner status irrespective of any
permissions they have or don't have
>on their own or due to memberships in groups.
Therefore, the user "Admin" should not
>be the owner of your secured database or any of the
objects within it.
>
>If you verify these three things then you should at
least be to the point where the
>default System.mdw file cannot be used to open your
database. This does not
>guarantee that you have everything concerning security
set up correctly, but you will
>have achieved the minimum requirement for most
applications; that any old body
>double-clicking your file won't get in.
>
>
>.
>

Hi Jack

I just got back to the newsgroup. I think the others have answered your
questions comprehensively.

Cheers,
TC


"Jack Cannon" <(E-Mail Removed)> wrote in message
news:097501c3720e$9fd34e80$(E-Mail Removed)...
> Thanks very much TC.
>
> You make the point, "if the database has been secured
> correctly, only the right workgroup file will let him
> into the database". I felt that I had done everything
> correctly and I haven't found anything, so far, in my
> online searches to indicate otherwise. Could you offer
> any guidance on where I might go for information on
> securing the datatbase correctly so that only the right
> workgroup file will let a user into the database?
>
> Jack Cannon
>
>
>
>
> >-----Original Message-----
> >
> >It is not a "gaping hole". It demonstrates, with 100%
> confidence, that your
> >database is not secured correctly.
> >
> >There is no way to "tie" a particular database to a
> particular workgroup
> >file. Access selects which workgroup file to use (or is
> told that via a
> >shortcut) *before* it has actually opened any database.
> So the workgroup
> >file is a "per session" thing, not a "per database"
> thing.
> >
> >A user can use *any* workgroup file in an attempt to
> open a database. But if
> >the database has been secured correctly, only the right
> workgroup file will
> >let him into the database. No other workgroup file will
> let him into the
> >database. If some other workgroup file *does* let him
> into the database,
> >this demonstrates (with 100% confidence) that the
> database has not been
> >secured correctly.
> >
> >HTH,
> >TC
> >
> >
> >"Jack Cannon" <(E-Mail Removed)> wrote in message
> >news:069101c371db$7fe582b0$(E-Mail Removed)...
> >> I have an application with various groups and users
> which
> >> are assigned different security levels depending on the
> >> object of concern. It all appears to work properly.
> >> The link to secured.mdw is accomplished via the
> >> command line on a desktop icon.
> >> However if a user attempts to open the application file
> >> (mdb or mde) directly from Windows Explorer the
> >> secured.mdw file is bypassed and the application is
> >> opened with no restrictions placed on the user.
> >> Obviously this is a gaping hole. It would seem
> resonable
> >> that the application should have a mechanism that
> ensures
> >> a link to secured.mdw before the application can be
> >> opened. Does such a mechanism exist?
> >
> >
> >.
> >

Thanks Scott

Along with Rick's comments, this has been extremely
helpful. I have bookmarked the URLs that you
shared with me plus that of your own site.

It is really great to get information in the timely
and relevant manner that I received on this issue.

Jack Cannon



>-----Original Message-----
>To expand on what TC said, I would encourage you to
download and
>read-read-read the MS Access Security FAQs at
>http://support.microsoft.com/default.aspx
scid=/support/access/content/secfaq.asp .
>There are specific steps you must take in order to
properly secure your
>application, and it's obvious you missed some. Jack
McDonald also has a very
>good section on security at his web site:
>http://www.geocities.com/jacksonmacd...sSecurity.html
>
>--
>Scott McDaniel
>CS Computer Software
>Visual Basic - Access - SQL Server - ASP
>www.thedatabaseplace.net
>
>
>.
>