|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Permissions Keep Changinginstructions I found from the internet. I set up different groups with different permission levels, and assigned each user (we have about 90 users) to the appropriate group. I then removed the Admin user from the Admins group, placed Admin in the Users group, assigned a password to the Admin user, as well. I then eliminated all permissions from the Users group. This seemed to work out well. All users have been getting the correct access, no problems. There are only 2 persons with permissions to do everything in the database (design, delete records, and modify permissions) -- myself and the IT Director. No one knows anyone else's passwords because I have a button where the users changes his/her password as often as they like to whatever they like. I don't have the IT Director's password, and she doesn't have mine -- so there is no password sharing. No one (except IT Director and myself) can delete any data from the database. There is a frontend and backend, and data can only be deleted from the backend tables. Recently, there have been some odd things happening with the data -- mainly records disappearing. I have audit tables, too, and when the records disappear, all related insert/modify records in the audit table disappear as well. Kinda looked like someone deleted records, then deleted any evidence the records were there. BUT, the evidence that the records was there because there was still related data in other tables, once connected to the client id that had been deleted. I was puzzled by the fact that records were being deleted when no one had permission to do so except myself and the IT Dir. Neither of us were doing this. I looked at the permissions, and it had all been changed, where most of the groups had permission to delete records. AND -- ALL the User group permissions (that I so carefully removed a year ago) had been restored. I fixed all the permissions the way they were supposed to be, and eliminated all permissions from the Users group. Records continued to be deleted. I checked the permissions again, and the Users group had again been restored. I removed permissions from that group again. Records still were being deleted. I looked at the hidden system tables, and saw that the Users group had full permissions for all of the System tables, so I deleted permissions from the Users group for the system tables. I had to GIVE "read" permission to all of the groups for the MSysAccessObjects, MSysObjects, and MSysQueries tables in order for staff to use the database. The reason I did this is because a couple of months ago, one of our staff suddenly couldn't open the database. When I watched her try to open it, her computer attempted to bypass the login screen to open the database directly, but instead she got an error message saying something like she didn't have design permissions for MSysAccessObjects -- and she could not get in. One of the IT people found something from Microsoft about how hackers try to use the Admin user to get in the database, like a "backdoor" entrance -- so I thought there might have been some vb code on her computer that was attempting to bypass the login and go straight into the computer as the Admin user, but failed because I had the Admin user disabled in the Users group. IT worked on this person's computer for a long time, could NEVER get it to be able to open an access database, and finally had to trash it. It wasn't just a simple matter of not being connected to the wrong workgroup, it wouldn't open any database due to "you don't have design permissions for MSysAccessObject" (or something to that effect). So, when I saw the Users group having permission to MSysAccessObject (knowing that the Admin user is part of the Users group), I removed all permissions to the system tables from the Users group. A week later, the Users group had permissions restored to the system tables, and it was removed from all the other groups. I removed permissions for System tables from Users group, and restored it for the staff groups. A day later, Users group had System table permissions again (that was yesterday), so I removed again. So far, today, Users group does not have any permissions to the systems table, but I keep checking throughout the day. The IT Dir has been on vacation all week, and we both changed our passwords just before she left. If someone is getting into the database on one of our passwords, how could they get the password since we don't share with anyone? Or, does Access automatically restore permissions to the Users group for system tables after a day or so? If so or if not, how could records get deleted when only the IT dir and myself have delete permissions (and she is on vacation)? And how could all the other group permissions for delete get restored when I painstakingly removed delete permissions a year ago to all the tables? I'm stumped and not quite sure which way to proceed to get this database secured. Oh, I disabled the shift+enter key bypass on both front and backends. I also unchecked all the boxes in the startup menu except for the db to open to the main menu. I also password-protected all the modules. Does anyone understand what's going on and/or how to fix it? All advice greatly appreciated. Janet,
I believe Joan Wild told you, in another thread, that you should NOT be attempting to do anything with permissions to System tables. That is a dangerous practice. -- Show quoteLynn Trapp MS Access MVP www.ltcomputerdesigns.com Access Security: www.ltcomputerdesigns.com/Security.htm Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html "Janet" <Ja***@discussions.microsoft.com> wrote in message news:7546F480-7363-4AE8-92EC-A72EAD5FB736@microsoft.com... > About a year ago, I set up User Level Security per some step-by-step > instructions I found from the internet. I set up different groups with > different permission levels, and assigned each user (we have about 90 > users) > to the appropriate group. I then removed the Admin user from the Admins > group, placed Admin in the Users group, assigned a password to the Admin > user, as well. I then eliminated all permissions from the Users group. > This > seemed to work out well. All users have been getting the correct access, > no > problems. > > There are only 2 persons with permissions to do everything in the database > (design, delete records, and modify permissions) -- myself and the IT > Director. No one knows anyone else's passwords because I have a button > where > the users changes his/her password as often as they like to whatever they > like. I don't have the IT Director's password, and she doesn't have > mine -- > so there is no password sharing. > > No one (except IT Director and myself) can delete any data from the > database. There is a frontend and backend, and data can only be deleted > from > the backend tables. > > Recently, there have been some odd things happening with the data -- > mainly > records disappearing. I have audit tables, too, and when the records > disappear, all related insert/modify records in the audit table disappear > as > well. Kinda looked like someone deleted records, then deleted any > evidence > the records were there. BUT, the evidence that the records was there > because > there was still related data in other tables, once connected to the client > id > that had been deleted. > > I was puzzled by the fact that records were being deleted when no one had > permission to do so except myself and the IT Dir. Neither of us were > doing > this. I looked at the permissions, and it had all been changed, where > most > of the groups had permission to delete records. AND -- ALL the User group > permissions (that I so carefully removed a year ago) had been restored. > > I fixed all the permissions the way they were supposed to be, and > eliminated > all permissions from the Users group. Records continued to be deleted. I > checked the permissions again, and the Users group had again been > restored. > I removed permissions from that group again. Records still were being > deleted. > > I looked at the hidden system tables, and saw that the Users group had > full > permissions for all of the System tables, so I deleted permissions from > the > Users group for the system tables. I had to GIVE "read" permission to all > of > the groups for the MSysAccessObjects, MSysObjects, and MSysQueries tables > in > order for staff to use the database. > > The reason I did this is because a couple of months ago, one of our staff > suddenly couldn't open the database. When I watched her try to open it, > her > computer attempted to bypass the login screen to open the database > directly, > but instead she got an error message saying something like she didn't have > design permissions for MSysAccessObjects -- and she could not get in. One > of > the IT people found something from Microsoft about how hackers try to use > the > Admin user to get in the database, like a "backdoor" entrance -- so I > thought > there might have been some vb code on her computer that was attempting to > bypass the login and go straight into the computer as the Admin user, but > failed because I had the Admin user disabled in the Users group. IT > worked > on this person's computer for a long time, could NEVER get it to be able > to > open an access database, and finally had to trash it. It wasn't just a > simple matter of not being connected to the wrong workgroup, it wouldn't > open > any database due to "you don't have design permissions for > MSysAccessObject" > (or something to that effect). So, when I saw the Users group having > permission to MSysAccessObject (knowing that the Admin user is part of the > Users group), I removed all permissions to the system tables from the > Users > group. > > A week later, the Users group had permissions restored to the system > tables, > and it was removed from all the other groups. I removed permissions for > System tables from Users group, and restored it for the staff groups. A > day > later, Users group had System table permissions again (that was > yesterday), > so I removed again. So far, today, Users group does not have any > permissions > to the systems table, but I keep checking throughout the day. > > The IT Dir has been on vacation all week, and we both changed our > passwords > just before she left. If someone is getting into the database on one of > our > passwords, how could they get the password since we don't share with > anyone? > Or, does Access automatically restore permissions to the Users group for > system tables after a day or so? If so or if not, how could records get > deleted when only the IT dir and myself have delete permissions (and she > is > on vacation)? And how could all the other group permissions for delete get > restored when I painstakingly removed delete permissions a year ago to all > the tables? I'm stumped and not quite sure which way to proceed to get > this > database secured. > > Oh, I disabled the shift+enter key bypass on both front and backends. I > also unchecked all the boxes in the startup menu except for the db to open > to > the main menu. I also password-protected all the modules. Does anyone > understand what's going on and/or how to fix it? > > All advice greatly appreciated. Well, here's my third (and last) try to help you fix your problem!
You'll get nowhere by: (1) Listening to people who don't know what they're talking about ("One of the IT people found something from Microsoft about how hackers try to use the Admin user to get in the database, like a "backdoor" entrance") Or: (2) Making false assumptions about how to fix the problem. ("So, when I saw the Users group having permission to MSysAccessObject (knowing that the Admin user is part of the Users group), I removed all permissions to the system tables from the Users group.) Instead, you need to: (1) Get the db to a known state; (2) *Do nothing more*, until the permissions have automagically changed themselves, then (3) Post back, describing (as best you can) exactly who did what in the period between (1) and (2). TC Well, TC, the people who didn't know what they were talking about were
Microsoft, as I had read that in an article from Microsoft. You may or may not be right about my assuming things about the Users group and System tables. I don't know for sure yet. I got the DB in a known state (again), and the permissions changed again over the weekend. I have no idea of "who did what in the period inbetween" which is WHY I am posting to this newsgroup. I am trying to find out "what is happening" to cause my permissions to change. Oh well, it doesn't seem that anyone there really has any idea of what to do to solve this issue, so I won't take up your time with any more of this. Thanks for trying, though. :-) Show quote "TC" wrote: > Well, here's my third (and last) try to help you fix your problem! > > You'll get nowhere by: > > (1) Listening to people who don't know what they're talking about ("One > of the IT people found something from Microsoft about how hackers try > to use the Admin user to get in the database, like a "backdoor" > entrance") > > Or: > > (2) Making false assumptions about how to fix the problem. ("So, when I > saw the Users group having permission to MSysAccessObject (knowing > that the Admin user is part of the Users group), I removed all > permissions to the system tables from the Users group.) > > Instead, you need to: > > (1) Get the db to a known state; > > (2) *Do nothing more*, until the permissions have automagically changed > themselves, then > > (3) Post back, describing (as best you can) exactly who did what in the > period between (1) and (2). > > TC > > Janet wrote:
> Well, TC, the people who didn't know what they were talking about Sorry, my reply was probably not very clear. You said that someone hadwere > Microsoft, as I had read that in an article from Microsoft. told you that "hackers can try to use the Admin user to get in the database, like a backdoor entrance". I really only meant to say: "This is not possible, if the database has been properly secured." Somehow, that came out as: "&*$$% *&%^$# $#@# !!!" :-) > I got the DB in a known state (again), and the permissions changed Ok, so now we have a known state, to take this further. You did not doagain > over the weekend. I have no idea of "who did what in the period inbetween" > which is WHY I am posting to this newsgroup. I am trying to find out "what > is happening" to cause my permissions to change. /anything/ such as adding or deleting users, or changing user permissions yourself, or joining different workgroup files, in the interim period - right? > Oh well, it doesn't seem that anyone there really has any idea of what to do> to solve this issue, so I won't take up your time with any more of Sure we can solve it! But we need to go step by step, not changingthis. > Thanks for trying, though. :-) /anything/ unless that is discussed "up front". With respect, your previous attempts were not a success, because you kept making changes that just caused more problems. So, if both of us have the patience to follow this through, let's get going! I apologise if these questions have been answered before, but I'd like to get the info. afresh, not go back through all the previous posts. 1. Is you db split into a front-end/back end structure? 2. Is there one BE, stored on a central server? If not, what? 3. Does each user of the FE have a seperate copy of the FE, on their PC? If not, what? 4. Are you using a single workgroup file, stored on the central server? If not, what? 5. Does each user start the system via a shortcut of the following form (all on one line): "full path to msaccess.exe" "full path to FE on user's PC" /wrkgrk "full path to wgf on server" 6. Do any users start the system by double-clicking a database file (ie. not using a shortcut)? 7. Does any user use the workgroup administrator program manually? 8. How /exactly/ are you checking what permissions a given user has? IOW, how do you know /for sure/, that someone's permissions have changed? Janet, believe me: if you follow this through in a discipled way, I have no doubt that I can fix your problem! [takes deep breath at foolish commitment] Note that I can only get one session on the net, per day. Please take that into account, when you check for replies. Cheers, TC During the interim (this past weekend) the "User Group" permissions were
changed again on both front end and back ends to include ALL permissions for MSysAccessObjects system table. The change also included removing "read" permission to other groups for this system table. Several times, I have removed all permissions from the Users group, including system table permissions. To enable my other groups to use the database, I had to give to these groups "read" permission for the MSysAccessObjects system table. Several times, this has gotten changed back where Users group gets full permissions to MSysAccessObjects table and my created groups get the "read" permission to this system table removed. So, last Friday, I removed all permissions from Users group to the MSysAccessObject table, giving "read" permission to my created groups to this system table. On Monday when I returned, Users group again has FULL permissions to MSysAccessObjects, and my created groups had their "read" permission removed. I don't know how this is happening -- someone doing it? Access doing it automatically? I have not changed it again. I have left it where the Users group has full permissions to the system table, but am not comfortable with it -- but haven't changed it back since I'm getting so much flack for messing with the system tables. But my question is: how does this keep changing back over the weekend, when I do NOTHING to the database over the weekend (am not even here) -- but other users are here on the weekend.... Show quote "TC" wrote: YES, I have a back with data and a front with forms, queries, etc.> > Janet wrote: > > > Well, TC, the people who didn't know what they were talking about > were > > Microsoft, as I had read that in an article from Microsoft. > > Sorry, my reply was probably not very clear. You said that someone had > told you that "hackers can try to use the Admin user to get in the > database, like a backdoor entrance". I really only meant to say: "This > is not possible, if the database has been properly secured." Somehow, > that came out as: "&*$$% *&%^$# $#@# !!!" :-) > > > > I got the DB in a known state (again), and the permissions changed > again > > over the weekend. I have no idea of "who did what in the period > inbetween" > > which is WHY I am posting to this newsgroup. I am trying to find out > "what > > is happening" to cause my permissions to change. > > Ok, so now we have a known state, to take this further. You did not do > /anything/ such as adding or deleting users, or changing user > permissions yourself, or joining different workgroup files, in the > interim period - right? > > > > Oh well, it doesn't seem that anyone there really has any idea of > what to do > > to solve this issue, so I won't take up your time with any more of > this. > > Thanks for trying, though. :-) > > Sure we can solve it! But we need to go step by step, not changing > /anything/ unless that is discussed "up front". With respect, your > previous attempts were not a success, because you kept making changes > that just caused more problems. > > So, if both of us have the patience to follow this through, let's get > going! > > I apologise if these questions have been answered before, but I'd like > to get the info. afresh, not go back through all the previous posts. > > 1. Is you db split into a front-end/back end structure? > There is one BE and one FE, both stored on a network drive.> 2. Is there one BE, stored on a central server? If not, what? > NO -- Each user simply has a shortcut icon on their desktop, from > 3. Does each user of the FE have a seperate copy of the FE, on their > PC? If not, what? NO. There is one FE on a network drive that all users have access to. I have to upgrade the db at least weekly, so it would be impossible to go around and upgrade each person's desktop version since there are about 80 different persons who could be using this database (though usually only about 10 people are in it at one time). > > 4. Are you using a single workgroup file, stored on the central server? > If not, what? YES a single workgroup file stored on a central server. > > 5. Does each user start the system via a shortcut of the following form > (all on one line): > > "full path to msaccess.exe" > "full path to FE on user's PC" > /wrkgrk "full path to wgf on server" > right-clicking the front-end file, and choosing "Send to Desktop as Shortcut." 6. Do any users start the system by double-clicking a database file Show quote > (ie. not using a shortcut)? Probably so - thinking about my answer to #5 above -- but it's a short-cut to the file, not the file itself. Does that matter? Thank you so much TC, and I will hang in here and learn what I can from you. > > 7. Does any user use the workgroup administrator program manually? I do, and the IT Director could if she wanted (though she says she doesn't). I have the FE setup to that the tools menu is not in the Startup options so regular users can't click Tools, Security, Workgroup Administrator, and I have the shift+enter key disabled, so they can't get to it that way. Is this what you mean? > > 8. How /exactly/ are you checking what permissions a given user has? > IOW, how do you know /for sure/, that someone's permissions have > changed? I open the db, go to tools/security/permissions and look at each group and what permissions are set for what tables/forms/queries/macros, etc. > > > Janet, believe me: if you follow this through in a discipled way, I > have no doubt that I can fix your problem! [takes deep breath at > foolish commitment] --No foolish commitment here -- this is my job and I want to keep it -- not by letting the db security be compromised either by my ignorance malicious intent by some user or hacker. > > Note that I can only get one session on the net, per day. Please take > that into account, when you check for replies. > > Cheers, > TC > Just so you will know, I am mostly self-taught in Access over the past 5 years -- have taken a couple of one-day seminars, but found I already knew what was being taught (and more) -- though self-learning has its draw--backs because some things are missed that are critical. Thanks again and will watch for your reply. Show quote > Aside from questioning whether you've properly secured the database to begin
with, the next thing I'd look at would be how strong is the password you are using to administer it? There are a variety of hacks that will analyze an MDW and crack weak passwords. If one of your users has such a utility, obviously they can log in as you and change the permissions to whatever they like. FWIW...the hacks that I've seen have trouble cracking passwords beyond 16 characters, and the inclusion of upper ASCII and/or quotes or other characters that are troublesome to Jet SQL seem to trip them up...but no doubt they'll figure that out at some point as well. USL will keep honest people out, but don't rely on it to guard Fort Knox or against determined hackers. Show quote "Janet" <Ja***@discussions.microsoft.com> wrote in message news:DE5A4D49-D5F9-4EE0-9DA3-07F9E264CEAA@microsoft.com... > During the interim (this past weekend) the "User Group" permissions were > changed again on both front end and back ends to include ALL permissions > for > MSysAccessObjects system table. The change also included removing "read" > permission to other groups for this system table. Several times, I have > removed all permissions from the Users group, including system table > permissions. To enable my other groups to use the database, I had to give > to > these groups "read" permission for the MSysAccessObjects system table. > Several times, this has gotten changed back where Users group gets full > permissions to MSysAccessObjects table and my created groups get the > "read" > permission to this system table removed. So, last Friday, I removed all > permissions from Users group to the MSysAccessObject table, giving "read" > permission to my created groups to this system table. On Monday when I > returned, Users group again has FULL permissions to MSysAccessObjects, and > my > created groups had their "read" permission removed. I don't know how this > is > happening -- someone doing it? Access doing it automatically? I have not > changed it again. I have left it where the Users group has full > permissions > to the system table, but am not comfortable with it -- but haven't changed > it > back since I'm getting so much flack for messing with the system tables. > But > my question is: how does this keep changing back over the weekend, when I > do > NOTHING to the database over the weekend (am not even here) -- but other > users are here on the weekend.... > > "TC" wrote: > >> >> Janet wrote: >> >> > Well, TC, the people who didn't know what they were talking about >> were >> > Microsoft, as I had read that in an article from Microsoft. >> >> Sorry, my reply was probably not very clear. You said that someone had >> told you that "hackers can try to use the Admin user to get in the >> database, like a backdoor entrance". I really only meant to say: "This >> is not possible, if the database has been properly secured." Somehow, >> that came out as: "&*$$% *&%^$# $#@# !!!" :-) >> >> >> > I got the DB in a known state (again), and the permissions changed >> again >> > over the weekend. I have no idea of "who did what in the period >> inbetween" >> > which is WHY I am posting to this newsgroup. I am trying to find out >> "what >> > is happening" to cause my permissions to change. >> >> Ok, so now we have a known state, to take this further. You did not do >> /anything/ such as adding or deleting users, or changing user >> permissions yourself, or joining different workgroup files, in the >> interim period - right? >> >> >> > Oh well, it doesn't seem that anyone there really has any idea of >> what to do >> > to solve this issue, so I won't take up your time with any more of >> this. >> > Thanks for trying, though. :-) >> >> Sure we can solve it! But we need to go step by step, not changing >> /anything/ unless that is discussed "up front". With respect, your >> previous attempts were not a success, because you kept making changes >> that just caused more problems. >> >> So, if both of us have the patience to follow this through, let's get >> going! >> >> I apologise if these questions have been answered before, but I'd like >> to get the info. afresh, not go back through all the previous posts. >> >> 1. Is you db split into a front-end/back end structure? > > YES, I have a back with data and a front with forms, queries, etc. >> >> 2. Is there one BE, stored on a central server? If not, what? > There is one BE and one FE, both stored on a network drive. >> >> 3. Does each user of the FE have a seperate copy of the FE, on their >> PC? If not, what? NO. There is one FE on a network drive that all users >> have access to. I have to upgrade the db at least weekly, so it would be >> impossible to go around and upgrade each person's desktop version since >> there are about 80 different persons who could be using this database >> (though usually only about 10 people are in it at one time). >> >> 4. Are you using a single workgroup file, stored on the central server? >> If not, what? YES a single workgroup file stored on a central server. >> >> 5. Does each user start the system via a shortcut of the following form >> (all on one line): >> >> "full path to msaccess.exe" >> "full path to FE on user's PC" >> /wrkgrk "full path to wgf on server" >> > NO -- Each user simply has a shortcut icon on their desktop, from > right-clicking the front-end file, and choosing "Send to Desktop as > Shortcut." > > > 6. Do any users start the system by double-clicking a database file >> (ie. not using a shortcut)? Probably so - thinking about my answer to #5 >> above -- but it's a short-cut to the file, not the file itself. Does that >> matter? >> >> 7. Does any user use the workgroup administrator program manually? I do, >> and the IT Director could if she wanted (though she says she doesn't). I >> have the FE setup to that the tools menu is not in the Startup options so >> regular users can't click Tools, Security, Workgroup Administrator, and I >> have the shift+enter key disabled, so they can't get to it that way. Is >> this what you mean? >> >> 8. How /exactly/ are you checking what permissions a given user has? >> IOW, how do you know /for sure/, that someone's permissions have >> changed? I open the db, go to tools/security/permissions and look at >> each group and what permissions are set for what >> tables/forms/queries/macros, etc. >> >> >> Janet, believe me: if you follow this through in a discipled way, I >> have no doubt that I can fix your problem! [takes deep breath at >> foolish commitment] --No foolish commitment here -- this is my job and I >> want to keep it -- not by letting the db security be compromised either >> by my ignorance malicious intent by some user or hacker. >> >> Note that I can only get one session on the net, per day. Please take >> that into account, when you check for replies. >> >> Cheers, >> TC >> > Thank you so much TC, and I will hang in here and learn what I can from > you. > Just so you will know, I am mostly self-taught in Access over the past 5 > years -- have taken a couple of one-day seminars, but found I already knew > what was being taught (and more) -- though self-learning has its > draw--backs > because some things are missed that are critical. Thanks again and will > watch for your reply. >> Thanks Paul, this helps. My Administer password is likely weak. I'll also
relay this to the IT Director (who also has full administer permissions) so she can be sure her password is strong. Thanks so much. Show quote "Paul Overway" wrote: > Aside from questioning whether you've properly secured the database to begin > with, the next thing I'd look at would be how strong is the password you are > using to administer it? There are a variety of hacks that will analyze an > MDW and crack weak passwords. If one of your users has such a utility, > obviously they can log in as you and change the permissions to whatever they > like. FWIW...the hacks that I've seen have trouble cracking passwords > beyond 16 characters, and the inclusion of upper ASCII and/or quotes or > other characters that are troublesome to Jet SQL seem to trip them up...but > no doubt they'll figure that out at some point as well. > > USL will keep honest people out, but don't rely on it to guard Fort Knox or > against determined hackers. > > -- > Paul Overway > Logico Solutions > http://www.logico-solutions.com > > > "Janet" <Ja***@discussions.microsoft.com> wrote in message > news:DE5A4D49-D5F9-4EE0-9DA3-07F9E264CEAA@microsoft.com... > > During the interim (this past weekend) the "User Group" permissions were > > changed again on both front end and back ends to include ALL permissions > > for > > MSysAccessObjects system table. The change also included removing "read" > > permission to other groups for this system table. Several times, I have > > removed all permissions from the Users group, including system table > > permissions. To enable my other groups to use the database, I had to give > > to > > these groups "read" permission for the MSysAccessObjects system table. > > Several times, this has gotten changed back where Users group gets full > > permissions to MSysAccessObjects table and my created groups get the > > "read" > > permission to this system table removed. So, last Friday, I removed all > > permissions from Users group to the MSysAccessObject table, giving "read" > > permission to my created groups to this system table. On Monday when I > > returned, Users group again has FULL permissions to MSysAccessObjects, and > > my > > created groups had their "read" permission removed. I don't know how this > > is > > happening -- someone doing it? Access doing it automatically? I have not > > changed it again. I have left it where the Users group has full > > permissions > > to the system table, but am not comfortable with it -- but haven't changed > > it > > back since I'm getting so much flack for messing with the system tables. > > But > > my question is: how does this keep changing back over the weekend, when I > > do > > NOTHING to the database over the weekend (am not even here) -- but other > > users are here on the weekend.... > > > > "TC" wrote: > > > >> > >> Janet wrote: > >> > >> > Well, TC, the people who didn't know what they were talking about > >> were > >> > Microsoft, as I had read that in an article from Microsoft. > >> > >> Sorry, my reply was probably not very clear. You said that someone had > >> told you that "hackers can try to use the Admin user to get in the > >> database, like a backdoor entrance". I really only meant to say: "This > >> is not possible, if the database has been properly secured." Somehow, > >> that came out as: "&*$$% *&%^$# $#@# !!!" :-) > >> > >> > >> > I got the DB in a known state (again), and the permissions changed > >> again > >> > over the weekend. I have no idea of "who did what in the period > >> inbetween" > >> > which is WHY I am posting to this newsgroup. I am trying to find out > >> "what > >> > is happening" to cause my permissions to change. > >> > >> Ok, so now we have a known state, to take this further. You did not do > >> /anything/ such as adding or deleting users, or changing user > >> permissions yourself, or joining different workgroup files, in the > >> interim period - right? > >> > >> > >> > Oh well, it doesn't seem that anyone there really has any idea of > >> what to do > >> > to solve this issue, so I won't take up your time with any more of > >> this. > >> > Thanks for trying, though. :-) > >> > >> Sure we can solve it! But we need to go step by step, not changing > >> /anything/ unless that is discussed "up front". With respect, your > >> previous attempts were not a success, because you kept making changes > >> that just caused more problems. > >> > >> So, if both of us have the patience to follow this through, let's get > >> going! > >> > >> I apologise if these questions have been answered before, but I'd like > >> to get the info. afresh, not go back through all the previous posts. > >> > >> 1. Is you db split into a front-end/back end structure? > > > > YES, I have a back with data and a front with forms, queries, etc. > >> > >> 2. Is there one BE, stored on a central server? If not, what? > > There is one BE and one FE, both stored on a network drive. > >> > >> 3. Does each user of the FE have a seperate copy of the FE, on their > >> PC? If not, what? NO. There is one FE on a network drive that all users > >> have access to. I have to upgrade the db at least weekly, so it would be > >> impossible to go around and upgrade each person's desktop version since > >> there are about 80 different persons who could be using this database > >> (though usually only about 10 people are in it at one time). > >> > >> 4. Are you using a single workgroup file, stored on the central server? > >> If not, what? YES a single workgroup file stored on a central server. > >> > >> 5. Does each user start the system via a shortcut of the following form > >> (all on one line): > >> > >> "full path to msaccess.exe" > >> "full path to FE on user's PC" > >> /wrkgrk "full path to wgf on server" > >> > > NO -- Each user simply has a shortcut icon on their desktop, from > > right-clicking the front-end file, and choosing "Send to Desktop as > > Shortcut." > > > > > > 6. Do any users start the system by double-clicking a database file > >> (ie. not using a shortcut)? Probably so - thinking about my answer to #5 > >> above -- but it's a short-cut to the file, not the file itself. Does that > >> matter? > >> > >> 7. Does any user use the workgroup administrator program manually? I do, > >> and the IT Director could if she wanted (though she says she doesn't). I > >> have the FE setup to that the tools menu is not in the Startup options so > >> regular users can't click Tools, Security, Workgroup Administrator, and I > >> have the shift+enter key disabled, so they can't get to it that way. Is > >> this what you mean? > >> > >> 8. How /exactly/ are you checking what permissions a given user has? > >> IOW, how do you know /for sure/, that someone's permissions have > >> changed? I open the db, go to tools/security/permissions and look at > >> each group and what permissions are set for what > >> tables/forms/queries/macros, etc. > >> > >> > >> Janet, believe me: if you follow this through in a discipled way, I > >> have no doubt that I can fix your problem! [takes deep breath at > >> foolish commitment] --No foolish commitment here -- this is my job and I > >> want to keep it -- not by letting the db security be compromised either > >> by my ignorance malicious intent by some user or hacker. > >> > >> Note that I can only get one session on the net, per day. Please take > >> that into account, when you check for replies. > >> > >> Cheers, > >> TC > >> > > Thank you so much TC, and I will hang in here and learn what I can from > > you. > > Just so you will know, I am mostly self-taught in Access over the past 5 > > years -- have taken a couple of one-day seminars, but found I already knew > > what was being taught (and more) -- though self-learning has its > > draw--backs > > because some things are missed that are critical. Thanks again and will > > watch for your reply. > >> > > > Paul Overway wrote:
> There are a variety of hacks that will analyze an They don't have to be weak. It is not a dictionary or brute-force> MDW and crack weak passwords. crack. All user-level passwords are instantly decryptable, due to a coding error in the encryption. This could be fixed by changing the order of two parameters in the Jet sourcecode. Then, it would be computationally impossible to retrieve the plaintext passwords from a workgroup file. I have a change suggestion in to the Access team, regarding this. It would be a significant improvement to Jet security, IMHO. Cheers, TC True...although the cracks I've seen seem to choke on anything over 16
characters (the 1st 16 are correct, but not after that...). Also, throwing some high/low ascii characters in the mix seems to fluster them a little too. I really can't see why they haven't issued a SP for this issue...they could version MDWs to determine which algorithm to use (broken or more secure). I've been working on securing an app, and this hole concerns me somewhat. Show quote "TC" <aatcbbtcc***@yahoo.com> wrote in message news:1115177155.716789.211470@o13g2000cwo.googlegroups.com... > Paul Overway wrote: > >> There are a variety of hacks that will analyze an >> MDW and crack weak passwords. > > They don't have to be weak. It is not a dictionary or brute-force > crack. All user-level passwords are instantly decryptable, due to a > coding error in the encryption. This could be fixed by changing the > order of two parameters in the Jet sourcecode. Then, it would be > computationally impossible to retrieve the plaintext passwords from a > workgroup file. I have a change suggestion in to the Access team, > regarding this. It would be a significant improvement to Jet security, > IMHO. > > Cheers, > TC > Ok, I'll get back to you within 3 hours. I have to rush off for a
meeting now. Cheers, TC Janet, I have a way forward which will quickly tell us what is going
on. First, I've made some general comments in a //seperate reply//. Those comments are just for information at this stage. //Do not change anything after reading those comments!// Second, when you say that you open the db & the permissions have changed: - which db are you opening - the BE, or one of the FEs? - exactly how do you open it? Third, here is how to proceed right now. 1. Pick a table whose permissions are automagically changing. Make sure it is a BE table, not an FE link to a table. Do not use a system table - use one of your own tables. 2. Put all the permissions (on all your objects) back the way you want them to be. 3. Immediately run the code below. NOTE: replace xxxxx with the name of the table that you chose in step 1. To run the code: - open the BE db; - type Ctrl-g to go to the debug window; - cut & paste the first command; - put the cursor anywhere in that command; - press Enter to run that command; - note the output of that command, then - repeat for the other commands. Commands: debug.print dbengine.systemdb debug.print dbengine(0)(0).name debug.print currentuser() debug.print dbengine(0)(0).tabledefs![xxxxx].owner debug.print hex$(dbengine(0)(0).tabledefs![xxxxx].allpermissions) 4. Close the db, let your users continue work, and wait for the permissions to automagically change themselves. 5. Immediately repeat step 3, then 6. Post the output from steps 3. and 5. Cheers, TC Janet, further to this, I ask you not to make //any// changes to your
system, except for those that I ask you to make, as part of the process of solving your problem. Otherwise, it is just too difficult to stay on a single track. That is my requirement, for my committment to solve your problem. Cheers, TC (off for the day) TC: Thanks so much for all your help. I'll try to answer your questions
below within your text: "TC" wrote: OK.> Janet, I have a way forward which will quickly tell us what is going > on. > > First, I've made some general comments in a //seperate reply//. Those > comments are just for information at this stage. //Do not change > anything after reading those comments!// > Second, when you say that you open the db & the permissions have They changed on both BE and FE. I open each database by clicking the FE or > changed: > - which db are you opening - the BE, or one of the FEs? > - exactly how do you open it? BE mdb file. > Third, here is how to proceed right now. Actually, they were having changes in many of the tables, but I will find > > 1. Pick a table whose permissions are automagically changing. Make sure > it is a BE table, not an FE link to a table. Do not use a system table > - use one of your own tables. one that has changed, and concentrate on that one for the sake of this. Oddly enough, when I checked today, none of them have changed since I reset them on Friday (except for the MSysAccessObjects table which the Users group has full permissions -- and I left it as is for now). After I had noticed the most recent changes in the BE (last week), though, I attempted to add more security to the BE by 1) unchecking everything in the Startup Menu (except for a form that says: "Access Denied!!") and 2) I disabled the shift+enter key on BE. Maybe this has worked -- especially if, as you say, the system tends to reset the permissions for system tables to the Users group, anyway. > 2. Put all the permissions (on all your objects) back the way you want They hadn't changed (yeah!) I haven't run the code below yet since nothing > them to be. had changed. Should I do it still? Show quote > 3. Immediately run the code below. NOTE: replace xxxxx with the name of > the table that you chose in step 1. To run the code: > > - open the BE db; > - type Ctrl-g to go to the debug window; > - cut & paste the first command; > - put the cursor anywhere in that command; > - press Enter to run that command; > - note the output of that command, then > - repeat for the other commands. > > Commands: > > debug.print dbengine.systemdb > debug.print dbengine(0)(0).name > debug.print currentuser() > debug.print dbengine(0)(0).tabledefs![xxxxx].owner > debug.print hex$(dbengine(0)(0).tabledefs![xxxxx].allpermissions) > > 4. Close the db, let your users continue work, and wait for the > permissions to automagically change themselves. > > 5. Immediately repeat step 3, then > > 6. Post the output from steps 3. and 5. > > Cheers, > TC > > "Janet" <Ja***@discussions.microsoft.com> wrote in message Yes. Since TC seems to get online only once a day, you'll just delay news:EC6AE66D-707D-4A37-91B4-91004488F305@microsoft.com... > > They hadn't changed (yeah!) I haven't run the code below yet since > nothing > had changed. Should I do it still? > things. Go ahead and run the code. If/when you see a change on one of the *non-system* tables, run it again as he asked. OK -- I ran the codes and here's what I got for steps 3 thru 5:
1. it showed the correct location of the MDW file. 2. it showed the correct location of the BE file. 3. it showed my database username. 4. it gave an error message (regardless of which table name I typed in place of the xxxx): "Compile error. Method or data member not found." 5. it gave an error message (regardless of which table name I typed in place of the xxxx): "Compile error. Method or data member not found." Was it supposed to show an error message for #4 and #5? Show quote "Joan Wild" wrote: > "Janet" <Ja***@discussions.microsoft.com> wrote in message > news:EC6AE66D-707D-4A37-91B4-91004488F305@microsoft.com... > > > > They hadn't changed (yeah!) I haven't run the code below yet since > > nothing > > had changed. Should I do it still? > > > > > Yes. Since TC seems to get online only once a day, you'll just delay > things. Go ahead and run the code. If/when you see a change on one of the > *non-system* tables, run it again as he asked. > > > the xxxxxx should be in quotes
Show quote "Janet" <Ja***@discussions.microsoft.com> wrote in message news:3D808C4B-6EF8-4D46-BAE4-43848C243043@microsoft.com... > OK -- I ran the codes and here's what I got for steps 3 thru 5: > > 1. it showed the correct location of the MDW file. > 2. it showed the correct location of the BE file. > 3. it showed my database username. > 4. it gave an error message (regardless of which table name I typed in > place > of the xxxx): "Compile error. Method or data member not found." > 5. it gave an error message (regardless of which table name I typed in > place > of the xxxx): "Compile error. Method or data member not found." > > Was it supposed to show an error message for #4 and #5? > > "Joan Wild" wrote: > >> "Janet" <Ja***@discussions.microsoft.com> wrote in message >> news:EC6AE66D-707D-4A37-91B4-91004488F305@microsoft.com... >> > >> > They hadn't changed (yeah!) I haven't run the code below yet since >> > nothing >> > had changed. Should I do it still? >> > >> >> >> Yes. Since TC seems to get online only once a day, you'll just delay >> things. Go ahead and run the code. If/when you see a change on one of >> the >> *non-system* tables, run it again as he asked. >> >> >> "Janet" <Ja***@discussions.microsoft.com> wrote in message debug.print dbengine(0)(0).Containers("tables").documents("xxxx").ownernews:3D808C4B-6EF8-4D46-BAE4-43848C243043@microsoft.com... > > 1. it showed the correct location of the MDW file. > 2. it showed the correct location of the BE file. > 3. it showed my database username. > 4. it gave an error message (regardless of which table name I typed in > place > of the xxxx): "Compile error. Method or data member not found." > 5. it gave an error message (regardless of which table name I typed in > place > of the xxxx): "Compile error. Method or data member not found." debug.print hex$(dbengine(0)(0).containers("tables").documents("xxxx").allpermissions) -- Joan Wild Microsoft Access MVP Good catch! :o)
Show quote "Joan Wild" <jwild@nospamtyenet.com> wrote in message news:%23Tgp4mOUFHA.3952@TK2MSFTNGP15.phx.gbl... > "Janet" <Ja***@discussions.microsoft.com> wrote in message > news:3D808C4B-6EF8-4D46-BAE4-43848C243043@microsoft.com... >> >> 1. it showed the correct location of the MDW file. >> 2. it showed the correct location of the BE file. >> 3. it showed my database username. >> 4. it gave an error message (regardless of which table name I typed in >> place >> of the xxxx): "Compile error. Method or data member not found." >> 5. it gave an error message (regardless of which table name I typed in >> place >> of the xxxx): "Compile error. Method or data member not found." > > > debug.print dbengine(0)(0).Containers("tables").documents("xxxx").owner > debug.print > hex$(dbengine(0)(0).containers("tables").documents("xxxx").allpermissions) > > > -- > Joan Wild > Microsoft Access MVP > I'm not sure what to enter in this code? Put the table name where you have
"Tables" and "xxxxx" ??? Show quote "Joan Wild" wrote: > "Janet" <Ja***@discussions.microsoft.com> wrote in message > news:3D808C4B-6EF8-4D46-BAE4-43848C243043@microsoft.com... > > > > 1. it showed the correct location of the MDW file. > > 2. it showed the correct location of the BE file. > > 3. it showed my database username. > > 4. it gave an error message (regardless of which table name I typed in > > place > > of the xxxx): "Compile error. Method or data member not found." > > 5. it gave an error message (regardless of which table name I typed in > > place > > of the xxxx): "Compile error. Method or data member not found." > > > debug.print dbengine(0)(0).Containers("tables").documents("xxxx").owner > debug.print > hex$(dbengine(0)(0).containers("tables").documents("xxxx").allpermissions) > > > -- > Joan Wild > Microsoft Access MVP > > > Just replace the xxxx with the name of a table....leave the rest the same
Show quote "Janet" <Ja***@discussions.microsoft.com> wrote in message news:1CB2158B-8FE9-466E-B63C-29EDBD090B06@microsoft.com... > I'm not sure what to enter in this code? Put the table name where you > have > "Tables" and "xxxxx" ??? > > "Joan Wild" wrote: > >> "Janet" <Ja***@discussions.microsoft.com> wrote in message >> news:3D808C4B-6EF8-4D46-BAE4-43848C243043@microsoft.com... >> > >> > 1. it showed the correct location of the MDW file. >> > 2. it showed the correct location of the BE file. >> > 3. it showed my database username. >> > 4. it gave an error message (regardless of which table name I typed in >> > place >> > of the xxxx): "Compile error. Method or data member not found." >> > 5. it gave an error message (regardless of which table name I typed in >> > place >> > of the xxxx): "Compile error. Method or data member not found." >> >> >> debug.print >> dbengine(0)(0).Containers("tables").documents("xxxx").owner >> debug.print >> hex$(dbengine(0)(0).containers("tables").documents("xxxx").allpermissions) >> >> >> -- >> Joan Wild >> Microsoft Access MVP >> >> >> Yes, thanks for that. Unfortunately I do not have Access on the pc that
I use to post to the web, so I have to do all code from memory! Cheers, TC Actually....I take that back.... but try this instead...
debug.print dbengine(0)(0).tabledefs("SomeTable").Owner debug.print hex$(dbengine(0)(0).tabledefs("SomeTable").AllPermissions) Show quote "Janet" <Ja***@discussions.microsoft.com> wrote in message news:3D808C4B-6EF8-4D46-BAE4-43848C243043@microsoft.com... > OK -- I ran the codes and here's what I got for steps 3 thru 5: > > 1. it showed the correct location of the MDW file. > 2. it showed the correct location of the BE file. > 3. it showed my database username. > 4. it gave an error message (regardless of which table name I typed in > place > of the xxxx): "Compile error. Method or data member not found." > 5. it gave an error message (regardless of which table name I typed in > place > of the xxxx): "Compile error. Method or data member not found." > > Was it supposed to show an error message for #4 and #5? > > "Joan Wild" wrote: > >> "Janet" <Ja***@discussions.microsoft.com> wrote in message >> news:EC6AE66D-707D-4A37-91B4-91004488F305@microsoft.com... >> > >> > They hadn't changed (yeah!) I haven't run the code below yet since >> > nothing >> > had changed. Should I do it still? >> > >> >> >> Yes. Since TC seems to get online only once a day, you'll just delay >> things. Go ahead and run the code. If/when you see a change on one of >> the >> *non-system* tables, run it again as he asked. >> >> >> I tried the code you have below, but got the same error message. I must be
doing something wrong.... I have to go home now and will be back here tomorrow. Show quote "Paul Overway" wrote: > Actually....I take that back.... but try this instead... > > debug.print dbengine(0)(0).tabledefs("SomeTable").Owner > debug.print hex$(dbengine(0)(0).tabledefs("SomeTable").AllPermissions) > > > -- > Paul Overway > Logico Solutions > http://www.logico-solutions.com > > > "Janet" <Ja***@discussions.microsoft.com> wrote in message > news:3D808C4B-6EF8-4D46-BAE4-43848C243043@microsoft.com... > > OK -- I ran the codes and here's what I got for steps 3 thru 5: > > > > 1. it showed the correct location of the MDW file. > > 2. it showed the correct location of the BE file. > > 3. it showed my database username. > > 4. it gave an error message (regardless of which table name I typed in > > place > > of the xxxx): "Compile error. Method or data member not found." > > 5. it gave an error message (regardless of which table name I typed in > > place > > of the xxxx): "Compile error. Method or data member not found." > > > > Was it supposed to show an error message for #4 and #5? > > > > "Joan Wild" wrote: > > > >> "Janet" <Ja***@discussions.microsoft.com> wrote in message > >> news:EC6AE66D-707D-4A37-91B4-91004488F305@microsoft.com... > >> > > >> > They hadn't changed (yeah!) I haven't run the code below yet since > >> > nothing > >> > had changed. Should I do it still? > >> > > >> > >> > >> Yes. Since TC seems to get online only once a day, you'll just delay > >> things. Go ahead and run the code. If/when you see a change on one of > >> the > >> *non-system* tables, run it again as he asked. > >> > >> > >> > > > blah![xxx] and blah("xxx") are normally equivalent in those contexts
:-) Cheers,TC debug.print dbengine.systemdb
F:\shared\Share.mdw debug.print dbengine(0)(0).name G:\CIS\CIS-BACK.mdb debug.print currentuser() superuser debug.print dbengine(0)(0).Containers("tables").documents("client").owner SuperUser debug.print hex$(dbengine(0)(0).containers("tables").documents("client").allpermissions) FFEFF Show quote "TC" wrote: > Janet, further to this, you need to show the actual result of each > command. > > TC > > Correct. When we compare the two runs, I expect that we will see a
difference in what database, workgroup file, user, or object, she is using to compare permissions. Cheers, TC Janet wrote:
(snip) > After I had noticed Janet, I truly can't help you, if you keep making changes. I made that> the most recent changes in the BE (last week), though, I attempted to add > more security to the BE by 1) unchecking everything in the Startup Menu > (except for a form that says: "Access Denied!!") and 2) I disabled the > shift+enter key on BE. very clear in my previous posts. Debugging requires a disciplined, step-by-step approach. If you want me to help you, you must accept my approach - which in this case means, //no more changes// unless we have discussed them //first//. Do you agree to that approach? TC TC - I had already done that prior to your helping me, but forgot to mention
it. Sorry. I haven't made any changes at all since working with you. Show quote "TC" wrote: > > Janet wrote: > > (snip) > > > After I had noticed > > the most recent changes in the BE (last week), though, I attempted to > add > > more security to the BE by 1) unchecking everything in the Startup > Menu > > (except for a form that says: "Access Denied!!") and 2) I disabled > the > > shift+enter key on BE. > > Janet, I truly can't help you, if you keep making changes. I made that > very clear in my previous posts. > > Debugging requires a disciplined, step-by-step approach. If you want me > to help you, you must accept my approach - which in this case means, > //no more changes// unless we have discussed them //first//. > > Do you agree to that approach? > > TC > > Ok, sorry, I completely misread what you said :-(
As soon as you see that some table permissions have unexpectedly changed, please post the before & after results of the (corrected!) code that I gave you before. Then we'll soon see what is going on. Be sure to cut & paste the exact text of each command's output. Pick one of your own tables for this - do not use a system table. Cheers :-) TC OK I will :-) Thanks so much.
Show quote "TC" wrote: > Ok, sorry, I completely misread what you said :-( > > As soon as you see that some table permissions have unexpectedly > changed, please post the before & after results of the (corrected!) > code that I gave you before. Then we'll soon see what is going on. Be > sure to cut & paste the exact text of each command's output. Pick one > of your own tables for this - do not use a system table. > > Cheers :-) > TC > > Janet, I have a way forward which will quickly tell us what is going
on. That is in a seperate reply. This reply is some general information for you to consider in due course. //Do not change anything, yet, in response to these comments!// > > 1. Is you db split into a front-end/back end structure? Ok.> YES, I have a back with data and a front with forms, queries, etc. > > 2. Is there one BE, stored on a central server? If not, what? See below.> There is one BE and one FE, both stored on a network drive. > > 3. Does each user of the FE have a seperate copy of the FE, on to. I have totheir > > PC? If not, what? > NO. There is one FE on a network drive that all users have access > upgrade the db at least weekly, so it would be impossible to go around and upgrade> each person's desktop version since there are about 80 different persons who could> be using this database (though usually only about 10 people are in it at one time).Having a single FE is generally thought to increase the chances of database corruption. It is true that having an FE per user gives rise to an administrative problem, but there are various ways of handling that. For example, there are "auto updater" modules that cause the FE to automatically update itself, from a new version on the server, whenever required. I recommend that you address this issue in due course - but //not yet//, since it is unlikely to be the cause of your current problem. So, //do not// change this yet. > > 4. Are you using a single workgroup file, stored on the central Ok.server? > > If not, what? > YES a single workgroup file stored on a central server. > > 5. Does each user start the system via a shortcut of the following Mmmm. If you double-click the FE - or a simple shortcut to the FE -form > > (all on one line): > > > > "full path to msaccess.exe" > > "full path to FE on user's PC" > > /wrkgrk "full path to wgf on server" > NO -- Each user simply has a shortcut icon on their desktop, from > right-clicking the front-end file, and choosing "Send to Desktop as > Shortcut." this will use whatever workgroup file was last joined-to, on that PC. By default - when Access is first installed, that file will be, the default workgroup file on that PC. So, if the database is actually opening (as it clearly is), one of two things must be true: (a) You have used the workgroup administrator, on each PC, to join each PC to the correct workgroup file on the server; or, (b) The database will open with the PC's normal (default) workgroup file. (This is common, & means that the database has not been properly secured.) I assume it is (a) - correct? If so, that is not the normal way to do it, because that will cause the server's workgroup file to be used for /every/ database on the PC - even ones that aren't secured. Those local, unsecured databases should normally use the PC's initial, default workgroup file. Usually, you would use the shortcut described in 5, to open a secured database. The shortcut uses the /wrkgrp switch to select the server workgroup file /for that run only/. Then, you can leave each PC joined to its normal (default) workgroup file, for running other (unsecured) databases. //Do not change this yet.// Leave it as it is, until we work out what is causing your problem. > 6. Do any users start the system by double-clicking a database file See 5. //Do not change this yet.//> > (ie. not using a shortcut)? > Probably so - thinking about my answer to #5 above -- but it's a short-cut > to the file, not the file itself. Does that matter? > > 7. Does any user use the workgroup administrator program manually? Mmmm. Do you mean that you used the workgroup administrator program> I do, and the IT Director could if she wanted (though she says she doesn't). > I have the FE setup to that the tools menu is not in the Startup options so > regular users can't click Tools, Security, Workgroup Administrator, and I > have the shift+enter key disabled, so they can't get to it that way. > Is this what you mean? /once/, on each PC, to join that PC to the workgroup file on the server? Or do you use it repeatedly? If so, why? > > 8. How /exactly/ are you checking what permissions a given user I've addressed this in my other reply.has? > > IOW, how do you know /for sure/, that someone's permissions have > > changed? > I open the db, go to tools/security/permissions and look at each group > and what permissions are set for what tables/forms/queries/macros, etc. > During the interim (this past weekend) the "User Group" permissions You'll get nowhere looking at system table permissions. The underlyingwere > changed again on both front end and back ends to include ALL permissions for > MSysAccessObjects system table. (snip) database engine (MS Jet) has certain requirements of the system tables. It will re-apply those requirements, automagically, in certain cases, if you try to change them. //Do not// fiddle with the system tables! That will only lead to grief & confusion. Cheers, TC "TC" <aatcbbtcc***@yahoo.com> wrote in message TC, that is the main point that I think you are missing. The only table news:1115195090.540034.52930@z14g2000cwz.googlegroups.com... > > You'll get nowhere looking at system table permissions. The underlying > database engine (MS Jet) has certain requirements of the system tables. > It will re-apply those requirements, automagically, in certain cases, > if you try to change them. //Do not// fiddle with the system tables! that Janet has reported the permissions keep changing on is a system table. -- Joan Wild Microsoft Access MVP That is the most obvious table they are changing in. I have seen them change
in other tables, as well. I'm going to check, again, today to see if permissions in the other tables have been changed. My biggest concern was the system table because it seemed to change everything to FULL permissions -- but there have also been changes in other tables, as well. I'll let you know what I find. Show quote "Joan Wild" wrote: > "TC" <aatcbbtcc***@yahoo.com> wrote in message > news:1115195090.540034.52930@z14g2000cwz.googlegroups.com... > > > > You'll get nowhere looking at system table permissions. The underlying > > database engine (MS Jet) has certain requirements of the system tables. > > It will re-apply those requirements, automagically, in certain cases, > > if you try to change them. //Do not// fiddle with the system tables! > > > TC, that is the main point that I think you are missing. The only table > that Janet has reported the permissions keep changing on is a system table. > > -- > Joan Wild > Microsoft Access MVP > > > Gak!!! I did miss that! But her reply suggests that other tables are
changing as well. As you, I, & everyone else has said, there is no point messing with the system tables, or trying to divine what their permissions mean. Cheers, TC
Show quote
"TC" wrote: OK> Janet, I have a way forward which will quickly tell us what is going > on. > > That is in a seperate reply. This reply is some general information for > you to consider in due course. //Do not change anything, yet, in > response to these comments!// > > > > > 1. Is you db split into a front-end/back end structure? > > > YES, I have a back with data and a front with forms, queries, etc. > > Ok. > > > > > 2. Is there one BE, stored on a central server? If not, what? > > > There is one BE and one FE, both stored on a network drive. > > See below. > > > > > 3. Does each user of the FE have a seperate copy of the FE, on > their > > > PC? If not, what? > > > NO. There is one FE on a network drive that all users have access > to. I have to > > upgrade the db at least weekly, so it would be impossible to go > around and upgrade > > each person's desktop version since there are about 80 different > persons who could > > be using this database (though usually only about 10 people are in it > at one time). > > Having a single FE is generally thought to increase the chances of > database corruption. It is true that having an FE per user gives rise > to an administrative problem, but there are various ways of handling > that. For example, there are "auto updater" modules that cause the FE > to automatically update itself, from a new version on the server, > whenever required. I recommend that you address this issue in due > course - but //not yet//, since it is unlikely to be the cause of your > current problem. So, //do not// change this yet. Show quote > > > 4. Are you using a single workgroup file, stored on the central I used the Workgroup Administrator once on each computer to join it to the > server? > > > If not, what? > > > YES a single workgroup file stored on a central server. > > Ok. > > > > > 5. Does each user start the system via a shortcut of the following > form > > > (all on one line): > > > > > > "full path to msaccess.exe" > > > "full path to FE on user's PC" > > > /wrkgrk "full path to wgf on server" > > > NO -- Each user simply has a shortcut icon on their desktop, from > > right-clicking the front-end file, and choosing "Send to Desktop as > > Shortcut." > > Mmmm. If you double-click the FE - or a simple shortcut to the FE - > this will use whatever workgroup file was last joined-to, on that PC. > By default - when Access is first installed, that file will be, the > default workgroup file on that PC. So, if the database is actually > opening (as it clearly is), one of two things must be true: > > (a) You have used the workgroup administrator, on each PC, to join each > PC to the correct workgroup file on the server; or, > > (b) The database will open with the PC's normal (default) workgroup > file. (This is common, & means that the database has not been properly > secured.) > > I assume it is (a) - correct? YES THIS IS CORRECT If so, that is not the normal way to do > it, because that will cause the server's workgroup file to be used for > /every/ database on the PC - even ones that aren't secured. Those > local, unsecured databases should normally use the PC's initial, > default workgroup file. > > Usually, you would use the shortcut described in 5, to open a secured > database. The shortcut uses the /wrkgrp switch to select the server > workgroup file /for that run only/. Then, you can leave each PC joined > to its normal (default) workgroup file, for running other (unsecured) > databases. > > //Do not change this yet.// Leave it as it is, until we work out what > is causing your problem. > > > > 6. Do any users start the system by double-clicking a database file > > > (ie. not using a shortcut)? > > > Probably so - thinking about my answer to #5 above -- but it's a > short-cut > > to the file, not the file itself. Does that matter? > > See 5. //Do not change this yet.// > > > > > 7. Does any user use the workgroup administrator program manually? > > > I do, and the IT Director could if she wanted (though she says she > doesn't). > > I have the FE setup to that the tools menu is not in the Startup > options so > > regular users can't click Tools, Security, Workgroup Administrator, > and I > > have the shift+enter key disabled, so they can't get to it that way. > > Is this what you mean? > > Mmmm. Do you mean that you used the workgroup administrator program > /once/, on each PC, to join that PC to the workgroup file on the > server? Or do you use it repeatedly? If so, why? MDW file associated with this database. However -- there are times when I have to "redo" this on a few computers because somehow it magically defaulted back to the system.mdw file -- then I get a call from the user that the database won't open. No one seems to know how the computer was taken back to the system.mdw. It's only happened a few times, and not lately. Show quote > > > 8. How /exactly/ are you checking what permissions a given user > has? > > > IOW, how do you know /for sure/, that someone's permissions have > > > changed? > > > I open the db, go to tools/security/permissions and look at each > group > > and what permissions are set for what tables/forms/queries/macros, > etc. > > I've addressed this in my other reply. > > > > > During the interim (this past weekend) the "User Group" permissions > were > > changed again on both front end and back ends to include ALL > permissions for > > MSysAccessObjects system table. (snip) > > You'll get nowhere looking at system table permissions. The underlying > database engine (MS Jet) has certain requirements of the system tables. > It will re-apply those requirements, automagically, in certain cases, > if you try to change them. //Do not// fiddle with the system tables! > That will only lead to grief & confusion. > > Cheers, > TC > > Next time that happens, and you start the workgroup administrator
program to correct it, please record exactly what the workgroup administrator is displaying as the "current" workgroup file - ie. /before/ you rejoin the correct file - then post that info. here. Cheers, TC OK I'll do that. I will say that each time this has happened, I did notice
that the workgroup admin was displaying the original, default system.mdw file joined. Show quote "TC" wrote: > Next time that happens, and you start the workgroup administrator > program to correct it, please record exactly what the workgroup > administrator is displaying as the "current" workgroup file - ie. > /before/ you rejoin the correct file - then post that info. here. > > Cheers, > TC > > I've waited for others to respond, but now I'll add some more thoughts:
Janet wrote: > About a year ago, I set up User Level Security per some step-by-step If that is the order you did things in, then it is quite possible that it > instructions I found from the internet. I set up different groups > with different permission levels, and assigned each user (we have > about 90 users) to the appropriate group. I then removed the Admin > user from the Admins group, placed Admin in the Users group, assigned > a password to the Admin user, as well. I then eliminated all > permissions from the Users group. isn't secured properly, and someone is able to use it with the standard system.mdw, and also possible they can change permissions. > Kinda looked like someone deleted records, If you had set referential integrity on the relationship, then it would be > then deleted any evidence the records were there. BUT, the evidence > that the records was there because there was still related data in > other tables, once connected to the client id that had been deleted. impossible to orphan records like this. > the database directly, but instead she got an error message saying That is a sign of corruption. See this thread> something like she didn't have design permissions for > MSysAccessObjects -- and she could not get in. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=eosdnu44bqj592i1kds26kck6m6f9nleop%404ax.com--Joan WildMicrosoft Access MVP As posted in the thread (at least by my newsreader) Joan's link
will have problems. Use this short link to take you to the thread Joan was talking about: http://tinyurl.com/45knb -- Show quoteJeff Conrad Access Junkie Bend, Oregon "Joan Wild" wrote in message: news:uCsZsANTFHA.2520@TK2MSFTNGP09.phx.gbl... http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=eosdnu44bqj592i1kds26kck6m6f9nleop%404ax.com--Joan WildMicrosoft Access MVP> I've waited for others to respond, but now I'll add some more thoughts: > > Janet wrote: > > About a year ago, I set up User Level Security per some step-by-step > > instructions I found from the internet. I set up different groups > > with different permission levels, and assigned each user (we have > > about 90 users) to the appropriate group. I then removed the Admin > > user from the Admins group, placed Admin in the Users group, assigned > > a password to the Admin user, as well. I then eliminated all > > permissions from the Users group. > > If that is the order you did things in, then it is quite possible that it > isn't secured properly, and someone is able to use it with the standard > system.mdw, and also possible they can change permissions. > > > Kinda looked like someone deleted records, > > then deleted any evidence the records were there. BUT, the evidence > > that the records was there because there was still related data in > > other tables, once connected to the client id that had been deleted. > > If you had set referential integrity on the relationship, then it would be > impossible to orphan records like this. > > > the database directly, but instead she got an error message saying > > something like she didn't have design permissions for > > MSysAccessObjects -- and she could not get in. > > That is a sign of corruption. See this thread > > Show quote > Jeff Conrad wrote:
> As posted in the thread (at least by my newsreader) Joan's link Thanks Jeff; something screwy about my signature. I'll try again:> will have problems. Use this short link to take you to the thread > Joan was talking about: > > http://tinyurl.com/45knb http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=eosdnu44bqj592i1kds26kck6m6f9nleop%404ax.com--Joan WildMicrosoft Access MVP "Joan Wild" wrote in message:
news:extCR3OTFHA.2424@TK2MSFTNGP09.phx.gbl... I figured.> Thanks Jeff; something screwy about my signature. I'll try again: > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=eosdnu44bqj592i1kds26kck6m6f9nleop%404ax.com--JoanWildMicrosoft Access MVP And same result. Show quote :-) -- Jeff Conrad Access Junkie Bend, Oregon Jeff Conrad wrote:
> Anyone understand this? I'm hitting enter a couple of times after the URL.> And same result. > :-) http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=eosdnu44bqj592i1kds26kck6m6f9nleop%404ax.com.Stilltrying(I've saved as draft and it keeps doingthis)--JoanWildMicrosoftAccess MVP "Joan Wild" wrote in message:
news:uxeWwrPTFHA.1152@tk2msftngp13.phx.gbl... Does it happen if you press Enter several times before the sig, back> Anyone understand this? I'm hitting enter a couple of times after the URL. up a couple of lines, and then paste the link? Or are you pasting the link, hitting Enter a couple of times, and then going to Insert | Signature? -- Jeff Conrad Access Junkie Bend, Oregon Jeff Conrad wrote:
> I've tried both and the same thing happens. I don't use Insert|Sig; it's> Does it happen if you press Enter several times before the sig, back > up a couple of lines, and then paste the link? > > Or are you pasting the link, hitting Enter a couple of times, and then > going to Insert | Signature? automatically inserted when I start a reply. -- Joan Wild Microsoft Access MVP "Joan Wild" wrote in message:
news:egZ3z7PTFHA.3012@TK2MSFTNGP14.phx.gbl... Weird, I cannot seem to reproduce this.> I've tried both and the same thing happens. However, I do not actually hit "Send" in my tests. >I don't use Insert|Sig; it's automatically inserted when I start a reply. I did not think so, but it just crossed my mind as a possibility.Strange. -- Jeff Conrad Access Junkie Bend, Oregon  |
|||||||||||||||||||||||
Other interesting topics