My boss fancies himself an IT genius, and has created a number of databases, all secured with Access' user-level security MDW feature. Now for the MDW feature to work, you either have to craft shortcuts that point to the MDW, or you have to configure the workstation to use that MDW as default.
He chose the latter.
Now, when opening MY unsecured DBs, or even trying to create new blank ones, it wants me to login to his MDW. This cannot stand.
How can I reconfigure Access to use the default MDW (I think it is called System.MDW).
NB: I cannot run code in the VB window. I cannot open any databases at all. Solutions must likely be external to Access.
Okay, as it turns out, you need to modify the value HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Access Connectivity Engine\Engines\SystemDB to "%appdata%\Microsoft\Access\System.mdw"
Or, in the case of Office 2010, HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Access Connectivity Engine\Engines\SystemDB
Not sure why I didn't look in the registry first.
Related
Newbie - Looking for assistance in moving an Access 2010 front end, SQL back end, from an isolated test environment to developing in a live environment with multiple developers.
Currently reading "Automatically Deploy a New Access Client" http://www.databasejournal.com/features/msaccess/article.php/3286111/Automatically-Deploy-a-New-Access-Client.htm
Need assistance with how to switch from test database to live database during publishing.
The general assumption is that on code start up, you need to check if the current linked back end is the same. This suggests that you need to have some .ini or text file that points to the production server.
Or if you on the same network, then you can simply use the linked table manager, point the front end to the production SQL server and re-link. You then compile to an accDE and simply distribute that pre-linked database to each workstation.
So you only really need re-link code on start-up if you can’t be on site or on the same network to pre-link.
If you link to SQL server using a FILE dsn, then Access automatically converts the links to DSN-less, and thus no re-linking code is required, nor is any “DSN” setup on each workstation required.
So you can manually switch and re-link your front end application before you distribute and that would means you simply switch which database the FE points to before you distribute.
As noted, if you can’t be on the same network for this “switch”, then you have to adopt some code to test the current link, and ensure that it points to the correct server (and this means an external file with the correct SQL server needs to exist).
If you need to switch during deployment, then you need some code to test if a re-link is required, and if yes, then you need some re-link code to run “one time” to correct and point the links to the production server. It certainly much less work to pre-link, and thus no switch or change in the connection and which SQL server you point to will be required during deployment.
If you need some re-link code, then this code can re-link for you:
http://www.accessmvp.com/DJSteele/DSNLessLinks.html
So, I'm trying to figure out how best to go about exposing some reports on a SSRS server that's behind the firewall to users on an extranet site, as discussed here. My DBAs have set a constraint that I pass Windows credentials to the server to gain access, and that the server remain behind the firewall. I'm having trouble conceiving of how to do that and still maintain a secure system in a public-facing DMZ. Here are some of my questions:
How can I allow users to authenticate to AD while preventing brute-force account hacking? In other words, one option is to create an app in the DMZ that accepts a u&p, and attempts to authenticated against AD inside the firewall. However, I need to prevent repeat trying and failing.
Assuming I have an authenticated user, how do I pass that credential to the SSRS server? What languages or mechanisms exist to accomplish that? Does this have to be a .NET app or could I manage it through Java?
How would I accomplish permitting the user to interact with the SSRS server? I don't want to loose all the UI functionality of the reports, and I don't want to rewrite it either. It seems like a hack to write an app that acts as a proxy, but that's all I can think of. Ideas?
TIA
I understand that sandbox mode stops expressions that Microsoft considers 'unsafe.' These expressions can be wrapped in VBA code to circumvent the sandbox. But what is the advantage? Is it merely that you can provide some sort of validation within the code? I am specifically talking about the expression Environ("username").
I have set up a test application that used the above expression in a control, which is explicitly blocked when sandbox mode is on, however, I have wrapped the expression in VBA code as well inside a module - which is not affected by VBA.
Is the VBA code safer to use than the control expression? I am having trouble finding how I would exploit an expression in a control, and is it any safer to use the VBA code? Why or why not?
Sandbox mode is a general safety measure geared toward the Jet/ACE engine and preventing applications, including Access and any other app using the engine for reading/writing to MDB and ACCDB databases (and also Excel files), from using Jet/ACE as a means to run unsafe expressions.
For instance, access to environment variables could allow sensitive information (like the username) to be read and others (like the PATH) to be changed.
Sandbox mode is a default security measure that prevents all applications that use the Jet/ACE database engine from running these arbitrary, and potentially dangerous, commands.
Trust vs sandbox
Note that sandbox mode is different from Trust: the sandbox is only concerned with items that are interpreted through the Jet/Ace database engine, not VBA.
Trust on the other hand will ensure that Access applications are always disabled by default and will thus disable ActiveX, VBA, etc unless that application is running from a Trusted Location (folder).
When you open a database outside of a Trusted location (for instance one downloaded from the internet in your Download folder or on your Desktop) it will have a big yellow warning saying that all active content has been disabled.
The user would need to click on that button to enable temporary the application after he/she has assessed the security risk.
So Trust is just about enabling/disabling of active content in an Application. Sandbox is an additional (an independent) layer that is always on by default and prevents 'dangerous' operations from being run through the database engine.
Bypassing the sandbox
Most Trusted applications will have no need to get outside of the sandbox.
If you need to access some sensitive operations, once your application is Trusted, you can use VBA instead.
It's OK because the user would have explicitly allowed it, either by clicking the warning when they opened the application or by running it from a registered Trusted location.
If an application really needs to use run outside the sandbox to execute unsafe expressions you must first change the SandboxMode registry key and then run your application from a Trusted location (or have your application digitally signed).
To change the registry key, the user account would need to be able to modify it (normal users only have read access to it).
So the thinking is that to disable sandbox mode, you need to log in as Administrator of the machine and modify that registry key. It's not something you can do by accident!
Registry
If you really want to disable Sandbox mode (you probably shouldn't) you will find the SandboxMode key under HKLM\Software\Microsoft\Office\14.0\Access Connectivity Engine\Engines (or \SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines on 64 bit OS running 32 bit Office) and the valid values for key are:
0 Sandbox mode is disabled at all times.
1 Sandbox mode is used for Access, but not for non-Access programs.
2 Sandbox mode is used for non-Access programs, but not for Access.
3 Sandbox mode is used at all times. This is the default value, set when you install Access.
Conclusion
I think the main thinking there was to ensure a set of safe default in layers:
a vanilla install of Office would ensure that you can't open and run unsafe code by default (the database isn't Trusted)
the sandbox mode prevents apps (including Access) from running unsafe commands throught the Jet/Ace database Engine in all cases.
you still have the flexibility you need, but it requires jumping through few determinate hoops to work properly (modify the registry as administrator). Something most applications should shy away from.
It's probably that Microsoft saw this as a way to push developers to only use safe expressions when using the database engine by making it difficult to run unsafe commands.
I'm trying to rebuild an Access adp application in Access 2007. I started with a blank database, linked the SQL Server tables I need with ODBC, and then copied over all of the forms from the original application. I then updated the data sources for the forms to go to the correct tables.
When I open one of the forms, I get the error "Syntax error in WITH OWNERACCESS OPTION declaration". This error is occurring before the Open event code is being run.
Does anyone have any ideas about how to track down where this error is coming from? Or maybe an idea of another way to do this altogether?
Thanks!
WITH OWNERACCESS OPTION makes no sense in an ADP, as it's a command for Jet SQL for use with Jet user-level security. With an ADP, the security should all be set on the server. So, you should remove all the WITH OWNERACCESS OPTION statements from your form RecordSources.
Frankly, I'm not sure they have an effect in anything other than a saved QueryDef, so likely they were an error in the original application.
Also, I would never recommend copying anything from an MDB into an ADP. First off, I don't believe migrating to an ADP is ever advisable (though I certainly use ADPs as an administrative tool with my MDB/ODBC apps that use SQL Server), but secondly, there are so many differences between the two platforms that I just can't see them working.
If I chose to migrate an MDB to ADP (and I can't imagine that I ever would, given that MS has been deprecating ADPs for about half a decade now), I would start from scratch and rebuild it from the ground up.
I've got a MS Access database with a table and a form, but I want the user to only see the form. I don't want them to be able to edit any of the data. The user should only be able to use the form to query the table. Any suggestions??
There are a few ways to enforce some control over what users can do.
AutoExec
The most simple way is to use an AutoExec macro to initialise the user interface when the application starts.
That way to can make sure that only the form you want is displayed and hide everything else.
Runtime
A good complement to this approach is to compile your application and force the user to use the Access Runtime to use your application.
In the runtime, users don't have access to all the standard tools unless you explicitly code for it.
A good thing to know is that unlike previous versions, the Access 2007 Runtime is free, and that makes Access a very cheap platform to develop for.
Runtime emulation
With Access 2007, a simple way to ensure that the application will open as if only the runtime was installed is to change the extension of the database to .accdr.
You can also force a full Access installation to open a normal database in Runtime emulation by passing the /runtime command line switch.
Secure data-access
Note that short of encrypting the database (but then you have to manage the password), all you can do is make it hard for the user to open the tables manually.
A determined and knowledgeable user can always circumvent these protective measures and access the data.
If you need a really secure solution though, Access may not be the best choice: implementing fine grained security in Access is a greater challenge than the alternatives, say storing the data into a SQL Server database for instance where security is enforced.
Links to resources
Security Considerations and Guidance for Access 2007 on MSDN
A simple Microsoft Access User-Level Security Tutorial for older versions of Access.
FormSafe, a commercial product that helps enforce security on form controls.
I believe you want to use Access User-Level Security. Here's the documentation at Microsoft.
If you are using Access 2003 or earlier, you can use user level security, as mentioned. If you are using Access 2007 you are out of luck - Microsoft in their wisdom removed this ability. You will basically have to write your own login and set permissions on editing etc. using VBA code.