A2K Splitting and Security

[Ted]

i am trying to wrap my mind around how database splittng and password
protection would work with an a2k application. so far the only result i have
to show for it is a splitting headache i think that once i manage to
implement it on a real (as opposed to mocked up prototype) of a database
which has the FE sitting on a user's pc and the BE on a shared corporate
network drive that i would like for the FE AND BE to password protected.
moreover, the piece de resistance to me of this enhanced security would
incorporate the idea of the complied mde type file.

thus far i have been using mdb applications developed w/ a2k that sit on a
commonly accessible corporate network drive. the mdb is encrypted and
password
protected and i don't have user level security (at least not with the use of
the native files of a2k's -- i do however use a third party vendor's product
whic i find easier than ms') and i have been reading that once a user's FE is
on his/her pc and the BE is on a shared network drive that some other a2k
system type files need go to the network drive as well.

anyway, does anyone have a recipe/checklist that i could use to go through
the process of bringing an a2k application into the world of split databases
that have both FE and BE password protected?

hope this narrative makes sense to somebody.

 

[mscertified]

Why don't you use network security to protect the back end database, its
better than using a password. It can be granted and revoked. Any why password
protect the front end?

-Dorian

 

[Ted]

hi,

we have ms 2000 on the corporate network but i'm not a network person.
although the permission to access the shared drive where the backend would
live are granted only to a fraction of the potential employees, so only
trusted users would have access to it, if i were to implement the FE/BE
arrangement, i'm concerned that someone might decide to download the BE file
so my plan would try to get around the fact that that would be doable by
encrypting and password protecting it.

can you expand on what you have in mind for the BE. as for why password
protect the FE, well it just seems like you wouldn't want just anyone to walk
over to a pc equipped with a shortcut to the FE and start messing with it
would you? i mean is there something i'm not understanding and i mean this in
a friendly way?

 

[John Welch]

Ted-
tablesdbdesign isn't really the best place to post a question about
security, but..anyway, it's best not to immediately post the same question
somewhere else either.
For info on Access User level security, see this link:
http://support.microsoft.com/support/access/content/secfaq.asp
You don't really need user level security if you don't care about assigning
different permissions to different users. You could just have a single
database password that everyone uses. But usually people want to give
different permissions to different users and so they use ULS. That "other
system type file" would be a workgroup (.mdw) file that stores the usernames
and passwords and group affiliations. Check out the online info- it's tricky
to set it all up just right.
hope this helps
-John

 

[Ted]

john, i thought it was the least bad 'fit' given the topic under discussion
so....

at any rate, what i would be using to handle user-level security is a 3rd
party vendor's product they dubbed 'LASsie' that seems to have the
functionality for this. there would be two passwords needed to hurdle, 1) the
a2k password all users share and 2) a user-generated password corresponding
to the user's log-in name which would map him/her to a security level. i
don't really intend to dwell on this because that's not what's driving this
thread although it might appear to be.

what i'm concerned about is this.....given there are two files around, a FE
on the user's desktop and a BE sitting on a shared network drive with
(admittedly) limited access to users, the FE is password protectable via the
native a2k capability (we'll just ignore the LASsie contribution for this
discussion) and i have tried protecting the BE the same way and with the
identical password (even while sitting on the same desktop of my pc) but when
i do and i tried to access the data via the appropriate form in my FE i got a
message saying: "Not a valid password" and this was true as well if i clicked
on a query that used the underlying table in the BE database. i'm newbie
enough to imagine (read 'wish') that somehow the BE's password would 'osmose'
its way into the FE and be 'known' to it enabling the user to implement
his/her data entry chores. do you see the problem?

 

[Ted]

anyone reading this thread: i just found the solution in the 'security'
forum, look under 'Add password to backend' -- the 'trick' apparently is to
delete the linked table(s) and then relink them from the password protected
BE. i tried it on a mock up of my database by selecting a form in the FE that
uses the linked table in the password protected BE and it works.

 

[mscertified]

If you are concerned with someone walking over to a PC and messing with it,
you should instruct your users to lock their computer before walking away (a
good idea anyway). What is to say someone is not inside the application,
already having entered the password when they walk away? In my experience,
users open an application then leave it open all day.
Access passwords are not that secure. Anyone can download a utility off the
internet which will deciper the password.
A better way is to detect the windows user in code (easy), then stop
unauthorized users. Just have the list of valid users in a table on the back
end. If you want to have a password have a system generated password for each
user. The passwords can be derived from the windows logon id by applying an
algorithm (hidden inside the mde).

-Dorian