When locking down Office 2007 security settings via Group Policy I ran into an interesting issue with Trusted Locations. Office 2007 doesn’t support environment variables in those trusted locations paths. I managed to get it solved pretty elegantly, thanks to some posts and clues in random forums. What I didn’t find was any descent blog article or how-to guide for the solution. So here goes.
The Scenario and Issue
When designing a secure Office environment you want to limit the usage of macros, you want to disable all macros by default. Unfortunately, things don’t work if you just leave it to that. Office itself needs some macros to work and probably your users might have some documents with macros in them.
Office provides an easy (and lazy!) way. You can configure a “trusted location“, which is simply a path to some local disk or network location. Trusted location means “run everything in this location without asking any questions“. A better way is to require all macros to be signed by trusted publishers, which you decide of course. Both these ways can be configured using Group Policy.
What if you had stuff containing macros in a location that would require the use of environment variables? And those macros are not or cannot be signed (read: the writer won’t or doesn’t know how to). You go on and provide a trusted location via gpo and the path contains environment variables. You’re out of luck, Office 2007 doesn’t support that. If you provide a path like
%AppData%\SomeSoftware\Docs” or “
it won’t work. Those paths will be inserted into registry as strings and therefore, the stuff surrounded with percentage signs won’t get expanded or resolved. Office applications don’t know what
%AppData% means in a trusted location.
The key to the solution is the difference between
REG_EXPAND_SZ data types in registry.
REG_SZ doesn’t expand, but the
REG_EXPAND_SZ will! What I did was, I modified the Office Group Policy administrative template (
office12.admx) and change the type of the trusted location setting from
REG_EXPAND_SZ by adding the attribute “
expandable = true“, see XML-snippet below.
<policy name="L_TrustedLoc20" class="User" displayName="$(string.L_TrustedLoc20)" explainText="$(string.L_OfficeTrustedLocationsExplain)" presentation="$(presentation.L_TrustedLoc20)" key="Software\Policies\Microsoft\Office\12.0\Common\Security\Trusted Locations\All Applications\AllAppPolLocation20"> <parentCategory ref="L_trustcenter241" /> <supportedOn ref="windows:SUPPORTED_WindowsVista" /> <elements> <text id="L_pathcolon314" valueName="Path" expandable="true"/> <text id="L_datecolon315" valueName="Date" /> <text id="L_descriptioncolon316" valueName="Description" /> <boolean id="L_allowsubfolders317" valueName="AllowSubFolders"> <trueValue> <decimal value="1" /> </trueValue> <falseValue> <decimal value="0" /> </falseValue> </boolean> </elements> </policy>
Having done that, the value gets inserted with the new type into the workstation’s registry, and voila! Office gets the expanded (or resolved) value and hence, the proper, valid path to the trusted location (see screenshot below).
You could do the same with, for example, some logon scripts where those paths would be written to the registry, but the maintenance of them would be a nightmare. The way desrcibed in this article, all configuration is done where it should be done, in the GPO.
As it turns out, the exact thing has been done in Office 2010 GPO’s, so what I’ve done here was quite alright.