Security without signon

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I would like to rollout a basic application (1 form, 2 tables) to many users,
but I don't want the users to have to logon to the database with an ID and
Password. However, I want to ensure they are only able to enter data in the
form and nothing else. Of course, I would liike the administrator to have
full access. What is the best way to do this? Thanks
 
BPH said:
I would like to rollout a basic application (1 form, 2 tables) to
many users, but I don't want the users to have to logon to the
database with an ID and Password. However, I want to ensure they are
only able to enter data in the form and nothing else. Of course, I
would liike the administrator to have full access. What is the best
way to do this? Thanks
Click to expand...

Normally when applying Access User Level Security a primary requirement is
to remove all permissions and ownership from the group "Users" and the user
"Admin". That is what forces users to use your mdw file and a login.

You can however, give limited permissions to the Users group. Then any user
(using any mdw file) can open your file, but they are still limited to the
permissions that you granted to the Users group. There is no need in this
setup to distribute an mdw file. Anyone who needs to log in with higher
permissions though still needs to use your mdw file so they can log in as a
user with higher authority.
 
Thank you Rick, That works except that when trying to limit users from being
able to link to the tables in my database, the users are not restricted. I
have not split my database (FE/BE) and at this point would prefer not to. I
have set up the form to run off a RWOP query, and I have removed all access
to the tables from the Users Group. I have put the database on a network
drive and have not put the security.mdw file with it, thus users are not
prompted for a password. I would expect that any user linking to the
database from another database would be stopped by not having sufficient
rights inherited from the Users group (I have removed the Admin user from the
Admins group). But users are able to link to the table with full rights.
Any thoughts???
 
BPH said:
Thank you Rick, That works except that when trying to limit users
from being able to link to the tables in my database, the users are
not restricted. I have not split my database (FE/BE) and at this
point would prefer not to. I have set up the form to run off a RWOP
query, and I have removed all access to the tables from the Users
Group. I have put the database on a network drive and have not put
the security.mdw file with it, thus users are not prompted for a
password. I would expect that any user linking to the database from
another database would be stopped by not having sufficient rights
inherited from the Users group (I have removed the Admin user from
the Admins group). But users are able to link to the table with full
rights. Any thoughts???
Click to expand...

Does the default user "Admin" own the database ir any of the objects within?
Owners have rights above and beyond those that are explicitly granted to
them.
 
OK, I have changed the owner of the database and the tables to a user (my
user id). As an added precaution, I created a new (non-default) admin group
called SBAdmin and assigned full rights to the tables to this group and
removed all table rights from the default Admins group.

However, users are still able to link to the tables with full rights.
Further, if they open the database (I temporarily allowed Shiftkeybypass for
testing purposes) they have full rights to the tables as well. The user is
using their default security.mdw file but seems to gain access to the tables
via the Admins group (all rights are checked for this group, but not checked
for the user Admin or for the group Users), despite the fact that I have
explicitly removed table access from the Admins group. Is there something I
have to do to ensure my access changes take effect?

Thanks for your continued help.
 
I think that your requirements are mutually exclusive. AFAIK, the
owner of the RWOP query must exist *in* the workgroup file that is in
effect during the Access session. In other words, the users must log
onto a special workgroup file that contains the query owner. But your
main requirement is that they *not* be required to logon. I don't see
how those two requirements can co-exist.

But I may be wrong... If so, I am sure somebody will correct me.

WRT their ability to link to the tables -- if they have read
permissions on the tables, they *will* be able to link to them. Can't
have it both ways...

Split or no split is irrelevant for the security. However, split is
highly recommended.

Thank you Rick, That works except that when trying to limit users from being
able to link to the tables in my database, the users are not restricted. I
have not split my database (FE/BE) and at this point would prefer not to. I
have set up the form to run off a RWOP query, and I have removed all access
to the tables from the Users Group. I have put the database on a network
drive and have not put the security.mdw file with it, thus users are not
prompted for a password. I would expect that any user linking to the
database from another database would be stopped by not having sufficient
rights inherited from the Users group (I have removed the Admin user from the
Admins group). But users are able to link to the table with full rights.
Any thoughts???
Click to expand...

**********************
(e-mail address removed)
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security
 
jacksonmacd said:
AFAIK, the
owner of the RWOP query must exist *in* the workgroup file that is in
effect during the Access session.
True.

In other words, the users must log
onto a special workgroup file that contains the query owner.
Click to expand...

That doesn't follow imho. He only has to log on if the Admin user has a
password (as you know). If he used a shortcut with the /wrkgrp switch,
but the Admin user of that workgroup file did not have a password, he'd
be seeing the right user(s), but he would not have to log on.

HTH,
TC
 
That doesn't follow imho. He only has to log on if the Admin user has a
password (as you know). If he used a shortcut with the /wrkgrp switch,
but the Admin user of that workgroup file did not have a password, he'd
be seeing the right user(s), but he would not have to log on.
Click to expand...


You are correct.

Whether or not this is applicable to the OP depends on whether he is
prepared to distribute the workgroup file plus shortcut. I was
assuming that he wanted to use any arbitrary workgroup file without
employing a shortcut. He would also be stymied if he wanted
double-click access to the MDB file.
HTH,
TC
Click to expand...

**********************
(e-mail address removed)
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security
 
So if I understand both of you correctly, despite the fact that I have set up
a RWOP query, the fact that the user was not using the Security.mdw file
where I established secuirty makes the RWOP setting mute as the user was not
using this, rather the form worked because they had underlying access to the
table. I understand this, and it seems then that my requirements conflict.

However, I still don't understand why my security settings for the tables
haven't taken effect for users logging onto the DB without access to my
security.mdw file. Remember, I removed all access to the tables from
everyone but members of SBAdmins group, but users can link to the table.
Coincidentally, when I try to test the access by changing the name of the
security.mdw so I effectively simulate a user, then I am restricted from
linking the tables and it seems to work as I would like it (I use a default
security.mdw file and am on as admin, not the owner - this is strange and
frustrating).

Even though once I understand this, it seems my design is still flawed
because of the points above.

Thanks
 
jacksonmacd said:
I think that your requirements are mutually exclusive. AFAIK, the
owner of the RWOP query must exist *in* the workgroup file that is in
effect during the Access session. In other words, the users must log
onto a special workgroup file that contains the query owner.
Click to expand...

That is not true. The production workgroup file does not need to have the
owner in it for a RWOP query to work.
 
I am thinking that you didn't create a new workgroup file to secure it with.
That is still a requirement.

Create a new workgroup file; secure it, but grant limited permissions to the
Users Group. Distribute the mdb without your workgroup file.
 
Joan, that is good news for me, but then takes me back to my original
question. Do you know why the security I have applied to the tables in my
database does not seem to restrict users from linking to the table when they
access the database via their default security.mdw?
 
Sorry... I don't know. I went thru the same steps and *was* denied the
ability to link to the tables when logged on as an unpriviledged user.


So if I understand both of you correctly, despite the fact that I have set up
a RWOP query, the fact that the user was not using the Security.mdw file
where I established secuirty makes the RWOP setting mute as the user was not
using this, rather the form worked because they had underlying access to the
table. I understand this, and it seems then that my requirements conflict.

However, I still don't understand why my security settings for the tables
haven't taken effect for users logging onto the DB without access to my
security.mdw file. Remember, I removed all access to the tables from
everyone but members of SBAdmins group, but users can link to the table.
Coincidentally, when I try to test the access by changing the name of the
security.mdw so I effectively simulate a user, then I am restricted from
linking the tables and it seems to work as I would like it (I use a default
security.mdw file and am on as admin, not the owner - this is strange and
frustrating).

Even though once I understand this, it seems my design is still flawed
because of the points above.

Thanks
Click to expand...

**********************
(e-mail address removed)
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security
 
Joan said:
That is not true. The production workgroup file does not need to have the
owner in it for a RWOP query to work.
Click to expand...


Um, are you sure? An RWOP query is executed with the permissions of the
user who owns the query. If that user does not exist in the current
workgroup file, those permisions will be "nil", AFAIK.

If you can contradict this, I'd be interested in a small example db &
mdw (preferably in A97 format) that I could take a look at with my
various tools.

Cheers,
TC
 
Um, are you sure? An RWOP query is executed with the permissions of the
user who owns the query. If that user does not exist in the current
workgroup file, those permisions will be "nil", AFAIK.
Click to expand...

Well TC, I am no MVP, but I can tell you what I am seeing. When the
database is distributed without the security file, and a user opens the
database, they gain full access to the "restricted" tables via the ADMINS
group. Therefore, their permissions are not "nil" but rather FULL. Perhaps
this is due to the fact that when I check the owner of all the objects as a
user logged in with their default security.mdw file, the owner appears as
"<unknown>"? Thus the tables are not secure despite the fact that I have
secured them. At this point the RWOP is not the problem. Still looking for
ideas on how to ensure the tables are secure. Thanks.
 
TC said:
Um, are you sure? An RWOP query is executed with the permissions of
the user who owns the query. If that user does not exist in the
current workgroup file, those permisions will be "nil", AFAIK.
Click to expand...

I'm positive. I never ship the workgroup file that was used to secure a
database; always a production mdw. The development mdw contains the user
that is owner, the production does not.
 
Sorry, I really can't comment on your setup without following through
it all, detail. I just picked up on the comments regarding RWOP queries
& the owners thereof. I'm sure the others will help you get it sorted
:-)

TC
 
Back
Top