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.
Related
I have a Microsoft Access Database with an interface for usability ... But now, all users have access to the tables of the database directly. I want to deny this except for those who are authorized i.e.: Password Protect the access to the tables not the GUI.
Unfortunately, there is no "simple" solution for this.
Access has a security-mechanism built in. Note though, that this only works for the "old" mdb format, not for the new accdb format supported by Access 2007/2010. Thus, if you are going this way, you are using a deprecated technology which will might not be supported in future versions.
That said, here is a tutorial found on the Internet. The process is a bit complex; it definitely exceeds the space of a StackOverflow answer:
The Microsoft Access Security Apparatus
If you need a more future-proof solution, I'm afraid your only choice it to move the back-end (= the tables) into another database system, such as SQL Server Express. There, you can restrict access to the tables and grant access to your application by using Application Roles.
If you only want to prevent your users from accidentally messing up your data, it might suffice to install only the Access Runtime instead of the full product. Note, however, that this does not provide security, since a malicious user could simply install the full version of Access!
It's advisable to assign permissions to groups, not to users, because each user inherits the permissions assigned to the group. this might help you
I would like to design a database application using Microsoft Access. Before I start there are some important features I want to make sure are available in Access.
In a multi-user environment can the database be accessed simultaneously by different users such that only individual records are locked/unlocked as necessary?
Does Access need to be "opened" or can a "front end" be designed so the user only sees menus, menu bars, tabs, data screens, etc?
Can the database design features be locked so the user cannot change any database features?
Thank you for your help.
AF
Yes, certain records can be locked.
For Example, if you work with an ADO Recordset:
recordset.Open Source, ActiveConnection, CursorType, LockType, Options
LockType defines the locking-mechanism used for the selected Query Source.
More Information on that: http://msdn.microsoft.com/en-us/library/ms675544%28v=vs.85%29.aspx
Usually you split your Database into an frontend and backend. The back-end only contains only the tables, the rest goes in to the frontend. The backend tables are then linked to the frontend. Here is a link explaining how to do that: http://www.fmsinc.com/MicrosoftAccess/DatabaseSplitter/
In the frontend file can be compiled, so that the frontend users cannot edit sources.
In response to the third of your initial questions please note that Microsoft Access offers the facility to convert an Access database to an executable file (having file extension "accde" where your forms, reports, code and macros are protected to a substantial extent. However the level of protection offered with regard to tables is low in that the same are directly accessible even in an accde. MS Access also offers the runtime version free of charge and does not restrict its deployment to as many users as you may require. It no longer offers user-level security. This feature has been replaced with an encrypted password feature. Thus you will have to insert your own design and code to impose access restrictions on different categories of users. Alternatively, to use the user level security feature, one has to develop his application in an earlier version of Access in which this feature was available and thereafter use a recent version to convert it. I am uncertain whether MS Access 2013 will entertain such a database but understand that MS 2010 will though it will not offer that feature when you create a new database inside it.
You can get SQL Express for free, it's a stripped down version of SQL Server. It will handle multiple user access significantly better and not come with the bloat/performance degredation issues that Access brings along.
There will be a slightly higher learning curve, but if you're looking to get your foot into the development world's door, you'll be much better off learning how to work with SQL Server than Access.
Is it possible to set Access persmissions using Active Directory users?
Edit: The overall objective is to allow some users to see certain tables and deny this permission for other users. I'm wondering if it can be done using active directory users.
Depends on what you mean by Access permissions. Access user level security do not interact with Active Directory in any way. ACC: Microsoft Access Security FAQ Available in Download Center It is suggested you reread this FAQ several times. I must admit I never quite understood it. Also see ACC2000: Overview of How to Secure a Microsoft Access Database
Now what you could do is read the Active Directory data for the logged in user and groups and such. Then with some local tables mapping the various AD groups along with the login userid to the various objects and menu items in Access you could control access in this fashion. Note however that local tables can possibly be mucked with by a savvy user, etc, etc.
The most useful URL I found was the following newsgroup posting need help on get list of W2K ad Domain (fqdn) by using VB Options I kept a page of notes when I was working on this topic but they may or may not be useful. I can post them if desired.
I agree with the things that both Tony and Philippe has posted. I just want to add a bit:
If you really need security, then a Jet/ACE back end is not going to do the job for any significant definition of the word "security". Jet ULS is crackable and fairly easily so for anyone with even basic programming chops. Thus, if it's DATA SECURITY that you're looking form, Philippe is right that you should choose a different database engine.
But if you are only looking to control ACCESS in your front-end application, you have three choices:
maintain a couple of tables in your database of your users and the permissions on each of the objects.
implement Jet user-level security.
use AD users/groups in place of Jet ULS.
None of these choices is seamless.
And all of them mean that your front-end has to be programmed to deal with the issues.
If you're restricting access for security reasons, then it makes sense to use a database engine that integrates with Windows security (i.e., SQL Server).
If you're doing it just to streamline program flow, and to adapt the app at runtime to the needs of particular users, then you don't necessarily need security on the data store so much as you need a way to keep track of who is using the database and what groups they belong to, and then what parts of the app they should have access to (and, secondarily, what level of access, read/write, read-only, etc.).
I have used Jet ULS for this last purpose for years, but have never been entirely happy with it because it's not that easy to make it user-manageable. Integration with AD would be a good choice, but that means that whoever administers your app needs to have the permission to manage AD users. This may not be something your friendly neighborhood sysadmin is willing to agree to.
On the other hand, if you end up needing both back-end security and front-end access control, you can't beat a SQL Server back end using Windows security for one-stop shopping via AD.
According to the few questions you posted these last days on Access, it seems obvious to me that you should consider switching your tables (not your forms) from an Access/mdb file to a SQLExpress server, where all these security issues can be easily managed. Upsize your database, add your connection string as a public variable in your client app (or in an xml file, local table, or anything else that can hold the string, even an extra property of your access file can do the trick through the currentDb.createProperty method), and go for a real client-server configuration.
Is there a way to secure tables in ms access db from unauthorized access? I would like my users to use the forms in the db but i don't want them to see the contents of the tables. I know i can hide a table but anyone who knows just a bit about access can show the hidden tables anyway. I cna also change a name to UsysTableName but again - enabling system tables shows them all. Is there a safer way? Securing by password maybe?
Also in access there are users and groups, and the possibility of granting rights.
You can access this functionality via tools/security/user and group permissions.
You need to create a workgroup information file in order to use this :
see : http://www.databasedev.co.uk/access_security.html
NOTE : Indeed Ms Access is in most cases a poor choice of db. But if you have to keep on using it for one reason or another, learning its security model is imperative in real world apps.
For Access 2003 Understanding the role of workgroup information files in Access security at http://support.microsoft.com/kb/305542/.
For Access 2007 How to use the Workgroup Administrator utility in Access 2007 at http://support.microsoft.com/kb/918583.
In your case, I suggest moving the tables you want to secure into a different database then link to the User-Interface (front end) database. This allows you more control over security. Using a password only keeps non-users out of the database. Logged in users can still see the tables.
One solution is to have your forms on one side (client side) and your tables on the other side (server side). Each user has only a copy of the forms, and the tables are somewhere else on the network.
Another solution is to install the runtime version of access (free to use) on user's computer. In this case the database window does not appear.
Whatever is you choice, you'll have to fully manage access to commandbars, creating you own ones (and forbidding the display of access commandbars).
If you go for the first solution, you'll be on your way to a real client/server structure, and you'll be able sooner or later to switch to SQL Server for your tables (your forms can then stay in an Access client application).
With some limits, it is possible to completely delete the links to the back-end tables in the front-end/app:
During app open, just use ChDir "\\someShare\someFolder" in VBA
As the source of your forms & reports, use SQL SELECT instead of saved queries/tables, using the syntax: SELECT field1, field2 FROM [BackendName_be.mdb].myTable. Note that the path is NOT specified!
This way the forms/reports will work perfectly, without any table (not even hidden) in the app.
If you put the BE in a hidden folder/share and you deliver an MDE, users will have a very hard time finding where the data is.
This technique has the added benefit to allow instant switching of the back-end (like between test/prod).
Access does a very poor job of securing data in tables. Your users NEED access to the tables in order to work with the data, but you don't want them possibly seeing EVERYTHING. You could encrypt the data in your tables yourself on the fly. I talk about this in my Access Data Encryption seminar.
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.