I'm creating an Access 2010 database and would like some clarification when it comes to concurrency and security. What I would like is upon starting the app only a menu form to be displayed with several buttons including a login button. Most buttons would be disabled until after the user logs in at which point based on their permission group; Viewer(Deafault), Worker, Editor, Admin.
Also, Admin should be the only one to be able to see the access database while the others are restricted to seeing the forms only.
I was just testing the default concurrency implementation but saving my database to a shared network and having myself and a co-worker try to access it. Found out if one accessed the database it locked it from others, and if we both tried at the same time it became read-only.
So I'm just looking for tips on how to start this.
For an Access database all users must have as a minimum read, write and modify permissions on the folder in which the database resides. This is because MS Access creates a lock file and if the second user does not have permissions to modify the lock file, the cannot get access to the database. Delete permissions may also be useful, to remove the lockfile when they are the last person out.
Related
I have a split database in MS Access 2010 on Windows 7.
The back end is on a networked drive in a folder that only some people have write permissions; everyone has read permissions.
Every user has their own copy of the front end stored on their local machine.
Both BE & FE are set to open as shared, not exclusive, for all users.
If a user with read-only permissions tries to get on while another user with read-only permissions is on, they can get on fine.
If a user with read-only permissions tries to get on while a user with write permissions has it open, they get a message saying " file already in use" and they can't open the database.
If a user with write permissions tries to open the database while a user with read-only permissions has it open, it opens as read-only for this user as well.
Do ALL users of a split database need full access? I really don't want everyone to be able to make edits. Anything I can do to get this to work?
The issue has certainly something to do with the fact that the read-only clients can't manage the .laccdb lock file since they don't have write permission to the shared folder in which the database file resides.
When the database is opened in shared mode, each client will create or update the lock file.
It's likely that since read-only clients can't create the lock file, they fall-back to believing they are in exclusive mode.
Once a full-access client creates the lock file, any subsequent client will attempt to use it, and read-only clients will fail since they can't update the lock.
Some documentation regarding lock files:Introduction to .ldb files
If you want to solve your issue, you must grant full access to the folder for all clients, but you can restrict access to the .accdb database file itself to the group of clients that are not supposed to be able to modify data in it.
Alternatively, if you are not using Access 2007/2010 features, you can revert to using an older .mdb file as a backend and use their old-style group security features.
Ultimately, if you really want to control access, you may need to roll-you-own security scheme from within the client, forcing users to log-in (or use their the identity of their machine) and update your forms' data edit properties depending on what that particular user/machine is allowed to do.
We have an access database on a file share that has permissions for everyone in the department to access. The problem i am having is that when multiple users try accessing the database at the same time they are unable to do this. One user can open the database fine but when another user tries to simultaneously, they double click the file icon, get an hour glass for a split second and nothing happens after. We are using Server 2003 as our domain controller. All permissions have been verified on both a domain level and in the access database under tools-options-advanced and setting relevent permissions to shared and no locks. Do you know what could be causing this issue with a "dead link" when user try to open the file simulateneously?
Any help is greatly appreciated.
Thanks.
Ignore the naysayers - Access is perfectly fine for a small number of users. Either you have the default Access settings to open dbs exclusive which will lock out other users or there is some weird network problem.
EDIT
- noticed you already have default shared access
- is record-level locking on?
- also try giving user full control of the shared network folder (Access needs read/write/create/delete to be able to create and delete the ldb file)
This issue occasionally happens to Access databases for almost no apparent reason. Of the suggested responses by Microsoft, you are already doing the second (opening from within Access) but I believe the first provides somewhat of the answer you are looking for.
In the target of the shortcut, include
the path of MSAccess.exe
According to Microsoft Help and Support
When you say share permissions, do the users have full permissions? Full permissions are needed because the share file (.ldb) must be created and deleted.
I am just recently experiencing the same issues, only one person can open the database. We only have 3 people accessing the same database through shorcuts on our desktop.
Now according to Microsoft we need to include the database path in our shortcut, I will tried that. They acknowledge this problem.
MS Access is not worth the trouble in a multi-user setup.
Your time is better spent converting the database over to a server-based RDBMS such as SQL server while you still have hair.
Believe me, you will have to do it sooner or later anyway! Sorry for the bad news.
What is the simplest way to allow one user write access and everyone else read-only access to a MS Access database on a local network?
I trust my users, but unfortunately Access saves changes to data as soon as the row of a table is deselected. Accidental keystrokes are saved without the user asking for the changes to be saved.
Some thoughts on controlling user rights to a Jet data store:
if you really want to lock things down, you'll never manage it with Jet, as it's inherently vulnerable because the user has to have WRITE access to the MDB file.
if you are content with controlling rights to the data in your front-end application, you could provide different front ends (one for WRITE users and one for READ-ONLY).
if you're not using ACCDB format, you can use Jet user-level security. It's a surprisingly complicated technology if you really want to lock down access to the data -- you have to follow all the instructions in the Jet Security White Paper to the letter, or your data will be open to anyone with the standard Jet workgroup file. And even once you're done, it is crackable (though not without spending $$$ to buy cracking software). BTW, database passwords before Access 2007 were completely useless and easily cracked. Access 2007 enhances the security by raising the level of data encryption, but a database password causes lots of issues and doesn't allow you to have more than one level of access (unless you provide two different front ends with different passwords -- cf. #2).
if you just want to use Jet ULS to control access in your front end, you can add your users to groups and then check the group membership in your front-end UI objects (i.e., forms), and give WRITE permission to the users who are in the user group that provides that level of access. The easiest way to do this, assuming you have more READ-ONLY users than those with WRITE permission is to have the READ-ONLY users log on as the default admin user (i.e., you do nothing for their setup), and have the WRITE users log on as a user in the group with WRITE permission. In other words, if they aren't logged on as user "admin", they have full WRITE access.
another alternative is to use NTFS security groups. API code for that is found on the Access Web, but it does require a Windows administrator to implement for you. Again, you would be limiting access in your front end application, rather than actually restricting user rights in the back-end MDB.
Only Jet ULS actually allows you to prevent a READ-ONLY user (who hasn't cracked your workgroup file) from editing your data. All users have to have network access to your back-end MDB, but you can make it hard for them to get to the data even without jumping through the hoops in implementing Jet ULS. Here are some steps to do that (and yes, all of these are a form of "security by obscurity" and will only slow down a READ-ONLY user determined to hack your back end):
Right click each table in your back end and turn on the HIDDEN attribute. This can also be done in code (see SetHiddenAttribute in Help). Naturally, if the end user sets their Access options to display hidden tables, this won't do anything. But most end users don't know about that, and if your users are running your app in the runtime, they won't have the option.
Change the back-end database's Startup Properties to not display the database window and to not use special keys. You can find code for setting the startup properties in the Help topic for "AllowBypassKey".
In your back-end, create a macro named AutoExec with one command, Quit. With special keys disabled, there is no way to prevent the execution of this macro, and as soon as the user attempts to open the back end (even if they hold down the SHIFT key, i.e., the standard keystroke for bypassing all startup routines), the database (and the instance of Access) will close.
Now, all of these things can be undone by someone who knows what they are doing. If you gave me a back end with these things implemented, I'd be in it in about 5 minutes, simply by running code in another Access database to change all these startup properties to give me access.
But your end users likely don't have that level of expertise. Any such user who does probably ought to be a WRITE user, no? :)
Yes, of course -- all of these things are easily hackable by anyone who knows how. But it's also easy to break into your house in seconds for the person with the right tools. That doesn't mean you don't lock the doors, even though it's not bulletproof protection from burglary.
Another consideration is that if you provide your users only the Access runtime instead of full Access, they won't be able to undo any of these settings in your back-end MDB.
Last of all:
Security is not solely a technical issue -- most of it is, in fact, a people problem. In order for people to do their work, you have to trust them to a certain extent in giving them access to your data. There is no technical solution to the problem of the untrustworthy system administrator, for instance, and the only way to fully protect your data is to not give them any access to it at all.
The easiest way would be to use share permissions. Grant write access to a group and put the users who must write to the database in that group. Put everyone else in a read group. This assumes you have a Windows domain, of course.
Here is a site that has some information on securing Access databases. It deals with Access 2000, there may be more options for newer versions.
This is the cheeky answer, but if you need better security, seriously consider upgrading to a more robust RDBMS.
I think it is possible using an ODBC connection to use Access as an interface to almost any database. For example, I have successfully configured a SQL Server 2008 Express Edition database with 2 users, one read/write and one read-only. I have been able to connect to the database from Access by opening an ODBC data source. So a user can have the Office-based report-generating and mail-merging functionality they are familiar with. But with any database server you wish.
This conversation may be a little old, but for some reasons I got the same problem recently. It will not suit to everyone, cause it relies not on M$ SQL Server but on MySQL. Use the MySQL ODBC connector (available here: http://dev.mysql.com/downloads/connector/odbc/), and store your tables on a MySQL server. The Access user's rights on tables will inherit from the MySQL user's rights. Pretty easy to customize...
Fact is, there is NO functional security for an access database.
The link below sells software that will 'recover' your access database Even if it has a a password.
It is a good thing they exist. Their program saved one of my customer's butts once when their previous programmer died and no one else had the password. Thanks to this program we could not get in and no data was lost.
http://www.stellarinfo.com/access-recovery.htm
And before you even think it, No, I do not work for them.
Can user level security enable someone to access a form, but not access a table? I have a form that is connected to a table using a"SELECT" command. It does not "UPDATE" or "DELETE". I'd like for the user to access my form, but I don't want them to be able to view the details in the underlying table. I've tried all sorts of combinations in the user level security wizard, but for some reason, my form comes up blank, unless I give complete access to the user to do anything. Any ideas? By the way, I'm on Access 2003.
You could make an MDE and give it to your users. If you do this, the users won't be able to see anything but the user interface you have provided.
If your tables are in the same Access database as the forms and queries, you first need to "split the database" into a frontend and backend. See:
http://databases.about.com/od/tutorials/ss/splitaccessdb.htm
for information on how to do this. The frontend contains everything but the tables. The backend contains the tables. The frontend is linked to the backend tables using "linked table" objects in the frontend.
Once the database is split, open the frontend in Access, and create an MDE by selecting Tools/Database Utilities/Make MDE File from the menu bar. The MDE is what you provide to the users. They open it the same way they would any other database, except that they can't design any of the objects.
Make sure that you have an AUTOEXEC macro defined in the frontend, so that when the MDE is opened by the user, it has an entry point. The user cannot see any of the objects in the MDE, so if you don't have an AUTOEXEC macro to open the first form, nothing will happen when they try to open the MDE.
If you need the ability to manage the linked tables in the MDE by allowing the user to connect to the backend database with a File/Open dialog, see the following article:
http://www.mvps.org/access/tables/tbl0009.htm
OF course, none of this precludes your users from opening the backend database. If you need stronger security, you can upsize the backend database to SQL Server Express. More info here:
http://office.microsoft.com/en-us/access/HA102755371033.aspx
What you're looking for is a RWOP query. That means "run with owner permission."
To make it work, assuming you've already run the security wizard on your front-end and back-end databases and have removed permissions for the users to even read the tables, you then create a saved query as the recordsource of your form. In the properties of the query, it is set by default to RUN PERMISSIONS as "user's." Change that to "owner's" and save the query. The query will run with whatever permissions on the base table the owner of the query has. If you are running as an administrator with full permissions, you'll want to set the permissions of the saved query to read-only (or create the query under a user logon that has read-only access to the tables -- it's much easier to do the former).
Some caveats:
user-level security is tricky. If you miss even one step outlined in the ULS security white paper, your app won't be secured. The way to test this is to open Access with a default workgroup file and then see if you can access the objects in your database logged on as the default admin user. If you can, then you made a mistake somewhere along the line.
user-level security is crackable by anyone who wants to. This doesn't mean it's not useful, it just means that it's not bullet-proof. I don't worry about that so much, as I consider security as much a people problem as a technical problem -- you have to give employees sufficient privileges to do their work, and you have trust them that they won't abuse the privileges you've given them.
if you're running Access 2007 and using the ACCDB format, RWOP queries are not available to you, as Jet user-level security is not supported for the ACCDB format. If you're using MDB format, though, it will work just fine in A2007.
I maintain an ms-access application splitted to frontend and backend files.
The frontend file is in the users conputers.
The backend file is in a shared folder in the server.
What is the lowest permissions required?
can I give some of the users only read-only permissions in that folder? (or hide it from them in some other way) but still enable them to view the data?
How should I give the best security to the data file and to the folder containing it?
Unfortunately, the lock file (ldb) must be created, updated and deleted. If a user with insufficient permissions opens the database, it will be locked for all other users, therefore all your users need Read/Write/Delete permissions on the back-end.
EDIT #1
The lock file must be created every time the database is opened, this includes via linked tables, and deleted when the database is closed. If a lock file exits and the database is closed, it indicates a problem has occurred. You will also run into problems with compact and repair if it is run with insufficient permissions.
Edit #2
Security for Access is quite a large subject and depends to a great extent on your environment and requirements, for the back-end, it ranges from a database password, which is tissue thin, but quite suitable for most offices, to Access security, which can be complicated and has been dropped in 2007. Here is a link http://support.microsoft.com/kb/207793 for a download for the Microsoft Access Security FAQ for versions < 2007.
Information on security for 2007 can be found here http://www.microsoft.com/technet/security/guidance/clientsecurity/2007office/default.mspx.
Many have suggested that you must give FULL permissions to users, but this is not true. You need only give them MODIFY permissions -- you can deny them DELETE permission, which is a good idea, as it prohibits the users from "accidentally" deleting your data file.
It is true that for a user with DELETE permissions, the LDB file will be deleted on exit when that user is the last user exiting the database. But it is not required that the LDB file be deleted -- indeed, in Access 2 and before, the LDB files were not deleted on exit, but just left there hanging around. This generally has no downside, but occasionally the LDB file gets corrupted and causes problems and really does need to be deleted and recreated afresh.
What I do is have two classes of database users (as defined in custom NT security groups specific to my Access application(s)) -- DBAdmins and everyone else. The DBAdmins have FULL permissions, everybody else only CHANGE. The result is that any time a DBAdmin exits as the final user, the LDB is deleted. This setup works really well, and I've been using it for well over a decade.
Using a hidden share for your back end is really only "security by obscurity," and not really worth the effort. Sophisticated users can figure it out through any number of methods (depending on how you've locked down your front end):
view the MSysObjects table and find
the CONNECT string for the tables,
which will identify the hidden
share.
examine the results of
CurrentDB.TableDefs("name of linked
table").Connect in the immediate window in
the VBE
Now, if you've properly secured your app using Jet user-level security (and it's very easy to think you've secured your database and find out that there are holes, simply because it's really easy to forget some of the crucial steps in the process), they won't be able to do this, but even if you have, Jet ULS security is crackable (it's pretty easy to Google it and find cracking software), so is not really something you should depend on 100%.
Yes - it resolves down to file access permissions as well as read/write. You can't execute any type of data update stuff (you'll get "operation requires an updateable query") unless the user supplies credentials that allow them to write, or you allow write on the file.
Running a query requires only read access.