Network ID and Access security

[Ogedei]

I think I know the answer but I want to ask the question.

Is there a way to use an mdw but not have the login prompt?

We need the security of the MDW and such but we want to use their network login as validation of who they are. One less password for everyone to manage.

Thanks in advance for your consideration

 

[Len Boorman]

I use an alternative method. Not actually Access security or using the mdw file but an alternative if you are only looking to keep out the curious and those with limited knowledge of Access

I detect the Network login and compare this to the contents of a table. If the Login ID is in the table I then open the Opening Form. If the login is not in the table I close the application.

Thus only those that I allow by having their login ID in the control table end up with the application opening.

You do need to also disable the by pass key and control startup properties as well. I also use custom menu bar.

It is not totally bomb proof by any means. You could simply import all the objects into a new database, but it is inclined to keep out the curious and those without sufficient knowledge to do twiddly things

Let me know if its of interest and I can give you some more info

Len B

 

[ghudson]

Is there a way to use an mdw but not have the login prompt?

We need the security of the MDW and such but we want to use their network login as validation of who they are. One less password for everyone to manage.

Yes you can if you are willing to have your users open the secured db with a unique shortcut.

I do this for a few apps if I want it to be secured but I do not want the user to have to manualy log into the application. I create a unique shortcut that I send to each user. I use a self extracting program to install the shortcut where I want it off of the users Start button. The target field in the shortcut looks like this [all in one line]...

"C:\Program Files\Microsoft Office\Office11\MSACCESS.EXE" /wrkgrp "\\Server\Partition\Directory\WorkgroupFile.mdw" "\\Server\Partition\Directory\DatabaseFile.mdb" /user UserName /pwd Password

It is okay if the user discovers the values in the target field since they would be logging into the program anyway. I also store the users login info in a table so that I can track who is logging into the app and when.

You could incorporate an extra step to verify the users network login name into your db to verify that the user is who you expect them to be. The Environ() function will allow you to extract that info. Here is quick example...

Msgbox Environ("UserName")
MsgBox Environ("ComputerName")

You could compare that info with the values in a table to ensure that the user is who you expect and that they are logging in from their own PC.

I trust that your db is split and that each user has a copy of the front end installed to their hard drive and that each front end is linked to one backend on the server. The shortcut, front end and the Workgroup.mdw file should all be on the users hard drive and you will have to update those files anytime you modify the database [front end or back end]. The shortcut, front end and the Workgroup.mdw files should not be shared.

 

[Bosch]

ghudson...

I am not sure how old this post is..I was looking for some advice on where to copy the FE and BE and I found your post.

Can you please tell me the database name in the shortcut "\\Server\Partition\Directory\DatabaseFile.mdb" is front end or backend ?

Can I assume that this is frontend because you mentioned that
"The shortcut, front end and the Workgroup.mdw files should not be shared."

Thanks

 

[ghudson]

03/09/2005 is the data I posted the thread you are questioning.

Yes, I am referring to the front end. The user should never be opening the back end directly. The shared tables in the front end will be linked to the back end.

 

[llkhoutx]

You're correct, it's the front end.

The front end is what one executes in a split Access program. Of course, the back end is linked to the front end.

 

[Bosch]

Thanks guys..
I finally got the security working.