New to security have questions before plunging

[Guest]

Ok I am very new to setting up security so please bear with me. I have read
several comments here and need some questions answered. I have developed a
FE BE program, which will be sent to several places. Because of the security
issues at each individual place they may place the FE BE differently so I
can't come up with just one idea and expect each to play along if you know
what I mean. My suggest is to place the FE on each user's PC and the BE
inside a folder on a server. Now for my questions.

1. When I create a MDW is there ever a possiblity when they open this then
open a different program with a different MDW that it could affect the second
one? The reason I ask some of the places have very sensitive DBs and I don't
want this program to intefere with theirs.

2. I believe what I read was to create a new MDW from scratch and assign the
permissions, then have them place that in the same folder as the BE. Is this
correct?

3. Will this prevent others from gaining access to the tables who don't
have permission, including importing them into another DB?

4. Since I will be making revisons to the DB and will sending out a FE
later on, could this intefere since the user will have different permissions
than the Admin?

5. Should I make 2 or 3 groups and each group have a separated password? I
can't add each individual person, since we don't know who they will be. For
instance the Admin will have complete permissions. One password for the
daily routine of the user. Should I provide a third one so when they get new
revisions, it could modify or create tables, etc?


Just curious on how all this will take place before I dive in. Any
comments on the above would be helpful.

 

[TC]

Hmm, to answer all those questions in detail would probably take a day
or two!

I've jotted down some things that might help. But these are in no way a
comprehensive detailed answer.

TC

Ok I am very new to setting up security so please bear with me. I have read
several comments here and need some questions answered. I have developed a
FE BE program, which will be sent to several places. Because of the security
issues at each individual place they may place the FE BE differently so I
can't come up with just one idea and expect each to play along if you know
what I mean.

I assume you mean that each user might put the FE and BE in different
folders compared to you & each-other? If so, the FE must contain code
to automatically locate the BE (on that PC) and re-link the FE tables
to it. You can certainly do that, but it is easier to say they must go
in a fixed location. For example, "You must put the FE and BE files in
a folder called C:\My Programs\Blah Application", or whatever.

My suggest is to place the FE on each user's PC and the BE
inside a folder on a server.

That is correct.

1. When I create a MDW is there ever a possiblity when they open this then
open a different program with a different MDW that it could affect the second
one? The reason I ask some of the places have very sensitive DBs and I don't
want this program to intefere with theirs.

You'll be fine as long as you do NOT change any existing workgroup file
on their PC. Create a new workgroup file for your application. On each
user PC, start your application via a shortcut which uses the /wrkgrp
switch to give the path to your workgroup file. Google this nesgroup
for wrkgrp switch or similar for more information on this.

2. I believe what I read was to create a new MDW from scratch and assign the
permissions, then have them place that in the same folder as the BE. Is this
correct?

The issue is whether you put your workgroup file on the server (so
there is only one of them), or give each user one. The latter approach
gives each user quicker access to the workgroup file, but now you have
a problem in keeping all those files in synch. Others will doubtless
comment more on this choice.

3. Will this prevent others from gaining access to the tables who don't
have permission, including importing them into another DB?

The whole point of Access security is to control who gets access to
what resources. So the answer is yes, as long as you do it properly -
which is easier said than done!

4. Since I will be making revisons to the DB and will sending out a FE
later on, could this intefere since the user will have different permissions
than the Admin?

Well, you had a good question there, until the last few words! I see
roughl;y what you're getting at, buty I encourage you to rephrase the
question more precisely. Don't use terms like "the Admin". Only use
properly defined terms such as, "the Admin User" - this is a special,
pre-defined user in Access; "the Admins Group" - a special, pre-defined
group - note the 's'!; "a user with Administrative priviliges"; "a user
who is a member of the Admins Group", & so on. "The Admin" is a fatally
confusing term that will lead you down the paths of darkness!

5. Should I make 2 or 3 groups and each group have a separated

password?

Passwords identify users, not groups. Users belong to one or more
groups. Each user inherits the permissions of all the groups to which
he belongs. So, you might have one group called "Administrators",
another called "General Users", and so on. Fred might be a member of
both groups, but Dick might only be a member of the "Power Users"
group. Fred & Dick each have their own passwords, but their permissions
are not defined by their passwords - they are defined by the groups to
which they belong. I think you need to do more reading on Users &
Groups. And note that those are technical terms with specific,
well-defined meanings in Access.

I can't add each individual person, since we don't know who they will

be.

You need to decide whether an authorized user (at each site) should
have the ability to add new users for that site. If so, you have to
account for that in your coding and/or when establishing the security.

For instance the Admin will have complete permissions. One password for the
daily routine of the user. Should I provide a third one so when they get new
revisions, it could modify or create tables, etc?

I don't understand your question.

Just curious on how all this will take place before I dive in. Any
comments on the above would be helpful.

I suggest that you DO NOT expect to get it going by next Thursday!
Create a simple database just a few tables & forms. Use that database
as a tesbed, to see if you can get the whole thing working properly.
Then repeat the (tested) process on a copy of your actual database.
Expect this process to take *at least* a few weeks, if not more.

HTH,
TC

 

[TC]

TC wrote:

(snip)

this and
I don't

You'll be fine as long as you do NOT change any existing workgroup file
on their PC ...

.... AND you do NOT ask them to use the Workgroup Administrator to
"join" your workgroup. Use a shortcut with the /wrkgrp switch instead
(as mentioned already).

HTH,
TC

 

[Keith]

1. When I create a MDW is there ever a possiblity when they open this then
open a different program with a different MDW that it could affect the
second
one? The reason I ask some of the places have very sensitive DBs and I
don't
want this program to intefere with theirs.

Leave the default system.mdw on the users' PCs untouched. Supply your own
custom mdw and invoke it at runtime using the command line "wrkgrp" switch.

2. I believe what I read was to create a new MDW from scratch and assign
the
permissions, then have them place that in the same folder as the BE. Is
this
correct?
Yes


3. Will this prevent others from gaining access to the tables who don't
have permission, including importing them into another DB?

If done properly, yes. I should mention at this point that achieving this
may take some time.

4. Since I will be making revisons to the DB and will sending out a FE
later on, could this intefere since the user will have different
permissions
than the Admin?

As long as you replace the FE and the mdw with each revision than I can't
see a problem.

5. Should I make 2 or 3 groups and each group have a separated password?
I
can't add each individual person, since we don't know who they will be.
For
instance the Admin will have complete permissions. One password for the
daily routine of the user. Should I provide a third one so when they get
new
revisions, it could modify or create tables, etc?

I always create generic users, for example, user "guest" is a member of
group "guests" and has read-only access. User "clerical" is a member of
group "clericals" and has full access to certain areas and read-only access
to others. So all guests and all clerical users will log on using their
respective generic user name. You can always harvest the network logon IDs
using code to track who's logged on and to track their movements if that's
your bag.

HTH - Keith.
www.keithwilby.com

 

[TC]

Keith wrote:

(snip)

I always create generic users, for example, user "guest" is a member of
group "guests" and has read-only access. User "clerical" is a member of
group "clericals" and has full access to certain areas and read-only access
to others. So all guests and all clerical users will log on using their
respective generic user name.

Why?

With that method, an individual who needs to be a member of several
groups, will need to know the password of each of those groups. And if
you wanted to remove him from one of those groups, you'd have to change
the password of the relevant generic user, then tell all the remaining
users of that group, what the password had been changed to!

With the proper method (a username per individual), each individual
only has *one* password, and you can easily manage which groups he
belongs to, without changing *any* passwords.

The generic *groups* are fine, but I can't see any justification for
generic *users*.

Yes? No?

Cheers,
TC
(off for the day, unfortunately)

 

[Keith]

Keith wrote:

(snip)



Why?

With the proper method (a username per individual), each individual
only has *one* password, and you can easily manage which groups he
belongs to, without changing *any* passwords.

The generic *groups* are fine, but I can't see any justification for
generic *users*.

Yes? No?

Define 'proper'. In my line of business, with literally hundereds of
potential users and people joining and leaving the company/project all the
time it would be an unmanagable overhead to give all users their own
account. There's nothing to stop a generic user from belonging to more than
one group.

Enjoy your day off, only 90 minutes to go for me

Regards,
Keith.

 

[Guest]

Thanks for the responses and yes I should have used the correct terminology
when asking the questions. One of the things I was thinking of was create a
table called something like tblDBPassword which would have maybe 2 -3 rows.
If the user logs in using one of these passwords give them these rights.
Because I can't really count on each place to understand on how to administer
the rights I would like just a generic password for the USer group. One of
the comments stated that I need to create a new MDW for each revision, could
you explain why? Is it because on the new revision that you might have new
tables, queries, etc and the User Group won't have permission for these?
Also, I believe I read here to place the MDW with the FE, am I mistaken I
thought it should be where the BE is located on the server? I am really
trying to get a true understanding before plunging since this is very
sensitive. I really appreciate everyone and all comments. Thanks

 

[Keith]

One of the things I was thinking of was create a
table called something like tblDBPassword which would have maybe 2 -3 rows.
If the user logs in using one of these passwords give them these rights.

The built-in user-level security does just this, you don't need to "roll
your own" table.

One of
the comments stated that I need to create a new MDW for each revision, could
you explain why? Is it because on the new revision that you might have new
tables, queries, etc and the User Group won't have permission for these?

Got it in one.

Also, I believe I read here to place the MDW with the FE, am I mistaken I
thought it should be where the BE is located on the server? I am really
trying to get a true understanding before plunging since this is very
sensitive. I really appreciate everyone and all comments. Thanks

It's more convenient with the BE because then you only need deploy the
one mdw which all users reference. Because the FE will be on each
user's PC, to have the mdw with it causes an obvious management overhead
(although there may be a minor performance improvement).

Regards,
Keith.
www.keithwilby.com

 

[Guest]

Thanks Keith,
One more thing, when I send out revisions later on what is the best of doing
this with security? In other words say I have to add a table or add a field
or somthing to the back end. When they intially copy over the FE and open it
the first time it should give them permission to have these capabilities, but
then take them away afterwards. Or if they run into problems when they do
this have them start from scratch again and copy the FE over. However, later

 

[TC]

Define 'proper'. In my line of business, with literally hundereds of

 

[TC]

Keith wrote:

(snip)

Define 'proper'. In my line of business, with literally hundereds of

potential users and people joining and leaving the company/project all the
time it would be an unmanagable overhead to give all users their own
account. There's nothing to stop a generic user from belonging to more than
one group.
Understood.


Enjoy your day off, only 90 minutes to go for me

Then stop fskin' around on the net and get back to work !!

Cheers,
TC

 

[TC]

Sorry Keith, google seems to have mangled my reply completely.

I just acknowledged your explanation of why you use generic users. And
in reply to your comment:

Enjoy your day off, only 90 minutes to go for me

I said: "Then stop fskin' around on the web and get back to work !!"

Cheers,
TC

 

[TC]

Keith, this is my THIRD attempt to say that google mashed-up my reply
to your reply. It is not what I said. I give up - just ignore it!

Cheers,
TC

 

[TC]

Sorry Keith, google has now mangled my reply to you, twice. The
previous post is not what I sent. Hope this one makes it thrugh
correctly. I just acknowledged your explanation of why you use generic
users.

Cheers,
TC

 

[Keith]

<Top Cat/Brain>
D'uh, OK TC.
</Top Cat/Brain>

 

[Joan Wild]

Got it in one.

That is not true Keith. There is no reason to create a new MDW for each
revision; infact it's undesireable (when to deploy it, you'll wipe out the
users' passwords.)

Remember that the permissions are stored in the mdb not the mdw. The only
reason to deploy a modified mdw (note you wouldn't create a new one) would
be if you added new groups or users.

 

[Keith]

There is no reason to create a new MDW for each
revision; infact it's undesireable (when to deploy it, you'll wipe out the
users' passwords.)

Remember that the permissions are stored in the mdb not the mdw. The only
reason to deploy a modified mdw (note you wouldn't create a new one) would
be if you added new groups or users.

Thanks for that correction Joan, I did indeed think that permissions
were stored in the mdw - I take it that they're stored in the normally
hidden system tables?

Why would the passwords be wiped out? I must admit, in my line of work
it is easier to choose a password for my generic users and only change
them myself if I think that security has been compromised, denying
access to change passwords to the actual users.

Regards,
Keith.

 

[Guest]

Joan, could you explain how I would go about doing what I requested in the
previous note? Thanks

 

[Joan Wild]

Thanks for that correction Joan, I did indeed think that permissions were
stored in the mdw - I take it that they're stored in the normally hidden
system tables?

I'm not sure where they are stored, but definitely in the mdb file (which is
why you can use more than one mdw with a single mdb file).

Why would the passwords be wiped out? I must admit, in my line of work it
is easier to choose a password for my generic users and only change them
myself if I think that security has been compromised, denying access to
change passwords to the actual users.

Passwords are stored in the mdw file. If users have changed their password,
and you copy over a new mdw, their password is wiped out (granted it doesn't
sound as though this would be an issue for you, in your setup, in most cases
it would be an issue)

 

[Joan Wild]

Thanks Keith,
One more thing, when I send out revisions later on what is the best of
doing
this with security? In other words say I have to add a table or add a
field
or somthing to the back end.

It should be rare that you would need to add a table/field to the backend,
if you've done a good job at scoping the business needs. Depending on the
circumstances, you could have them send you the backend, you modify it and
return it.

If you want them to be able to do it, you could create a separate mdb to run
once to make the modifications.
http://www.granite.ab.ca/access/backendupdate.htm