If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
A2K Splitting and Security
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. |
#2
|
|||
|
|||
A2K Splitting and Security
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" wrote: 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. |
#3
|
|||
|
|||
A2K Splitting and Security
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? "mscertified" wrote: 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" wrote: 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. |
#4
|
|||
|
|||
A2K Splitting and Security
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...ent/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" wrote in message ... 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. |
#5
|
|||
|
|||
A2K Splitting and Security
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? "John Welch" wrote: 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...ent/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" wrote in message ... 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. |
#6
|
|||
|
|||
A2K Splitting and Security
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. "John Welch" wrote: 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...ent/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" wrote in message ... 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. |
#7
|
|||
|
|||
A2K Splitting and Security
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 "Ted" wrote: 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? "mscertified" wrote: 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" wrote: 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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Splitting - Ready Only | KReese | Database Design | 3 | November 16th, 2005 11:32 PM |
splitting the database | Gitche Gumee | Database Design | 4 | October 16th, 2005 05:52 PM |
Splitting A Database | Wstanley | Database Design | 5 | August 18th, 2005 10:54 PM |
Questions on splitting | hackmn_g | General Discussion | 6 | April 29th, 2005 09:04 PM |
Sharing mdbfiles | Jan | General Discussion | 9 | December 31st, 2004 07:37 PM |