The Office STIG Bureau Enterprise Configurations – Microsoft Office 2016/365 Security Policy v.3.0 includes both computer and users settings. The STIG was linked at the regional level on Tuesday, February 13, 2018. For sites that are still experiencing issues, a troubleshooting guide was sent to IT ALL on 2/20/18. Below is the summary of that email:
WHAT YOU NEED TO KNOW
We are receiving reports that some systems are having issues with Office 2016 and Office 365 since the Security Policies were applied on 02/13/2018. Working with sites, we have found several sources of issues. The purpose of this notification is to offer solutions for common issues. If the solutions below do not resolve your issues, please email the Service Desk and we will assist you.
We have also observed that many inconsistencies in behavior are the result of how hostnames resolve in the environment. Several teams will be working together to discuss additional configurations in the environment that might improve results. Below are some workarounds to help resolve gaps that may be present when DNS records do not resolve computers against a DNS suffix that identifies them as internal resources for communications in the environment. The failure of a computer to append a suffix such as gs.doi.net to a system in the DNS record and DNS system settings could result in trust issues between equipment. This notification will also contain some general best practices on DNS settings to be applied through DHCP.
WHAT YOU NEED TO DO
Please use the references below for more information:
- Update to Office 365 – This is a good fix for systems having macro issues with local files – We have received some reports of issues with files stored locally showing a red bar stating that Macros are blocked. This is not the expected behavior. All files should prompt the user to allow macros. If possible, please try to update to Office 365 on the system and test if this resolves the issue. We have seen that systems that have issues with Office 2016 may work after upgrading to Office 365. The SCCM application removes all previous versions of Office from systems and this process seems to reset problematic settings. By deploying the SCCM Office 365 x86 application as “Available” for all systems; users can choose to install as needed or when they are ready. Please remember to ensure all Visio and Project installs that are version 2010 or older have their license updated per previous guidance.
- File Save-As – This is a good fix for systems having macro issues with local and network files – We have received some reports of issues with files stored either locally or on a network share showing a red bar stating that Macros are blocked. This is not the expected behavior. All files should prompt the user to allow macros. We have observed that in this case opening the file, choosing file > save-as and renaming to a new name, and then closing and re-opening the new file resolves the issue. This process resets whatever is causing an issue with the file and users can then use the new file to proceed with their work.
- Fully Qualified Name (FQN) Path to Network Share – This is a good fix for systems having macro issues with network files – We have received some reports of issues with files stored either locally or on a network share showing a red bar stating that Macros are blocked. This is not the expected behavior. All files should prompt the user to allow macros. We have observed that in this case, changing the path to a fully qualified name fixes the issue. Please try to change the format of the network path from \\servername\share\filename to \\gs.doi.net\share\filename. If this works, please review the following options
- Update Mapped Drives to be FQN – If mapped drives are in place in the environment, updating the mapped drives through logon script or other automated process will allow users to access the FQN path and resolve most network macro file issues.
- Add Network path to Intranet Zone – DFS – Rather than having to update all DFS network paths to FQN and train users to add the extra suffix as they browse, the DFS name can be added to the Intranet Zone on the system by following the instructions outline here. The DFS name should be added in the format \\gs.doi.net\DFSroot and the Zone should be set to 1. A GPO has been created to set all DFS paths to the Intranet zone. If testing is successful, these settings may be linked to USGS at a higher level. Please feel free to link GPO ”BWTST – DFS Intranet Zone GPO” to resolve DFS FQN issues.
- Add Network path to Intranet Zone – Local server share – Rather than having to update all Local server network paths to FQN and train users to add the extra suffix as they browse, the Local Server name can be added to the Intranet Zone on the system by following the instructions outline here. The Local server name should be added in the format \\gs.doi.net (ex. \\igsbabewfs001.gs.doi.net) and the Zone should be set to 1.
- Deviation Requests – There will be situations where none of the above options work and there is something unique that is required by files. These situations may be solved with deviations. Deviation requests can be sent to the Service Desk. Deviation requests that can be solved with the above methods will not be approved. Here are a few deviations that are currently available based on specific need. Additional deviations may be created based on need.
- Access files use Switchboard and need Macro deviation – The current security settings require users to respond to a prompt to enable Macros. Access files that use a switchboard will block the user from seeing and responding to this dialog.
- Excel files require access to VB Project – The current security settings block access to Visual Basic Project. Excel files that are designed using this tool, will need to have access to VB allowed.
- Excel files do not execute Macros properly even when users accept the prompt to enable – For some spreadsheets with highly complex design, there are many layers of macros that even when the user allows them to run will result in the output of the file not running correctly. Excel files that do not produce the correct output due to highly complex design might require this deviation.
- DNS Best practices – The follow settings represent best practices for DNS in an environment. Every time a computer boots up in active directory, a DNS record is refreshed on the domain controllers.
- DNS Suffix – The default DNS suffix for computers should be set to doi.net
- Append DNS Suffix – The append DNS suffix field should have doi.net set as the primary option. Additional settings can be used as needed to support er.usgs.gov, cr.usgs.gov, and wr.usgs.gov
- Additional information about DNS will be sent out as it becomes available
For more information, see the Office STIG page.
