Microsoft Access Team Blog : Security

Running a Command as Administrator in VBA

robcooper — Wed, 11 Nov 2009 16:23:32 GMT

We received a question the other day from someone who was using the Shell function in VBA to run a command in a command prompt. The command in question was netsh dhcp, but this could apply to any number of commands.

The original code was as follows:

Shell "c:\windows\system32\cmd.exe /k netsh –c dhcp"

This code had worked for a while, but on Windows Server 2008 (and presumably Windows Vista and Windows 7), this command requires elevated permissions. There are likely a few ways to do this, but we’ll look at the runas command to make this work.

The runas command allows you to start a process as another user. For our purposes, the syntax is something like:

RUNAS /user:<UserName> program

To run netsh using the runas command, you could change the code as follows:

Shell "runas /user:administrator ""c:\windows\system32\cmd.exe /k netsh –c dhcp"""

This will launch a command window and prompt you for the administrator password in the command window itself.

Another way to do this is to use "runas" as the verb for the ShellExecute API function as follows:

Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" _
(ByVal hWnd As Long, _
   ByVal lpOperation As String, _
   ByVal lpFile As String, _
   ByVal lpParameters As String, _
   ByVal lpDirectory As String, _
   ByVal nShowCmd As Long) As Long

Sub RunAsAdmin()
Const SW_NORMAL As Long = 1

    ShellExecute hWndAccessApp(), _
                 "runas", _
                 "c:\windows\system32\cmd.exe", _
                 "/k netsh -c dhcp", _
                 "c:\windows\system32", SW_NORMAL
End Sub

When you run the RunAsAdmin procedure, you should be prompted by Windows to run the specified command.

Access 2010 trusted documents (or databases)

Clint Covington — Thu, 01 Oct 2009 17:39:31 GMT

the Office 2010 Engineering blog has a good post from Maithili about trusted documents. We implemented this security feature in Access as well. What it means is that you can now trust an individual database without having to put it into a trusted folder. It is pretty simple, you go to the BackStage and choose the Enable Content dropdown. Choose Enable All Content.

You can read more about how the feature works across Office here.

Enjoy!

Encryption vs. Encoding

robcooper — Mon, 19 May 2008 23:01:09 GMT

Every now and again we get the question of "what is the difference between encryption and encoding?" This came up again today so we wanted to try to answer it more broadly.

In short, the feature that we call "encryption" is a feature that was introduced for ACCDB files in Access 2007. This feature was an improvement over the feature known as "encoding" in Access 2003. "Encoding" uses a proprietary algorithm for scrambling the data in a database and was first introduced in Access 2.0. "Encryption", used in Access 2007, uses improved Windows APIs and is stronger than previous versions.

In addition to the algorithm being used, here's a summary of the functional differences:

	Encryption	Encoding
File format	ACCDB, ACCDE, ACCDA	MDB, MDE, MDA
Requires database password?	Yes	No
Creates a new file?	No	Yes
Ribbon entry point	"Encrypt with Password"	"Encode/Decode Database"
Requires the database to be opened exclusively?	Yes (because a database password is required)	No

You'll notice that a database password is required when using "encryption" in a database in the ACCDB file format and not in the MDB file format. As a result, the behavior of these buttons is different in the Ribbon. When you click "Set Database Password" in the Ribbon in an MDB file, a database password is opened, but the file is not encoded. We've changed the text of the command in an ACCDB file to read "Encrypt with Password" to demonstrate that these are in fact a single operation.

The feature called "encoding" in Access 2003 and Access 2007 was previously called "encryption" in Access 2002 and earlier. We realize this is somewhat confusing, however, the term "encoding" more accurately describes the algorithm used for the feature so we changed it in Access 2003. Databases encoded using Access 2003 or earlier should not be considered secure.

If you're working with both the MDB and ACCDB file formats in Access 2007, there are a few things to keep in mind:

An encoded MDB database cannot be converted to the ACCDB file format
An encrypted ACCDB cannot be converted to the MDB file format
Because encrypted databases cannot be converted to MDB files, you'll need to remove the database password to save an encrypted ACCDB as an MDB

Lastly, we'd love to hear more from you about this. How many of you are using encryption in ACCDB files vs. encoding in MDB files? Thanks!

Avoiding security prompts for runtime applications

Clint Covington — Wed, 09 Apr 2008 02:07:00 GMT

Edit April 9th, 2008: It looks like the fix was checked into a post RTM version of the Package Wizard. It works on internal builds but I now need to figure out the plans for releasing a SP1 version of the Package Wizard.

----

One of the consistent feedback we got on this blog was that people expected to have runtime applications run as trusted applications. We wanted to make this happen for the RTM version of the runtime but some issues kept that from happening. A change was made to the Access 2007 SP1 Package Wizard where it now automatically writes the location of the application as a trusted location. This means your SP1 runtime applications will just work without any security prompts.

Enjoy!

Security followup

Erik Rucker — Tue, 01 Nov 2005 23:24:00 GMT

This is a consolidated post covering the main things that came up about security. Again sorry for the delay on getting this out. Also note the post has links to the pictures rather than in-place thumbnails. I'll get them moved to a better home where I can reference them directly tomorrow.

I took away 4 main issues from the comments on the security model:

What is “disabled mode” and how does it work?
What are “safe macros” and why would anyone ever use them?
How can I tailor my app’s UI to specific users without using User Level Security?
How do ADP’s fit into the new security story?

Disabled Mode:

The Automation security property will still be honored and will continue to function the way it always did. This property as you already know is valid and useful in developer scenarios where Access is launched using startup scripts and applications.

Disabled mode and the Office Trust Center are designed to make it easier for a user to make trust decisions in scenarios where scripts that launch Access do not come into play.

There are scenarios, where developers of a solution want to ensure that code in Access (startup form/ macro or otherwise) always executes. In such cases the recommended approach is to ensure that one or more of the following conditions are met:

The database is signed with a trusted certificate.
The database is installed in a trusted location.

By meeting these conditions, the code within the solution will always be enabled. In scenarios where neither of these conditions can be guaranteed, Access can be made to revert to its legacy behavior of a modal startup trust prompt, that will launch and execute code in the database or not open the file at all. To revert to this legacy behavior set the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\

Value: ModalTrustDecisionOnly = 1 (DWORD)

Safe Macros:

Safe Macros aren’t meant to replace code, and as noted there is no way all VBA in Access apps today could be replaced by macros. However, they can still serve a very useful purpose, and there is an interesting set of applications that can be created with no VBA at all. The Access team is building over 25 out of the box applications that use only macros. By not using code, we can ensure that these apps are fully functional without signing and without being trusted – they can be mailed around and will work great. In order to make that work, we’ve extended the macro language in some key areas and rethought about the way we build apps.

Even applications that use VBA may still want to use macros for some functionality, like creating simple navigation that will still work when the application is running in disabled mode. Examples include:

Enable navigation and other safe actions that will be available to the user even in disabled mode.
A combination of safe macros and code, provide an alternatives like an alert requesting the user to enable the database to unleash its full potential in disabled mode, where as using code to fulfill complex business logic requirements in enabled mode. For example: Let's say a button is supposed to execute an update query, which would be disabled if the database is not trusted, in this case using a macro that looks like the following can provide a usable experience:

{missing picture 1 is available at http://groups.msn.com/AccessBlogPics/shoebox.msnw?action=ShowPhoto&PhotoID=1}

Custom navigation using the navigation tools:

Access 12 developers will be able to customize the “navigation pane” (new nav metaphor, more on that very soon) to show users only those objects they need to see. This is the key thing that Access developers did with the ULS, but done in the context of personalization rather than security.

Let's consider a simple scenario where the database has the following objects:

Tables:

Issues

Contacts

Forms:

Contacts

Issues List

Issue Details

Reports:

Active Issues

Issues by Assigned To

Macros:

Autoexec

As the creator of the solution let's say I wanted to create the following navigation model:

A set of my users see all the objects and are able to design them.
A set of my users can see and use some forms and reports but not design them.
A set of my users can only see and use the forms and reports based on Issues, not Contacts.

To go about doing this I can use the concepts of the navigation pane along with certain macros and even code.

The first step is for me to create the navigation pane categories and groups that would allow me to divide up these objects in a way that makes sense. Based on my requirements, I'd need three categories, with the following groups and object shortcuts:

· All Objects

· Tables:

· Issues

· Contacts

· Forms

· Contacts

· Issues List

· Issue Details

· Reports

· Active Issues

· Issues by Assigned To

· Macros

· Autoexec

· Issues and Contacts

· Forms

· Contacts

· Issues List

· Reports

· Active Issues

· Issues by Assigned To

· Issues

· Forms

· Issues List

· Reports

· Active Issues

· Issues by Assigned To

For object shortcuts in the "Issues and Contacts" category and the "Issues" category, I'd disable design UI (using the shortcut properties option in the context menu for each shortcut). The property on the shortcut will disable all UI entry points into design for that object.

{{missing picture 2 is available at http://groups.msn.com/AccessBlogPics/shoebox.msnw?action=ShowPhoto&PhotoID=2}}

Now with my categories ready I can create the logic that sets the navigation pane category based on the user. To identify the user I can use code to get the current windows user ID and map that ID to a given category or any other logic (like a custom login prompt) I prefer.

Let's say I'm using code to identify the user and assign him a category (in a function called GetUseCategory()), then the startup macro would look like:

{missing picture 3 is available at http://groups.msn.com/AccessBlogPics/shoebox.msnw?action=ShowPhoto&PhotoID=3}

A brief introduction to Navigation pane macros:

SetDisplayedCategories:

This macro allows the user to specify the categories displayed in the navigation pane. It takes two arguments:

Show (Yes/No): Specifies whether to hide or show specified category.

Category (Enum): Allows the user to specify an existing category. If blank macros operates on all categories.

LockNavigationPane:

This macro allows the user to lock the navigation pane, disabling any further customization via the UI. It takes one argument: Lock (Yes/No).

NavigateTo:

This macro allows the user to navigate to a specific category and sub group. It takes two arguments:

Category (Enum): Specifies the name of an existing category. If blank default to first available category.

Group (Enum): Specifies the name of the group within the category.

ADP’s and Access 12 Security:

The ADP architecture is conceptually unchanged between Access 2003 and Access12, which means that the features continue to work in essentially the same way they did. We continue to believe that SQL Server makes a great store for Access data and that building the UI either through linked tables or ADPs will continue to work well.

Access 12 Security Model

Erik Rucker — Wed, 19 Oct 2005 18:39:00 GMT

In last week’s post, I talked at a high-level about some engine-level changes we’ve made to Access. This week, I’ll talk about changes to the security model that sits on top of that engine, and crosses into the UI as well. Starting next week, I’ll be going into the UI changes and all the other new stuff we’ve done in the product.

Fewer modal prompts on boot (by default) and disabled mode

In Access 11 based on the configuration of the machine when a user opened a database, he or she encountered 3 to 4 modal startup prompts which, to say the least, was cumbersome. In Access 12 we've been able to weed out most of these startup prompts by improving the application's trust evaluation model (improvements to the Office Macro security model) and making core improvements to the client. When a user opens a database, Access 12 will assess the trust around this database by using the following pieces of evidence:

o Location of the database file: Using the Office trust center, users can denote certain folders (local or remote) as trusted locations. This is an easy way to tell the application that the Office file within this folder is trusted and hence is safe to launch.

o Code signatures: The good old signature model still exists. A user can digitally sign a database with his or her code certificate and share such a signed database with other users. Users who trust the certificate can then launch any Office file with a valid signature as a trusted file.

By examining these pieces of evidence associated with a database, the Access client then makes a decision to trust the database or not. If trusted, the database will launch fully enabled. If the database is not trusted, Access will still open the database, but components like VB code, macros, pass through queries and the like will be disabled. This disabled state of the database will allow the user to examine the file, without the fear of code execution. If the user decides the file is trustable after examining it, she can choose to trust it and thereby enable all code, etc. This trust model is shared across the Office suite, so will be familiar to all Office users.

Safe Macros

When in disabled mode, any set of custom logic even in simple and potentially safe cases like navigating to another Access object (hmm … isn't this the switchboard scenario) would be disabled. Access 12 has created a sandboxed coding mechanism for cases like this using the Access Macro language. Macros have been part of access since version 1, but are rarely used by developers today, since they’re essentially a subset of VBA. In Access 12, however, we’ve been able to use that subset to our advantage by marking many of the macro actions as “safe”. These safe macro actions can then be stitched together to provide logical components that still function if the database is opened in disabled mode. This subset of safe macros is not meant to completely replace the need for code, but to provide basic and safe operations within disabled mode.

Improved encryption with database passwords

In previous versions Access depended on JET's ability to encode a database with its proprietary encoding scheme. Though the scheme served its purpose when it was first released, the current market provides better and tougher encryptions algorithms that can be used. The same goes with the "Database password" feature, JET would allow only users that knew the password to open the database, but would do little to encrypt the file when a password was set. In Access 12 (by improving the new engine), we've combined the two features into "Encrypt with database password" for new file formats (for backwards compatibility reasons the old file formats would still support the old proprietary scheme). This feature allows users to encrypt a database using one the many Office supported algorithms, bringing encryption in Access on par with the new encryption models for other Office applications.

User level security

Since JET is a file based database system where users need physical access to the file to operate on their data, the concept of user level security in Jet to assign different levels of user access to the data within the same file was not recommended. To have multiple people use the database but with different data access privileges, the recommended practice was to move this data to a centralized service like SQL server or SharePoint lists. However, Jet has had this feature for some time and it has worked OK for usability and custom navigation scenarios but isn’t recommended for actual security. To help promote using truly secure user-level security, ACE will no longer support the JET concept of user level security for new file formats (for backwards compatibility reasons ACE will continue to support JET user level security for old file formats). To help maintain the scenarios around custom navigation the Access UI (including the NavPane) will allow solution creators to completely customize the navigation experience.

We believe that the security work in Access 12 will both make the product more secure through things like the improved encryption and clearer user-level security, and will make security easier to manage through the new trust model and “safe” macros. In the next post, I’ll start talking about the feature changes we’ve made to the product by describing how report design has changed.