I have an Excel tool (xlsm file) I'm spreading to users, they download the file from our site and after that can use it. In a nutshell:
the tool has its own menu bar and a bunch of macros that e.g. do calculations, pull in data from an API, etc.
I use Unviewable to hide the code from the users
I sign the VBA project with a certificate
Last month, an user reported having issues running the tool and passed it on to his IT department. They came back with several ASR rules they had to switch off to make the tool work (all macros etc). They were reluctant to do so because of "general virus threats". These were the 3 rules they had to switch off:
Attack surface reduction (ASR) rules reference
Block Win32 API calls from Office macro
Block execution of potentially obfuscated scripts (js/vbs/ps)
Block JavaScript or VBScript from launching downloaded executable content
https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide
So my question 1 is: I think the obfuscated scripts line has to do with Unviewable, but have no idea what can cause the other 2 items in that list. Does anyone have an idea? Maybe some references in my project?
And the second question: as I signed my tool with a certificate, wouldn't that for that IT department be a fix - just allow macros that are signed (and add my certificate to the trusted publishers in Excel)?
Related
I am trying in our installer to add a macro that is available to every worksheet. What we presently do in our wix installer is (both 32-bit & 64-bit):
msOfficeApp.Workbooks.Add
msOfficeApp.Workbooks.Open (Session.Property("ExcelMacroLoc") & "AutoTagExcelMacro.xla")
msOfficeApp.Workbooks("AutoTagExcelMacro.xla").RunAutoMacros 1
...
<Property Id="ExcelMacroLoc" Value='C:\' />
<CustomAction Id="AssignExcelMacroLoc" Return="check" Execute="firstSequence" Property ='ExcelMacroLoc' Value='[INSTALLDIR]'>
</CustomAction>
This works sometimes, but not always. Oftentimes we get some or all of the below. What is the best way to tell Excel where this VBA script is and that it's ok to use in any worksheet?
I think the issues/questions are:
Is there anything in this macro (AutoTagExcelMacro.xla) that needs to change (written in 2000)?
Should the file's extension be changed to .xlam? And does that require any other changes?
How do I digitally sign the xla file?
How do I figure out where Excel is installed (to know where to install the macro)?
How do I determine the bitness of Excel (GetBinaryType does not work).
Is there anything else I need to do besides copy the xla file to the appropriate folder?
Also asked on MSDN (I'll post any answer from there here).
" #ProfoundlyOblivious Could you please post an answer telling us how to do each part best - digitally signing, trusted location, etc. and what/where we should tell people to look for macros being disabled? – David Thielen "
Disclosure: I am not an expert in software deployment, my knowledge is limited to the obstacles I encountered sharing my VBA solutions among peers on IT managed networks.
Note: The dialog boxes in your post do not all originate from the same cause. The first relates to security and the others to file availability.
Security
Macros have been, and still are, used in the development and circulating of malicious software. As a result macros are disabled by default and require user interaction to run.
Macro Security Settings
Macros are enabled through the Trust Center, which is accessed through the file menu. These settings are independent for each Office application and some applications may have additional options involving the suppression of a dialog box. Such as Excel where all macros may be disaabled without notification or all macros may be disaabled with notification. There are three basic settings for all Office applications summarized as:
Disable all macros
Disable all unsigned macros
Enable all macros (Not Recommended)
I strongly recommend that one does not enable all macros. It may achieve a desired result but I believe the risk is far too great to warrant the consideration.
Digitally Signed Macros
A digitally signed macro in and of itself simply means the underlying code has not been changed by anyone since last saved by the signer. If the signer's certificate is installed on a computer as a trusted publisher then macros signed with that certificate can run without notification under the requisite macro security setting.
In corporate environments, IT may retain a library of certificates and there may be an established procedure for an internal developer to submit a project for wider circulation, whereafter IT signs the project so it can be run with minimal intervention.
In my experience however, I have found many companies do not have an SOP for this process or that the process is prohibitively onerous. At such times, I turn to self-signed certificates. A self-signed certificate if miraculous for personal development because it provides ample flexibility without incurring the risk if allowing unsigned code to run. The problem, of course, then comes with sharing your code because the recipient will not have your certificate installed. They could install my certificate but my personal preference is that I send an unsigned project and they create a certificate and sign the project themselves. This is an easy step-by-step process that requires no skill beyond the ability to follow instructions.
Trusted Location
A document saved in a trusted location can run macros without notifications. Trusted locations are added in the Trust Center.
By default, XLStart is a trusted location
File Availability
When Excel is opened, it will try to refresh links to other data sources and add-ins. Those files must be open for a successful refresh and a dialog box will appear if the refresh fails.
Based on little more than experience and deduction, I believe this message is often semi-erroneous and driven by either the lack of a time out timer or too short of one. I have tested this with a simple worksheet and a simple add-in. The message pops saying the link could not be updated but it was open and updated by the time I manually check the status of the connection.
In other words, the dialog box was an iritation that served no value.
There is an option that suposedly offers some control over the "Links Could Not Be Updated" window with options along the lines of:
Update links and notify
Update links and do not notify
I have found these settings unreliable and prone to resets from crashes and updates.
To the best of my knowledge, the most assured way if avoiding this type of warning is to install the add-in after Excel is stable and uninstall the add-in before Excel closes. Of course this comes with it's on set of problems including a user perceivable slower loading time.
I would like to know how I can achieve the following:
Have Excel open without the request to "Enable Macros" for an Excel sheet that is distributed as a template and filled in by many, to then come back to a script of mine that wants to read the contents of the Excel sheet (Macros are only there for the users).
Any actions that require me to perform a change to my own installation of Excel (such as adding the file to the trusted docs), won't work, since the computer that runs the script, can be any of a 1000 computers that contains the automated script.
Signing the Excel sheet (something I read here, could solve the issue), is fine, but I would like to know how to go about his, when operating from within an enterprise, governed with a lot of security regulations.
I don't have access to alter the trust center settings, nor can I click the "enable macro's" button every time...
All help is welcome.
The simplest solution is to store the template in a "Trusted Location" - that is a folder on your network where macros are allowed. You can either set the template's current location as trusted, or move the template into an existing trusted location. Your IT dept should be able to set up such a location if they don't already have one enabled in people's profiles. You'll have to talk to your IT dept because it's unlikely your users can alter this setting themselves.
Fortunately noone can do this. If it was allowed to automatically prevent the "Enable Macros" security warning pop-up, this would have been a huge security issue:
However, you may contact the people using the template and ask them to enable all macros from the Trust Centre:
This is how to navigate to the Trust Centre in Excel:
Microsoft Office Button
Excel Options
Trust Center
Trust Center Settings
Macro Settings
Enable or disable macros in Office files
Vityata's solution only works if your enterprise security policy allows trusting network drives. It doesn't work in our environment as our security policy disables trusting network drives.
I handled the issue on a much smaller scale by self-signing the macros and installing my cert on the client's computers. I only have a few clients that use the scripts I write so it's not a big deal for me.
However, to do this at scale would require your IT dept to distribute your cert via their Windows update mechanism. You have to have admin access to your machine and a second as a test platform for this to work.
The steps you would take would be:
Create your self-signed cert.
Sign the macro.
Test it works on another machine by installing your cert on the other machine and running the macro.
Send the cert to your IT dept for them to distribute.
Send the spreadsheet to your clients.
I'm working on an alternative approach of setting our department up as a certificate authority and issuing properly signed certs internally for our own use. We have a plethora of devices that don't have fully qualified domain names assigned to them because the network group doesn't want to deal with the overhead of maintaining thousands of certs. As you might imagine, it's a project to get all the pieces in play so that one person can handle it.
I have a Windows 2003 Server box with Excel 2010 installed, upon which I am unable to create new or execute existing macros in spreadsheets. Note: this machine is in a Windows Domain (and I am not getting much help from the network folks here.)
I can and have edited the macro security levels within Excel (File, Options, Trust Center, Macro Settings --> Enable All Macros) but despite this, when I try to:
Open a spreadsheet with macros, I get an exception "Excel found unreadable content...." which goes on to refer to the VBA macros within the spreadsheet
Create a new macro in a brand new spreadsheet created on this machine, all the toolbar buttons providing access to the VBA editor are disabled.
Could this be a Group Policy setting that allows me to edit the macro security settings, but overrides these settings and prevents me from actually creating, editing, or executing VBA macros? (If so, does anyone happen to know which group policy setting I should be looking for?)
I've run rsop.msc (Resultant Set of Policy) on the machine and looked through every single thing under both Computer Configuration and User Configuration, but I don't see anything related to Excel (or Office) Security/Macros.
In this case, the problem was that Visual Basic for Applications hadn't been installed when Excel itself was installed.
(As usual, Microsoft could do a much better job of alerting the user to this unusual configuration, but what can you do.)
Is it possible to create a certificate for an Excel workbook which has some VBA macros, and distribute the certificates to a small group of users?
Remou's answer is spot on, but be aware though that, dependent on the user's security settings, self-certified projects might only replace the standard macro security warning with another about self-signed projects - not exactly a win in my book as it can confuse already wary users.
In a small group this may not be an issue, but then neither should asking them to click 'Enable' to the standard dialog...
The only way to completely get round this is to purchase a full-fat signing certificate - $$$
This may be of interest: Self Certify projects
with the push to leverage visual studio and dotnet with office based solutions, especially excel, where is the best article or information on how having office sheet with additional binaries and assemblies is sharable.
Do this external code get packaged with the spreadsheet
what if people start emailing the spreadsheet around. Is there any overhead of this additional assemblies. Is there risk of the binaries getting detached from the spreadsheet
It seems like microsoft has been pushing VSTO for over 5 years now but you read lots of mixed reviews and issues. Are we at the point where companies that do large VBA excel solutions can fully migrate over to dotnet without any real worries?
First of all, I want to answer your question on whether or not VSTO is ready for larger implementations. The answer is YES! Especially if the alternative is VBA. You have the entire .Net framework available, you can use web services, ADO.Net (better still, with the enterprise library). You can still write code that looks a lot like VBA, but is much more powerful. You can get more information by reading Walkthrough: Creating Your First Document-Level Customization for Excel. This page will give you an idea of what VSTO features are available to you.
Now, to answer your question on deployment.
It depends on whether you are making an Add-In or a document level customization. If its an Add-In, then you must install it on each client, and any passing around of documents will not effect that (Add-Ins are at the application level, and not at the individual document level).
I assume that you are talking about a document level customization, so I will center my answer around that.
When you create a document level customization, the assemblies are not loaded into the excel file (as they are with VBA). Instead, a document property is added telling the application that this document contains a manifest file (and tells it of the manifest file's location). The manifest file contains links to the assembly that makes up your customization.
As with any .Net application, there are sometimes other (referenced) assemblies that also need to be deployed. Not always are these assemblies in the GAC, so they would have to be located in the same folder as your executing assembly (in this case, your customization assembly). You don't necessarily have to place your assemblies in the same location as your excel file, though.
There are a few ways you can deploy the customization.
You can store all of the assemblies and the excel file in a folder and run the application that way (if the excel file is passed around, the users must pass around the entire folder).
You can run an setup program that installs the assemblies to a specific folder on the users computer, and specifies the manifest at that location (if the excel file is passed around, the users must also pass around the setup program).
You can install the assemblies in a network location and specify in the document properties, that the manifest and the assemblies are all at that network location (if the excel file is passed around, nothing needs to be passed along with it - but there are security settings that need to be made. Read this page for more information).
Any way that you decide to do this, here is the page you need to read in order to understand the document properties that enable the customization.
You need to make sure all of your users have the prerequisites installed. The easiest way to do this is to give them all a setup program. If you create a setup project for your customization, you can setup the bootstrapper to automatically install the prerequisites. You can also do this if you use ClickOnce to install the customization. This page will give you all the information you need to know regarding deployment.
Here are some other helpful links you will need to see:
Application Manifests for Office Solutions (2007 System)
Deployment Manifests for Office Solutions (2007 System)
Application and Deployment Manifests in Office Solutions
I hope this helps. Once you read all of this information, I think you'll agree that VSTO is a much better choice than VBA. You just have to plan your deployment carefully.
I created a Excel add-on and deployed it to a server. Then I passed around two links, the setup.exe file and the link to the actual Workbook. The workbook file never changed - it's purpose was to open and load the add-on which was now in the user's Add/Remove Programs. The add-on itself would check for updates on startup.
So if they start emailing the workbook around, great! I believe in theory, the workbook would download the add-on if it was missing, but I don't have a fresh computer around to test that. If it doesn't, it's just a simply exe to install (which will update on launch anyhow, so outdated isn't an issue).
For document-level deployment, I recommend the following three links:
https://msdn.microsoft.com/en-us/library/ms268758(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff937654.aspx
How do you assign the Assembly Location of an Excel VSTO Installation?
Unlike application-level solution, document-level has 2 special properties: _AssemblyLocation and_AssemblyName, which indicate the *.vsto position. To set these properties by install path, a custom action project should be created to record the target path when installing, and packaged together with setup.exe. Then you could put your excel file anywhere (on local machine) and open it in the correct way.