|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
shift override in split databaseHi
I have a split database, both parts (FE and BE) have been copied to provide a development database. Both use the same workgroup file. When I further develop the database and try to distribute it for live use, all of the security groups and access rights change, so I have to spend several hours reinstating them every time. How can I stop this. Also, I went to great lengths to secure my database. The FE is an mde file, and there is a button on a form that only the administrator can get to that will disable the shift over ride. Because it is a multi user db, I took advice on how to split it into a FE and BE (i.e. don't use the database splitter functionality in Access) and this has left me with a BE that only contains tables and is completely exposed. How do I stop people from opening the BE and viewing the data? "inbreda" <inbr***@discussions.microsoft.com> wrote in message Can you expand on what you mean by this? It would seem that you may have news:A7FFA005-0446-4D87-9C5B-2BCF677028FB@microsoft.com... > Hi > > I have a split database, both parts (FE and BE) have been copied to > provide > a development database. Both use the same workgroup file. > > When I further develop the database and try to distribute it for live use, > all of the security groups and access rights change, so I have to spend > several hours reinstating them every time. How can I stop this. missed a step in the securiing process. > You need to remove rights to the users group.> Also, I went to great lengths to secure my database. The FE is an mde > file, > and there is a button on a form that only the administrator can get to > that > will disable the shift over ride. Because it is a multi user db, I took > advice on how to split it into a FE and BE (i.e. don't use the database > splitter functionality in Access) and this has left me with a BE that only > contains tables and is completely exposed. How do I stop people from > opening > the BE and viewing the data? Have you read the MS FAQ on Access security? There's a link to it on my web site. In short, it's essential reading and once you fully understand it then you'll be able to correct the problems you describe. It's one steep learning curve and there's no filler in it but there's no substitute for it either. Good luck with your project. Keith. www.keithwilby.com I started with a database that is opened using a shortcut, and uses an .mdw
file. The mdw security is fine. User and admin accounts have no permissions. Depending what user group the user belongs to dictates what tables and forms they can open/delete/update etc. The database was then split into FE forms/reports etc and a BE data source. This is my live database. I then copied the live FE and BE to use for development (DFE and DBE). This development database uses the same mdw file. Password restricted access still works. Once I've done some development work on the DFE and tested it thoroughly against DBE data, I overwrite the live FE with the development DFE. I then delete the table links (which of course still point to DBE) and then recreate table links to the live BE, so my users can continue using the database and access the same data they were previously using. I expect to do this piece of work, however the database no longer works properly. This is because the user group permissions have all been reset, so I have to go into tools>security>user and group permissions, and reassign all of the tables/forms/reports that each security group is allowed to open/modify/update/delete/insert. This takes a LONG time and annoys me because all of the permissions on the FE, BE, DFE and DBE should all be the same. Is there something I can do to avoid resetting all these permissions every time I release a new version of the database? The second part of my question regards shift override. When I release a new version of the FE (i.e. when I overwrite live FE with DFE) I make it an mde file and disable the shift override of startup options (by clicking a specially placed hidden button on a form that only the admin user can reach). This succesfully prevents users from overriding the startup options ... but only on the FE. The BE with all of the important data in can still be opened, and all tables that the user has read permission for can be viewed. This really isn't very secure, but removing access rights will surely prevent forms in the FE from working properly? Cheers. Show quoteHide quote "Keith Wilby" wrote: > "inbreda" <inbr***@discussions.microsoft.com> wrote in message > news:A7FFA005-0446-4D87-9C5B-2BCF677028FB@microsoft.com... > > Hi > > > > I have a split database, both parts (FE and BE) have been copied to > > provide > > a development database. Both use the same workgroup file. > > > > When I further develop the database and try to distribute it for live use, > > all of the security groups and access rights change, so I have to spend > > several hours reinstating them every time. How can I stop this. > > Can you expand on what you mean by this? It would seem that you may have > missed a step in the securiing process. > > > > > Also, I went to great lengths to secure my database. The FE is an mde > > file, > > and there is a button on a form that only the administrator can get to > > that > > will disable the shift over ride. Because it is a multi user db, I took > > advice on how to split it into a FE and BE (i.e. don't use the database > > splitter functionality in Access) and this has left me with a BE that only > > contains tables and is completely exposed. How do I stop people from > > opening > > the BE and viewing the data? > > You need to remove rights to the users group. > > Have you read the MS FAQ on Access security? There's a link to it on my web > site. In short, it's essential reading and once you fully understand it > then you'll be able to correct the problems you describe. It's one steep > learning curve and there's no filler in it but there's no substitute for it > either. > > Good luck with your project. > > Keith. > www.keithwilby.com > > > inbreda wrote:
> The database was then split into FE forms/reports etc and a BE data When you split it did you use the splitter wizard? That will result in an > source. This is my live database. unsecure BE. > This is because the user group This will happen if you import any objects - permissions do not travel with > permissions have all been reset, so I have to go into > tools>security>user and group permissions, and reassign all of the > tables/forms/reports that each security group is allowed to > open/modify/update/delete/insert. the objects. > The BE with You can disable the shiftkey bypass in the BE as well. Put an autoexec > all of the important data in can still be opened, and all tables that > the user has read permission for can be viewed. This really isn't > very secure, but removing access rights will surely prevent forms in > the FE from working properly? macro in it that displays a message and closes the database. In addition you can remove all permissions on the backend tables, and use RWOP (run with owner permission) queries in the FE for all data interaction. -- Joan Wild Microsoft Access MVP No I didn't split it using the wizard. I copied the database and called one
FE, and the other BE, and then linked the tables. Although p[ermissions do not travel with tables I was surprised as the permissions should be the same on hte BE, FE and development FE and development BE... but it still resets all of the permissions and costs me time in resetting everything every time I re-release a database. Another Access annoyance!!! Show quoteHide quote "Joan Wild" wrote: > inbreda wrote: > > The database was then split into FE forms/reports etc and a BE data > > source. This is my live database. > > When you split it did you use the splitter wizard? That will result in an > unsecure BE. > > > This is because the user group > > permissions have all been reset, so I have to go into > > tools>security>user and group permissions, and reassign all of the > > tables/forms/reports that each security group is allowed to > > open/modify/update/delete/insert. > > This will happen if you import any objects - permissions do not travel with > the objects. > > > The BE with > > all of the important data in can still be opened, and all tables that > > the user has read permission for can be viewed. This really isn't > > very secure, but removing access rights will surely prevent forms in > > the FE from working properly? > > You can disable the shiftkey bypass in the BE as well. Put an autoexec > macro in it that displays a message and closes the database. > > In addition you can remove all permissions on the backend tables, and use > RWOP (run with owner permission) queries in the FE for all data interaction. > > > -- > Joan Wild > Microsoft Access MVP > > > I have never seen or heard of this.
-- Show quoteHide quoteJoan Wild Microsoft Access MVP inbreda wrote: > No I didn't split it using the wizard. I copied the database and > called one FE, and the other BE, and then linked the tables. > > Although p[ermissions do not travel with tables I was surprised as the > permissions should be the same on hte BE, FE and development FE and > development BE... but it still resets all of the permissions and > costs me time in resetting everything every time I re-release a > database. Another Access annoyance!!! > > "Joan Wild" wrote: > >> inbreda wrote: >>> The database was then split into FE forms/reports etc and a BE data >>> source. This is my live database. >> >> When you split it did you use the splitter wizard? That will result >> in an unsecure BE. >> >>> This is because the user group >>> permissions have all been reset, so I have to go into >>> tools>security>user and group permissions, and reassign all of the >>> tables/forms/reports that each security group is allowed to >>> open/modify/update/delete/insert. >> >> This will happen if you import any objects - permissions do not >> travel with the objects. >> >>> The BE with >>> all of the important data in can still be opened, and all tables >>> that the user has read permission for can be viewed. This really >>> isn't very secure, but removing access rights will surely prevent >>> forms in the FE from working properly? >> >> You can disable the shiftkey bypass in the BE as well. Put an >> autoexec macro in it that displays a message and closes the database. >> >> In addition you can remove all permissions on the backend tables, >> and use RWOP (run with owner permission) queries in the FE for all >> data interaction. >> >> >> -- >> Joan Wild >> Microsoft Access MVP
application deployment for SP2
New Post - Owner deleted - No backups, nothing! Problem with Multi-users in Access97 Suggestion on deploying and securing an Access appl Database Password how I add an username + posword to a mdb file? Preventing design changes with share-based security Workgroup file in Network drive and Local computer Hiding database window In Security, Workgroup Administrator Add Check Box to always point |
|||||||||||||||||||||||