Where Is Security Configuration Stored?

Can anyone tell me where are the security settings stored in a situation
where I have a front-end and a back-end for the following:

1. User/Group Accounts: Stored in system file, FE or BE?
2. User/Group Permissions: Stored in system file, FE or BE?

Thanks.
ck

CK wrote:
Can anyone tell me where are the security settings stored in a
situation where I have a front-end and a back-end for the following:

1. User/Group Accounts: Stored in system file, FE or BE?
2. User/Group Permissions: Stored in system file, FE or BE?

Thanks.
ck

User info, group info, and membership info is stored in the MDW. Permissions
for objects in the front end are stored in the front end. Permissions for
objects in the back end are stored in the back end.

Makes sense doesn't it?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Thanks, Rick. Whenever I copied a frontend to bring it home to work, made
some changes to the permissions, and then copied it back to the office, the
permissions go haywire so I'm wondering if I should also copy the mdw as well
whenever I need to make changes to permissions.
ck

"Rick Brandt" wrote:

CK wrote:
Can anyone tell me where are the security settings stored in a
situation where I have a front-end and a back-end for the following:

1. User/Group Accounts: Stored in system file, FE or BE?
2. User/Group Permissions: Stored in system file, FE or BE?

Thanks.
ck

User info, group info, and membership info is stored in the MDW. Permissions
for objects in the front end are stored in the front end. Permissions for
objects in the back end are stored in the back end.

Makes sense doesn't it?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

If you're able to work with the frontend at home without the mdw file, then
security probably hasn't been properly applied.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)



"CK" wrote in message
...
Thanks, Rick. Whenever I copied a frontend to bring it home to work, made
some changes to the permissions, and then copied it back to the office,
the
permissions go haywire so I'm wondering if I should also copy the mdw as
well
whenever I need to make changes to permissions.
ck

"Rick Brandt" wrote:

CK wrote:
Can anyone tell me where are the security settings stored in a
situation where I have a front-end and a back-end for the following:

1. User/Group Accounts: Stored in system file, FE or BE?
2. User/Group Permissions: Stored in system file, FE or BE?

Thanks.
ck

User info, group info, and membership info is stored in the MDW.
Permissions
for objects in the front end are stored in the front end. Permissions
for
objects in the back end are stored in the back end.

Makes sense doesn't it?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

"CK" wrote in message
...

Thanks, Rick. Whenever I copied a frontend to bring it home to work, made
some changes to the permissions, and then copied it back to the office,
the
permissions go haywire so I'm wondering if I should also copy the mdw as
well
whenever I need to make changes to permissions.

Well, you would have at least needed a copy of the workgroup file. If you
can move the mdb file to different machine, and open it with a different mdw
file, then your security has been setup wrong (what kind of security would
that be?). So, you can ONLY open the mdb file with the original workgroup
file used to secure it. (or a new workgroup file created with the same
passwords used).

Assuming, thus that you likely do have a copy of the workgroup file at home,
then, yes..you can make security changes, and take them back to work.

However, keep in mind two things:

You should NEVER NEVER set security for a form, report, query etc to a
actual INDIVIDUAL!!! The INSTANT you do this, you have now in fact put
security for users in the mdb file. You have a choice he

when you set security/permissions for a form, report etc, ALWAYS set
those
permissions to a SECURITY GROUP not a USER!!!! By doing this, means you
can work on a copy of the front end, and also take home a copy of the
security workgroup file. During the week, I sure that new users are being
added to the system. Further, I sure over time, some users will be given
permissions to use a particular form etc. However, since we ALWAYS assign
users to security groups, then in fact we NEVER assign a user to a form,
but only security groups.

This means that as you add new forms, or reports in your application, you
simply assign that report, or form to a EXISTING security group (say, the
sales group, or perhaps the manager group, or the 'read only' group). This
way, you can re-deploy a new front end to the company on site, but develop
off site. All of the many complex changes and assigning of users to security
groups will thus continue to work, and yet you don't care, or even need
their security workgroup file.

The instant you break the above rule, and start assigning forms to actual
users, then in fact that security is CONTAINED IN THE MDB file!!! So, don't
do
that!!

At the end of the day, most applications I have written can be broken down
in to maybe 3, or 5 major security groups. There is some great screen shots,
and an example of the security groups I used he

http://www.members.shaw.ca/AlbertKal...erFriendly.htm

So, the major trick to making this work is to sit down, and build 3 or 5
security groups. Then as you develop the application, you ALWAYS assign
forms
and reports to those security groups. It is only your clients that will
assign users to those actual security groups, but those settings are
contained in the workgroup file. So, you have 100% complete freedom to
email, or simply update your users front end.

The instant you allow your client to add new security groups, or allow them
to assign users to a particular form, then any update you send to them will
LOOSE those settings.

So, as a developer, make the security groups for the client, and as you
develop, assign forms, reports etc. to those security groups.

And, like I did, you might want to spend part of a afternoon, and make a few
nice security manager screens that makes this stuff VERY easy for your
clients...


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

Thanks Albert for the invaluable tips. As it happened, I had the original mdw
file which I first created with some users and groups in my home computer but
over time, the original mdw file in my home and the one in the office is no
more the same because of changes done to the one in the office. For example
when I added a new user, it was not reflected in my home computer. This is a
good reminder for me to also copy the mdw file whenever I need to bring the
frontend home to work, just in case.

One of the reasons I wanted to clarify this was that I noticed that the mdw
file doesn't seem to change in file size at all despite all the changes which
led me to suspect that maybe the configuration is stored somewhere else.
ck

Thanks. See my reply to Albert.
ck

For example
when I added a new user, it was not reflected in my home computer. This is a
good reminder for me to also copy the mdw file whenever I need to bring the
front-end home to work, just in case.

Yes, as mentioned, you can do the above. however, you need a
fresh copy of the workgroup file, as long as you following the
rules outlined in my previous post.

If take the approach I mentioned, then, you don't care if
changes occur "on site" to the workgroup file. They can add, delete
users and set permissions for users to groups, and you are STILL
FREE to send them new updates, and NOTHING will go wrong.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal