Replicas and User permissions

  • Thread starter Thread starter TC
  • Start date Start date
T

TC

I know nothing about replication, but I imagine that you would have to
distribute copies of the workgroup file that you used to secure the
database, and, have the users start the database with a shrtcut of the
following format (all on one line):

"path to MSACCESS.EXE"
"path to MDB"
/wkgrp "path to MDW"

Then, Access will use the correct workgroup file when you start the database
via that shortcut.

I can't imagine that replication would replicate changes to the >workgroup
file<. The user & group names (& user/group relationships) are stored in the
workgroup file - not the MDB file.

HTH,
TC
 
We are a club and our member database is used by
different officers for different things on their own
private computers.

I have set up users and group permissions, and I can
replicate the database successfully.

It all works perfectly on *my* computer.

However, when I run one of the replicas on a different
machine, it logs in automatically as Admin, as if I had
not set up different users.

How can I 'replicate' the User Permissions with the
database so that they can only access the parts of the
system I have set up for them?

Thanks...
 
You need to do several things
1. Create a new UNIQUE mdw file call it Club.MDW
This will need to be set up with a unique Name, Organisation and
PID
2. Set up all your groups and users again
2a. Remember to make one user an administrator
3. set a password for the user Admin
4. Remove ALL permissisions from the Admin User
5. Remove the Admin user form the ADmins group
6. Distribute your MDW file TOGETHER with your MDB
7 Set up a shortcut on each users computer along the lines of
"path to MSACCESS.EXE" "path to secured MDB" /wkgrp
"path to CLUB.MDW"
(Thanks TC)
8. Test your implementation

NB You may need to import all your objects into a new MDB owned by
your new AdministratorID to get all your permissions to take properly.
Your old MDB is almost certainly owned by Admin, and ownership takes
precedence over defined permissions.

This does not implement good security, but it will be a good start.
If you did Step 1 properly, you may be able to start at step 3

As has been commented on elsewhere, good (NOT perfect!)security does
not come easily in Access, but it is possible.

Regards Greg Kraushaar
Wentworth Falls Australia
(Do not email - the reply address is a Spam spoofer)
(If you really must, remove all UCase and numbers)
 
Thanks Greg/TC.

And there I was, thinking that MS must have made it easy
to do things like that!

Let me work through your ideas.

I had also been wondering how to get rid of Admin's
ownership of the database... I see that I must import it
into a new one owned by the new NewAdmin user.

Cheers for all that!

Neil
 
Hopefully, you are still reading....

You should only replicate tables. Split your database into frontend (all
objects except tables), and backend (tables/relationships only). The
frontend contains links to the backend. Ensure you apply security to both
mdbs. Replicate *only* the backend - it's not meant for replicating other
objects.

Download and study the security FAQ and ensure you follow every step. Since
your users can even open your database using the default system.mdw, you
haven't secured it properly.
The FAQ is available at
http://support.microsoft.com/?kbid=207793

You should also study up on replication
http://support.microsoft.com/?id=190766 - white paper
http://support.microsoft.com/?id=282977 - FAQ

Also see
www.trigeminal.com - excellent replication site
http://support.microsoft.com/support/access/content/repl/replication.asp

There is also a newsgroup devoted to replications
microsoft.public.access.replication
 
Ah, I think we had this conversation before! :-)

I disagee with calling Admin a "security hole". This implies that Admin can
be used to bypass security in a >properly secured< database file.

Naturally, if a user has no clue how to set up security properly, there will
be a gazillion holes in his setup. It will use the default workgroup file
(so anyone else can reproduce that file), the objects will be owned by
admin, the users group will have permissions, the startup props will not
have DDL set, & so on, ad infinitum. I don't see how the characteristics of
the Admin user make it any more relevant, there, that any of those other
errors. And they are >errors< - not "holes"!

Would you say, for example, that the Workgroup Information File is a "hole"
in Access security, because if it is not set up properly (with a unique
PID), an unauthorized user can re-create it & thereby gain administrative
rights to the whole database?

Cheers,
TC
(off for the day)
 
Actually, I did say it... ;-) If a developer does not understand how
the Admin user relates to the Jet security model, then it is a hole.
If s/he understands its workings and take steps to secure the database
correctly, then it is no longer a hole.
 
Still reading, Joan!

I've sorted out the 'default Admin' problem and created a
new Workgroup; exported all the objects to a new database
owned by the NewAdmin in the New Workgroup.

Now I'll spend some time on your recommended reading list!

Thanks...

Neil
-----Original Message-----
Hopefully, you are still reading....

You should only replicate tables. Split your database into frontend (all
objects except tables), and backend
Click to expand...
(tables/relationships only). The
 
Ah, I think we had this conversation before! :-)

I disagee with calling Admin a "security hole". This implies that Admin can
be used to bypass security in a >properly secured< database file.
Click to expand...

I don't think that it implies that at all. ("properly secured")
Naturally, if a user has no clue how to set up security properly, there will
be a gazillion holes in his setup. It will use the default workgroup file
(so anyone else can reproduce that file), the objects will be owned by
admin, the users group will have permissions, the startup props will not
have DDL set, & so on, ad infinitum. I don't see how the characteristics of
the Admin user make it any more relevant, there, that any of those other

errors. And they are >errors< - not "holes"!
Click to expand...

Agreed -- they are errors. But it seems to me that the characteristics
of the Admin user makes it very easy to commit errors -- thus leading
to holes. I guess it's just a matter of semantics.

Would you say, for example, that the Workgroup Information File is a "hole"
in Access security, because if it is not set up properly (with a unique
PID), an unauthorized user can re-create it & thereby gain administrative
rights to the whole database?
Click to expand...

More to the point, I would say that a database created when logged in
as the Admin user on the default Workgroup file (or any workgroup
file) would constitute a hole. And by the number of calls for help in
this newsgroup that are related to that kind of mis-understanding, I
would say that calling it a hole is not unjustified.

(IIRC, you pointed out to me a circumstance under which a database
created by an Admin user can be secured. I don't recall the details.)

But we both understand that Jet can be secured (within its
limitations) by using the proper techniques.

Cheers
 
Back
Top