would it be wise???

[tw]

Would it be wise to put in code upon start up, that if the CurrentUser() =
'Admin' then give user a message that they are using the wrong workgroup
file and need to change to a proper workgroup file, then quit the system?
If I were to do this, then I could possibly get locked out of my database if
the workgroup file got corrupt? Could there be a way around getting locked
out of the database if this code was implemented? If this code could be
implemented, where should it go, on the start up form, or is there a load
event to the database itself?

 

[Lynn Trapp]

The better approach is to implement user level security properly, as
described in the Security FAQ, so that a person will not be able to log on
as Admin without knowing Admin's password.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html

 

[Jeff Conrad]

Just to add to Lynn's response, if a user *does* happen to
log in as Admin with the correct password then they would
simply get a "You do not have permissions..." message and
would not be able to access any parts of the database.

This assumes you have removed ALL permissions from the
Users group and the Admin user.

 

[tw]

if passwords are stored in the workgroup file, then the system workgroup
file has no admin password. If the user logs in using the system workgroup
file, the system will not ask for a password. Is this understanding
incorrect?

 

[tw]

There are some permissions that are necessary by all users, that I included
in the users group. Other than that, the Admin user has no other
permissions. The Admin user is only a member of the users group. Some
permissions I allowed to the users group, because they are necessary for all
users. If the user logs in with username and password from the correct
workgroup, everything is fine. If the user logs in using the system.mdw,
then they can log in without a password. I have a function that checks to
see what groups the user is a member of to determine which options show on
the main form. The problem with this is that if the user logs in with the
system.mdw an error is generated in the function because the group does not
exist. I'm just trying to figure out how to do the error handling in this
situation.

 

[Lynn Trapp]

That's correct, but if you have followed the required steps correctly, a
person attempting to log in via the default system.mdw file will not be able
to get in.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html

 

[Jeff Conrad]

Maybe this explanation will help you understand the process.

Every time you open an Access database (without a shortcut
to give Access different instructions) Access will *attempt*
to log in as Admin user with no password. *If* that attempt
fails for any reason, then and *only* then will you be prompted
for a password.

Does that help?

--
Jeff Conrad
Access Junkie
Bend, Oregon

in message:

 

[tw]

What step did I miss then. I thought I followed the steps... (with the
exception of setting up some permissions for the user group). Could that be
why the admin user from the system.mdw can get in? I did give the user
group permission to open/run the database, limit the number of modifications
necessary if new groups are added. I guess I will move that permission
elsewhere to prevent the admin user from getting in with the system
workgroup file.

 

[Rick Brandt]

What step did I miss then. I thought I followed the steps... (with
the exception of setting up some permissions for the user group).
Could that be why the admin user from the system.mdw can get in? I
did give the user group permission to open/run the database, limit
the number of modifications necessary if new groups are added. I
guess I will move that permission elsewhere to prevent the admin user
from getting in with the system workgroup file.

Yep. If you want to force the use of a certain MDW then the Users group and
Admin user must have ZERO permissions.

There are people who will give the Users group a base-set of permissions but
that strategy is used when you specifically DON'T want to make them use a
specific MDW file.

 

[Lynn Trapp]

The Users group should not have any permissions to any object in the
database.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html

 

[tw]

Thanks all

The Users group should not have any permissions to any object in the
database.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html

 

[Jeff Conrad]

Well it depends.

From your earlier post you said you had granted the Users group some permissions.

...."Some permissions I allowed to the users group, because they are necessary for all
users."...

Well there are situations where this is OK, so I will not say that you *never* want
to do this, but it is very unusual.

*Normally* when you secure an Access database you give zero permissions to the
Admin User and the Users group. This includes zero permissions on the Database
itself (a step usually missed). By doing it this way, no one will "accidentally" log into
the database with the wrong workgroup file, ever.

So let's get back to your initial comment of needing to have some permissions for all
the users. What you *should* do is create one or more custom groups for your
workgroup file. You assign membership to those various groups for your users. Now
as an example, say you need everyone who uses the database to open "FormA." In
the Permissions dialog area you simply grant permissions for your *custom groups*
to use "FormA." That way everyone can use that form. Follow me?

By giving any permissions (however small) to the Admin User or the Users Group,
you open a security hole into your database.

One last comment. You thought about having some code to kick out the Admin User.
I think you can do this by setting up some quick code in a module and then calling it
through an AutoExec macro. You would have to grant the Admin User permission
to open the database and run the macro. However, I really, really, really, really, really
do not recommend this approach.

--
Jeff Conrad
Access Junkie
Bend, Oregon

in message:

 

[tw]

I solved the issue by removing permission to the database in the user group.
I am leaving some of the user permissions that are required for every user.
I.E. the main entry form, and other forms that all users need. They do not
have permission to any sensitive data. I created a group for all users who
will need access to open/run the database, and I put everyone in that group
except the admin user. That accomplished what I wanted. Thanks for all the
input.

 

[Jeff Conrad]

"tw" wrote in message:

I solved the issue by removing permission to the database in the user group.
Good.

I am leaving some of the user permissions that are required for every user.
I.E. the main entry form, and other forms that all users need. They do not
have permission to any sensitive data.

Ok, should be fine.

I created a group for all users who will need access to open/run the database,
and I put everyone in that group except the admin user. That accomplished
what I wanted. Thanks for all the input.

Excellent, very good.

You're welcome for the help.
One step at a time and you'll be fine.