About Setting Microsoft Office Security in a Testing Environment

Note
You can only include Microsoft Visual Basic for Applications (VBA) code or run COM Add-ins in a macro-enabled document, worksheet, or presentation. You can create a macro-enabled file by saving the documents with a .docm or .dotm for Microsoft Office Word; .xlsm, xltm, and xlam for Microsoft Office Excel; pptm, or potm, ppam, ppsm for Microsoft Office PowerPoint.

To install and run an unsigned COM add-in, the Require Application Add-ins to be signed by Trusted Publisher and the Disable all Application Add-ins options must be cleared in the Add-ins tab in the Trust Center (click the Microsoft Office button in the upper-left corner of the application window, and then click <Application> Options, Trust Center, Trust Center Settings, Add-ins).

To run all VBA macros, including those that have not been digitally signed, the Enable all macros option must be cleared in the Trust Center (click the Microsoft Office button in the upper-left corner of the application window, and then click <Application> Options, Trust Center, Trust Center Settings, Macros Settings). It is strongly recommended that you do this only in a testing environment. After you have completed your testing, set the options back to their original state.

In the Macro Settings tab of the Trust Center, you can also set options to Disable all macros without notification, Disable all macros with notification, or Disable all macro except digitally signed macros. You can also disable macros by saving the Word document, Excel worksheet, or PowerPoint presentation as macro-disabled files (.docm, xlsm, or pptm, respectively). You can also set or disable access to the VBA project object model from the Macro Settings tab by selecting or clearing the Trust access to the VBA project object model option.

Note
On the new Ribbon user interface (UI), when COM and application-specific add-ins are enabled and loaded, their UI is displayed on an Add-ins tab.

You can see a list of available add-ins on the Add-ins tab in the Trust Center. On the same tab, you can enable, disable, add, or remove COM or Word add-ins by selecting the type of add-in in the drop-down boxt by the Manage label and then clicking the Go button.

About Modifying the Microsoft Windows Registry

Modifying the Microsoft Windows registry in any manner, whether through the Registry Editor or programmatically, always carries some degree of risk. Incorrect modification can cause serious problems that may require you to reinstall your operating system. It is always a good practice to back up a computer's registry first before modifying it. If you are running Microsoft Windows NT, Microsoft Windows 2000, Microsoft Windows XP, or Microsoft Windows Server 2003, you should also update your Emergency Repair Disk (ERD).

For information about how to edit the registry, view the "Changing Keys and Values" Help topic in the Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Information" topics in the Registry Editor (Regedt32.exe).

About Making Microsoft Windows Application Programming Interface (API) Function Calls

Before calling Microsoft Windows functions, you should understand how arguments and data types are handled by the Windows API DLLs. Incorrectly calling Windows functions may result in invalid page faults or other unexpected behaviors. For more information on calling Windows functions, see the topic "The Windows API and Other Dynamic-Link Libraries" in the Microsoft Office 2000 Developer Online Documentation or the Microsoft Developer Network (MSDN) Library.

About Digital Code Signing

Digitally signing a document is the process of "stamping" a document so that the recipient of the document can be assured that it came from a particular source, and can detect whether the contents of the document have changed since the document was signed. Additionally, digital signatures can be used to mark a document as read-only to protect its authenticity and integrity.

In addition to digital signatures, documents can also contain in-document signatures that are visible in the document's content. The originator of the document can create unsigned documents with signature lines that can be transmitted to the recipient to sign. The recipient opens the document, locates the signature line, signs the document, and then returns it to the sender.

Basically, the steps to digitally sign a document include:

  1. The document's originator compacts the document's content into a few lines by using a process called "hashing." The compressed content is called a message digest. Hashing is performed by software created for that purpose.
  2. The document's originator then encrypts the message digest by using a private key obtained from a signing authority. The result is a digital signature.
  3. The originator attaches the digital signature to the document. All of the data that was hashed has now been signed, the signature has been encrypted and attached to the document.
  4. The originator then sends the document to the recipient.
  5. The recipient first decrypts the document by using a public key received from the originator. This changes the signature back to a message digest. If this works, this proves that the document was signed by the originator.
  6. The recipient, using digital signing software, hashes the document into a message digest and compares this hash to the hash from the sender. If they match, this verifies that the contents of the document have not changed since the document was sent by the originator.

Digital signatures have been available to customers since Office XP. However, Office has added features that make it easier for users to (a) digitally sign documents, sign their documents to make them read-only, and add inline-document signature lines to a document. For users, these tasks can be performed from the Office user interface available from the Microsoft Office button.

Developers also have access to new Office members to work with in-line signatures and digital signatures programmatically. For more information, search the MSDN Library for "Office signatures."

About Secure Deployment of Managed COM Add-ins in Microsoft Office

To comply with Office security, managed COM add-ins (COM add-ins targeting the common language runtime) must be digitally signed, and users' security settings should be set in the Office Trust Center to allow add-ins in your Office applications. Additionally, you will need to incorporate into your managed COM add-in project a small unmanaged proxy called a shim to avoid unexpected security warnings. For details, search for "deployment managed add-ins" in the MSDN Library.

About Automating the Visual Basic Editor

In Office, when calling the features of the Microsoft Visual Basic for Applications Extensibility object model, you may receive an error message that programmatic access to the Visual Basic project is not trusted. To prevent this message from appearing, click the Office button, click <Application> Options, click the Trust Center tab, and then click the Trust Center Settings button. Next click the Macro Settings tab and then select the Trust access to the VBA project object model box. By checking this box, macros in any macro-enabled documents that you open can access the core Microsoft Visual Basic objects, methods, and properties, which represents a possible security hazard. The recommended behavior is to check the Trust access to the VBA project object model box only for the duration of a macro that accesses the Visual Basic object model. The Trust access to the VBA project object modelbox should be unchecked after the macro has finished running.

About Passwords

Avoid using hard-coded passwords in your applications. If a password is required in a procedure, request the password from the user, store it in a variable, and then use the variable in your code.

Always use strong passwords. Strong passwords should contain:

Strong passwords should not contain patterns, themes, or words found in a dictionary.

Examples of strong passwords include:

Note
You should change your password frequently; for example, every one to three months.

About Microsoft Office Security Settings

COM Add-ins Using Default Security

In Microsoft Outlook, all COM add-ins that run on a computer which is not configured to obtain security settings from a Microsoft Exchange Server are considered trusted by default. This implies that the add-ins that run on clients that are not Exchange clients and the add-ins that use default security in Exchange environments are trusted automatically. As in Outlook 2003, Outlook trusts only the main Application object that is passed to the OnConnection event of the add-in.

COM Add-ins Using Security Settings from an Exchange Server

There has been no change in the way Outlook trusts COM add-ins in an Exchange environment when the security settings are obtained from the Exchange server. An add-in will be considered trusted only if it's registered in the Security Settings folder. Again, as in Outlook 2003, Outlook trusts only the main Application object that is passed to the OnConnection event of the add-in.

For further information on changes and new security features in Outlook, search for the Microsoft Developers Network (MSDN) article Code Security Changes in Outlook.ofv