 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Security / March 2005Help!!
I don't know what I did, but I skrewed something up. This is what I think I did. I have a test database (a copy of our live data) on my hard drive. I've been working at adding groups and users to that table and got everything set up almost the way I wanted. I then got sidetracked into testing how best to implement the security into the live data. There was a copy of the database in the same folder as the live data, and I used that one to test joining the workgroup file to see how that would work. Once I did that, the live data also joined the workgroup file. I think I understand why it did that on my system, but when that happened, other users on their machines started getting permissions errors. One of the systems that had problems didn't have wrkadmin.exe on their machine, and I could not find a system.mdw, so I copied my system.mdw into the folder on the network and then from my machine joined that workgroup file. But then when I went to open the data from my machine while that user is logged in, I can't. I think I understand why, we're both using the same login Admin and the same workgroup file (I think). I need to set it back the way it was. I think I need to rejoin the default access workgroup system.mdw on my machine, but I don't want to mess things up any further. I know I messed up, so please don't ream me...just help me fix it. Thanks If you did manage to implement User Level Security, here's a link that will show you how to "desecure" your database: http://support.microsoft.com/default.aspx?scid=%2Fsupport%2Faccess%2Fcontent%2Fs ecfaq.asp#_Toc493299668 Topic #34 is a good place to start ... >I don't know what I did, but I skrewed something up. > [quoted text clipped - 20 lines] > > Thanks I did the steps below that I explained. I'm not sure if USL is not set up. I don't know if it somehow got partially set up when I did what I explained below, but here are the symptoms right now... Every user seems to be able to get into the database without problem with two exceptions. Each one of those users that can get into the system show record locking on the database file (the file that gets temporarily created when someone has the system running). When the specific user gets in that was having permission errors after my original mistake gets in the system.mdw also shows record locking, indicating that that workgroup is being used when she logs in. When I log in the same thing happens, indicating that I am also using that system.mdw file. Everyone esle seems to be using there own local system.mdw when they log in (however I don't have visual confirmation) When both she and I try to log in at the same time we can't because appearently since we are both using the same system.mdw and both trying to log in as Admin (this is the original system.mdw from my system that was copied to the network to try to solve the permissions problem that the user was having because she didn't have a system.mdw on her own machine.) we cannot because one of us is already logged in using that user id. I just want to know before I skrew anything else up, if I rejoing my local system.mdw is it going to cause permission problems for the other user, and I it is how am I going to resolve the issue of both of us being able to log in at the same time until I am ready to actually implement the USL that I am working right now. I have looked at number 34 of the security document and it doesn't seem to apply because Admin already has administrator rights. > If you did manage to implement User Level Security, here's a link that > will show you how to "desecure" your database: [quoted text clipped - 26 lines] >> >> Thanks Perhaps a little understanding about workgroups and permissions might help you help us to understand. Every session of Access uses security. Out of the box, it ships with a workgroup called system.mdw. When you start Access, it uses this workgroup and silently logs you in as a user called 'Admin'. This system.mdw workgroup is set as your default for all sessions. When you implement security, the first step is to create a new workgroup file. During this process, Access will make this new workgroup the default for all sessions. There must always be some workgroup that is the default. The default can be ignored only by creating a desktop shortcut that uses the /wrkgrp switch to point to a different mdw to use *for that session* of Access. The workgroup file contains usernames, groups, memberships, passwords. Permissions though, are stored *in the mdb file*. It is possible to use many workgroup files with one database, and also many databases can use one workgroup file. The fact that people are able to get in using the their standard system.mdw suggests that it isn't secure. You can determine the mdw file *in use* by hitting Ctrl-G and typing ?dbEngine.systemDB You should use the workgroup administrator to join your secure mdw and remove security. > Every user seems to be able to get into the database without problem > with two exceptions. Each one of those users that can get into the [quoted text clipped - 25 lines] >> If you did manage to implement User Level Security, here's a link >> that will show you how to "desecure" your database: http://support.microsoft.com/default.aspx?scid=%2Fsupport%2Faccess%2Fcontent%2Fs ecfaq.asp#_Toc493299668 >> Topic #34 is a good place to start ... >>> I don't know what I did, but I skrewed something up. [quoted text clipped - 22 lines] >>> >>> Thanks  SignatureJoan Wild Microsoft Access MVP Please see inline responses. > Perhaps a little understanding about workgroups and permissions might help > you help us to understand. Every session of Access uses security. Out of > the box, it ships with a workgroup called system.mdw. When you start > Access, it uses this workgroup and silently logs you in as a user called > 'Admin'. I understand this... > This system.mdw workgroup is set as your default for all sessions. When > you [quoted text clipped - 5 lines] > /wrkgrp switch to point to a different mdw to use *for that session* of > Access. Then why is there no copy of system.mdw or *any* mdw on the machine in question. the target of the shortcut to the database on that machine looks like this \\ServerName\ShareFolder\ProgramName.mdb which would assume the system.mdw I would guess, but there is no system.mdw on this person's machine. That's why I copied my system.mdw from my machine to the folder where the data was. Now she is using that system.mdw which does make sense since it is not explicity named in the target it takes the first one it finds which would be in the shared folder. > The workgroup file contains usernames, groups, memberships, passwords. > Permissions though, are stored *in the mdb file*. It is possible to use > many workgroup files with one database, and also many databases can use > one > workgroup file. I understand this as well. > The fact that people are able to get in using the their standard > system.mdw > suggests that it isn't secure. You can determine the mdw file *in use* by > hitting Ctrl-G and typing ?dbEngine.systemDB Thanks, this is helpful. > You should use the workgroup administrator to join your secure mdw and > remove security. This is what I thought, but didn't want to do cause further hassles to the other user. Thanks, I'll just do this until I'm ready to implement the security I'm working on in the copy on my local drive. I have it all worked out. I'm in the testing phase with all the users to make sure everything works as expected prior to implementing. >> Every user seems to be able to get into the database without problem >> with two exceptions. Each one of those users that can get into the [quoted text clipped - 54 lines] >>>> >>>> Thanks also... If I rejoin the system.mdw on my local machine, should I delete the system.mdw on the server machine... keeping in mind that the other machine does not have a copy of system.mdw on it, or will that cause the problems originally created when this all started in the first place? > Please see inline responses. > [quoted text clipped - 112 lines] >>>>> >>>>> Thanks > also... > If I rejoin the system.mdw on my local machine, should I delete the > system.mdw on the server machine... keeping in mind that the other > machine does not have a copy of system.mdw on it, or will that cause > the problems originally created when this all started in the first > place? If that machine has Access installed, then there is a system.mdw file on it. Your search via Start, Search may not find it if folders are hidden. Perhaps the user you are logged in as doesn't have permission to view the folder where the file is. Open Access on that machine and use dbengine.systemdb to get the path of its default workgroup. Normally (but not always) system.mdw is found in the windows system folder. Your server should not have a system.mdw (unless this is the secure one you created? - you should really give it a different name if so). Why don't you rename it rather than delete it, just in case. more inline... >> Then why is there no copy of system.mdw or *any* mdw on the machine >> in question. the target of the shortcut to the database on that >> machine looks like this >> \\ServerName\ShareFolder\ProgramName.mdb which would assume the >> system.mdw I would guess, but there is no system.mdw on this >> person's machine. It's there somewhere. >> That's why I copied my system.mdw from my machine >> to the folder where the data was. Now she is using that system.mdw How do you know she is using this one? >> This is what I thought, but didn't want to do cause further hassles >> to the other user. >> Thanks, I'll just do this until I'm ready to implement the security >> I'm working on in the copy on my local drive. I have it all worked >> out. I'm in the testing phase with all the users to make sure >> everything works as expected prior to implementing. The thing is that you may have tested things on a copy, but the new workgroup became your default one. If you subsequently opened the live database, you would be doing so using your secure.mdw, not the standard mdw and you may have changed permissions on it. SignatureJoan Wild Microsoft Access MVP This is a windows98 system, I did do the search via start, I included all files/folders (hidden as well) on c:\ which is the only local drive there is no system.mdw... it is possible that somewhere on the nework in her path there is a system.mdw, but I havn't had a chance to check that out yet. >> also... >> If I rejoin the system.mdw on my local machine, should I delete the [quoted text clipped - 45 lines] > mdw > and you may have changed permissions on it. > This is a windows98 system, I did do the search via start, I included > all files/folders (hidden as well) on c:\ which is the only local > drive there is no system.mdw... it is possible that somewhere on the > nework in her path there is a system.mdw, but I havn't had a chance > to check that out yet. Open Access on that machine and use dbengine.systemdb to get the path of its default workgroup. Is Access really installed on the machine, or the runtime? SignatureJoan Wild Microsoft Access MVP I stand corrected... the problem was not that she didn't have a system.mdw, she had 3 of them. The problem was that she didn't have the option for workgroup admin on the menu nor did she have wrkgadmin.exe on her system. Also, she has the security wizard option on the menu, but when it is clicked on, she gets a message that the wizard is not installed. I think I have everything worked out though, since I will be using a shortcut to the .mdw file when I implement. She doesn't need the wizard, or wrkgadmin. Thanks for your help, when I get a chance I will re-install access on her machine to make sure everything that should be installed is. But for now I think I'm ok. >> also... >> If I rejoin the system.mdw on my local machine, should I delete the [quoted text clipped - 45 lines] > mdw > and you may have changed permissions on it. > I stand corrected... the problem was not that she didn't have a > system.mdw, she had 3 of them. The problem was that she didn't have [quoted text clipped - 7 lines] > machine to make sure everything that should be installed is. But for > now I think I'm ok. Good. If it's version 97 or 2000 you would look for wrkgadm.exe not wrkgadmin.exe. For later versions the administrator is in the Tools, security menu. SignatureJoan Wild Microsoft Access MVP thanks for all your help >> I stand corrected... the problem was not that she didn't have a >> system.mdw, she had 3 of them. The problem was that she didn't have [quoted text clipped - 11 lines] > wrkgadmin.exe. For later versions the administrator is in the Tools, > security menu. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.