I have a mdb file that resides on a Novell server. I have 3 people with write privileges and the rest of the company has read access for them to run 'canned' queries. The users with read rights can access the DB if no one with write access has the file open. The user with read access can not access the DB if a user with write access has the DB open yet more than one user with write access can have the DB open at the same time. The Novell administrator said the Network is set up correctly and my problem is with the security setup in Access. Can anyone tell me how to set it up so that users with read rights can access the DB at the same time as users with write rights?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Security 3
- Thread starter MGR
- Start date
-
1
- #2
Access creates a .ldb file whenever a database is opened – even if it is opened for inquiry only. Therefore, attempting to protect the database via Novell read-only privileges will not work. Access NEEDS to have write privileges to the disk so it can create the .ldb file.<br>
<br>
One option is to utilize Access’s security features. My OPINION is that Access is a poor tool when it comes to security (I’m open to feedback).<br>
<br>
I always ask the following questions when it comes to securing an Access database: what are your reasons for securing it? What do you want to protect yourself against? Is the data truly sensitive? Are you worried about malicious misuse of the data? Accidental corruption or misuse? <br>
<br>
If the data is truly sensitive or you are worried about malicious use/misuse – consider using another product. If you simply want to hide data or protect against accidental corruption (and you are not worried about hackers) you can design a system that “appears” to be read-only. For example create a separate front-end that has read-only views of the data. Smart users can always hack their way into the back-end but if you trust them this should not be an issue.<br>
<br>
One option is to utilize Access’s security features. My OPINION is that Access is a poor tool when it comes to security (I’m open to feedback).<br>
<br>
I always ask the following questions when it comes to securing an Access database: what are your reasons for securing it? What do you want to protect yourself against? Is the data truly sensitive? Are you worried about malicious misuse of the data? Accidental corruption or misuse? <br>
<br>
If the data is truly sensitive or you are worried about malicious use/misuse – consider using another product. If you simply want to hide data or protect against accidental corruption (and you are not worried about hackers) you can design a system that “appears” to be read-only. For example create a separate front-end that has read-only views of the data. Smart users can always hack their way into the back-end but if you trust them this should not be an issue.<br>
- Thread starter
- #3
Thanks for your help! I'm basically concerned about individuals inadvertently corrupting data. I think I'm going to try and use a database password for now. I'll spend some time trying to set up user-level security in the future.<br>
<br>
I read in an Access book that I should create 2 .mdb files, one for the 'working' data tables that I want to let a limited number of users have write privileges and another for forms, queries and report that I want most people to have read-only privileges. What do you think of this suggestion?<br>
<br>
I read in an Access book that I should create 2 .mdb files, one for the 'working' data tables that I want to let a limited number of users have write privileges and another for forms, queries and report that I want most people to have read-only privileges. What do you think of this suggestion?<br>
-
1
- #4
I agree with Lehtoant.<br>
<br>
If you use a database password, make sure you set it before you split the database. Don't forget the password - I'm not aware of a means of retrieving it if it gets lost.<br>
<br>
Access has a utility to split the database. See Tools / Add-Ins / Database Splitter<br>
<br>
<br>
If you use a database password, make sure you set it before you split the database. Don't forget the password - I'm not aware of a means of retrieving it if it gets lost.<br>
<br>
Access has a utility to split the database. See Tools / Add-Ins / Database Splitter<br>
<br>
- Thread starter
- #6
Thanks for your suggestions. I secured the database with a password. Unfortunately, the server coincidentally hic-cupped right after I added the password. That had me concerned for a few minutes. <br>
<br>
Why did you recommend adding the password before I split the database? Since I want different users to have access to reports and queries but not necessarily tables, don't I want to have different passwords?<br>
<br>
Why did you recommend adding the password before I split the database? Since I want different users to have access to reports and queries but not necessarily tables, don't I want to have different passwords?<br>
Create a test database and experiment. I believe the front & back end passwords need to be synchronized. If the two db's had different passwords, front-end users would be prompted for both passwords. As far as I know, passwords are all or nothing. Users either have the password or they don't. If they have the password, they have total control over all the objects.<br>
<br>
By creating a front-end with queries & read-only forms you give the IMPRESSION that the db is read-only. In reality they can do whatever they want.<br>
<br>
By creating a front-end with queries & read-only forms you give the IMPRESSION that the db is read-only. In reality they can do whatever they want.<br>
- Thread starter
- #8
-
1
- #9
I've applied Access security to 4 production applications (each a front end/back end pair) with a pool of 120 users. <br>
<br>
Re: the front-end, back-end thing, it makes it very easy if you keep all tables in your back end, and all forms, reports, and objects you want your users to see in the front end. The beauty of it is that when you want to change a report that relies on a query, a couple of forms that rely on a few queries, etc., it is much easier to simply replace the entire front end:<br>
(1) make a copy of your front end, <br>
(2) make ALL changes, <br>
(3) rename your existing front end, <br>
(4) move/rename your new front end <br>
This has a number of advantages. You don't overlook importing any changes if you do 8 items at a time, you don't lose your old versions if you screw up, you don't have to mess with production items, and it only takes a minute to do the switch over.<br>
<br>
Re: security, The database password level security is useless if you want to allow read access. User level security is what you need if you wnat a lot of people to read the data who may accidentally screw it up if they have write permissions. It relatively easy both to set up and maintain, as long as you give permissions only to groups, not users. <br>
<br>
I put no NT security on the files. If you do this you must be sure to back up nightly as this means a user can delete the entire database. The other NT option I've heard of (but not used) is to create a dummy user who has all NT permissions, and open the database as this user (and never close it while other users are in it). Since the .ldb file is only created by the first user to open the db and deleted by the last user to exit the db, none of the other users need create/delete permissions. Of course if you need to close the database or get exclusive use to compact it etc. you must do so as the dummy user.
<br>
Re: the front-end, back-end thing, it makes it very easy if you keep all tables in your back end, and all forms, reports, and objects you want your users to see in the front end. The beauty of it is that when you want to change a report that relies on a query, a couple of forms that rely on a few queries, etc., it is much easier to simply replace the entire front end:<br>
(1) make a copy of your front end, <br>
(2) make ALL changes, <br>
(3) rename your existing front end, <br>
(4) move/rename your new front end <br>
This has a number of advantages. You don't overlook importing any changes if you do 8 items at a time, you don't lose your old versions if you screw up, you don't have to mess with production items, and it only takes a minute to do the switch over.<br>
<br>
Re: security, The database password level security is useless if you want to allow read access. User level security is what you need if you wnat a lot of people to read the data who may accidentally screw it up if they have write permissions. It relatively easy both to set up and maintain, as long as you give permissions only to groups, not users. <br>
<br>
I put no NT security on the files. If you do this you must be sure to back up nightly as this means a user can delete the entire database. The other NT option I've heard of (but not used) is to create a dummy user who has all NT permissions, and open the database as this user (and never close it while other users are in it). Since the .ldb file is only created by the first user to open the db and deleted by the last user to exit the db, none of the other users need create/delete permissions. Of course if you need to close the database or get exclusive use to compact it etc. you must do so as the dummy user.
I find this discussion of this issue to be of great use. I'm having difficulty mysrlf trying to setup user-level security. I almost think it is a Novell vs. Microsoft problem. All my groups are setup correctly, but I still can't get into my database to test the user I added.
Here is the way I've found, through trial and error, to simplify - open to suggestions/corrections.
1) All user groups who need NT read permissions to the folder that holds the system.mdw file, because this is where Access stores information about security groups.
2) All user groups who add, delete, or change data need those permissions in the NT folder that holds the .mdb's, because this is where Access creates the .ldb (write lock) file. Since this means the users can then delete the .mdb's, you want to backup nightly!
3) After you have the appropriate NT security in place, add Access security. If you have a front end and back end, you can give the User group all permissions to the front end, and only apply restrictions to the back end. The downside is again that someone may change the design of a query, form or module (not a table as they are all in the back end). If you want to avoid that, take away change design permissions from all front-end objects.
4) Don't forget to address the "admin" user! It should be only in the User group, not the admin group, once you have set yourself up as an admin. I usually set the password of the "admin" user to something if I want to know who's getting into the database. If you don't set the password, anyone who is not pointed to the system.mdw that contains permissions will instead point to the system.mdw on their own hard drive. This causes them to skip the password check, and enter the db as the admin user.
1) All user groups who need NT read permissions to the folder that holds the system.mdw file, because this is where Access stores information about security groups.
2) All user groups who add, delete, or change data need those permissions in the NT folder that holds the .mdb's, because this is where Access creates the .ldb (write lock) file. Since this means the users can then delete the .mdb's, you want to backup nightly!
3) After you have the appropriate NT security in place, add Access security. If you have a front end and back end, you can give the User group all permissions to the front end, and only apply restrictions to the back end. The downside is again that someone may change the design of a query, form or module (not a table as they are all in the back end). If you want to avoid that, take away change design permissions from all front-end objects.
4) Don't forget to address the "admin" user! It should be only in the User group, not the admin group, once you have set yourself up as an admin. I usually set the password of the "admin" user to something if I want to know who's getting into the database. If you don't set the password, anyone who is not pointed to the system.mdw that contains permissions will instead point to the system.mdw on their own hard drive. This causes them to skip the password check, and enter the db as the admin user.
- Status
Similar threads
- Locked
- Question
- Locked
- Question