Securing divided database using workgroup (*.mdw) file

[Jarda Beran]

Hi, I need to secure database divided to back-end (data) and front-end (user
interface), using the same workgroup file (which I have to create yet). I
know, how to secure one database contained in one file, but don't know how to
secure divided database.
How to secure both back-end and front-end with one workgroup file? Is it
possible or not?
Thanks in advance for any suggestions

 

[Rick Brandt]

Hi, I need to secure database divided to back-end (data) and
front-end (user interface), using the same workgroup file (which I
have to create yet). I know, how to secure one database contained in
one file, but don't know how to secure divided database.
How to secure both back-end and front-end with one workgroup file? Is
it possible or not?
Thanks in advance for any suggestions

Every file you have opened to this point has been while using a single mdw
file (the default System.mdw). That should illustrate that any number of
files can be opened while using any particular mdw file.

If the mdw file being used requires you to log in (because it has a password
on the Admin user) then you will be required to log in any time you use that
mdw regardless of which file you might open.

A secure file is nothing more than one which expects *certain* login
credentials and typically NOT the user "Admin".

Any file you create while logged into a particular mdw file will be owned by
the user that you have logged in as. If you then remove all permissions to
"Admin" and the group "Users" in that MDB you now have a secured file (to
the extent that Access security can be called "secure"). Using that method
you can create as many secured files as you like that can be accessed with
that mdw file.

Rememebr that mdbs and mdws are not "linked" in any way. There is a
correlation only. A secured MDB expects certain user accounts and/or group
memberships to allow access to the file and the objects within. An mdw file
contains user accounts. Any mdw that happens to contain user accounts that
"satisfy" the mdb will let you into that file. It just so happens that with
an unsecured file ALL mdws satisfy that criteria and with a secured file
only certain mdw files do (usually exactly one).

 

[Jarda Beran]

Every file you have opened to this point has been while using a single mdw
file (the default System.mdw). That should illustrate that any number of
files can be opened while using any particular mdw file.

If the mdw file being used requires you to log in (because it has a password
on the Admin user) then you will be required to log in any time you use that
mdw regardless of which file you might open.

A secure file is nothing more than one which expects *certain* login
credentials and typically NOT the user "Admin".

Any file you create while logged into a particular mdw file will be owned by
the user that you have logged in as. If you then remove all permissions to
"Admin" and the group "Users" in that MDB you now have a secured file (to
the extent that Access security can be called "secure"). Using that method
you can create as many secured files as you like that can be accessed with
that mdw file.

Rememebr that mdbs and mdws are not "linked" in any way. There is a
correlation only. A secured MDB expects certain user accounts and/or group
memberships to allow access to the file and the objects within. An mdw file
contains user accounts. Any mdw that happens to contain user accounts that
"satisfy" the mdb will let you into that file. It just so happens that with
an unsecured file ALL mdws satisfy that criteria and with a secured file
only certain mdw files do (usually exactly one).

Rick,
thank you for your advice. I tried on example database, and worked fine for
me. It's just important to first assign full control on all objects to new
group for administrators on both back-end and front-end, and then remove all
permissions (including DB opening) for system created administrators and
users groups. Then if anybody tries to log-in using any other *.mdw file will
not have permission to open database.
Is it right?

 

[Keith Wilby]

Rick,
thank you for your advice. I tried on example database, and worked fine
for
me. It's just important to first assign full control on all objects to new
group for administrators on both back-end and front-end, and then remove
all
permissions (including DB opening) for system created administrators and
users groups. Then if anybody tries to log-in using any other *.mdw file
will
not have permission to open database.
Is it right?

PMFJI. I think that's right as far as it goes but your custom admin account
should also be the database *owner*. You achieve this by creating a new,
blank db file whilst logged onto your custom admin account and importing all
objects into it. Have a look at the FAQ, link on my web site.

Regards,
Keith.
www.keithwilby.com

 

[Jarda Beran]

PMFJI. I think that's right as far as it goes but your custom admin account
should also be the database *owner*. You achieve this by creating a new,
blank db file whilst logged onto your custom admin account and importing all
objects into it. Have a look at the FAQ, link on my web site.

Regards,
Keith.
www.keithwilby.com

Keith,
I've found a lot of interesting information on your website, thank you.
I have one more question - what about linked tables? Do I have to set up
permissions to the data tables for all users in the source (back-end)
database, or just in the front-end? And what if I need to relink the tables?

 

[Keith Wilby]

Keith,
I've found a lot of interesting information on your website, thank you.
I have one more question - what about linked tables? Do I have to set up
permissions to the data tables for all users in the source (back-end)
database, or just in the front-end? And what if I need to relink the
tables?

What I do is have no user permissions to tables at all and use RWOP (run
with owner's permissions) queries on them. That way, as long as the user
has permissions to the RWOP query, they will inherit those same permissions
on the table(s). Search the help for "WITH OWNERACCESS OPTION" for more
info.

Regards,
Keith.

 

[Jarda Beran]

What I do is have no user permissions to tables at all and use RWOP (run
with owner's permissions) queries on them. That way, as long as the user
has permissions to the RWOP query, they will inherit those same permissions
on the table(s). Search the help for "WITH OWNERACCESS OPTION" for more
info.

Regards,
Keith.

Keith,
I've heard about RWOP, but I'm not sure how to use it, when I have several
tables, related to each other, and each of them is data source for one nested
form. So I decided to set permissions both in back-end and front-end
databases.
Anyway - thank you for suggestion. Maybe, next time, I'll try RWOP.
Best Regards
Jaroslav