On February 10th 2015, Microsoft published Security Bulletin MS15-011, which detailed a recently discovered critical flaw in every major version of Windows from Server 2003 right the way through to Windows 8.1. The flaw, relating to how Group Policy handles data, potentially allows:

…remote code execution if an attacker convinces a user with a domain-configured system to connect to an attacker-controlled network. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

Microsoft was quick to release a corresponding security patch via the Windows Update service and each corresponding Operating System update can be downloaded and installed via the links below

Now, you may be asking at this point, why are you posting about this now in mid-2018? Surely the vulnerability has been addressed on all affected systems that are patched regularly? Well, as I found out very recently, this security patch is one of many released by Microsoft that requires additional administrator intervention after installation to ensure that the exploit hole is properly filled. The modifications required can be completed either via the Local Group Policy Editor for single machines not joined to a domain or Group Policy Management Console from a domain controller. The second option is naturally preferred if you are managing a large estate of Windows machines. Below are summarised steps that should provide the appropriate guidance on applying the fix for both environments

  1. Navigate to the Management Editor and expand and open up the Computer Configuration/Policies/Administrative Templates/Network/Network Provider folder path.

  1. On the right-hand pane, you should see an item called Hardened UNC Paths, marked in a state of Not configured. Click on it to open its properties

  1. There are then a couple of steps that need to be completed on the pop-up window that appears:
    • Ensure that the Enabled box is selected.
    • In the Options tab, scroll down to the Show… button and press it. The options at this stage depend upon your specific environment. For example, let’s assume that you have a domain with a file server called MyServer, which is configured for shared access. The most appropriate option, in this case, would be a Value name of \\MyServer\* with a Value of RequireMutualAuthentication=1, RequireIntegrity=1. Another example scenario could be that multiple Servers are used for sharing out access out to a share called Company. In this case, you could use the Value name option of \\*\Company with a Value of RequireMutualAuthentication=1, RequireIntegrity=1. Both of these examples are reproduced in the screenshot below, for your reference. Press the OK button to confirm the UNC path fields and Apply to make the policy change.

 

  1. The final step will be to enforce a group policy refresh on the target machine and any others on the domain. This can be done by executing the gpupdate /force Command Prompt cmdlet and confirming that no errors are generated in the output.

And that’s it! Your Windows domain/computer should now be properly hardened against the vulnerability 🙂

This whole example represents an excellent case study on the importance of regularly reviewing security bulletins or announcements from Microsoft. The process of carrying out Windows updates can often become one of those thankless tasks that can grind the gears of even the most ardent server administrators. With this in mind, it can be expected that a degree of apathy or lack of awareness regarding the context for certain updates can creep in, leading to situations where issues like this only get flagged up during a security audit or similar. I would strongly urge anyone who is still running one or all of the above Operating Systems to check their group policy configuration as soon as possible to verify that the required changes indicated in this post have been applied.

If you are heavily involved with the management and deployment of Office 365 Click-to-Run installation packages on a daily basis, the chances are that you have come across all sorts of weird and wonderful error messages throughout your travels. Although I am admittedly a novice in this area, I know there is oft the requirement to resort to registry modifications or similar to achieve certain kinds of management tasks, along with a whole list of other quirks that can test the patience of even the most ardent of IT professionals and frustrate what may appear to be simplistic Office 365 deployments.

Case in point – the installation of the downloadable Click-to-Run Office 365 installation package (available from the Office 365 portal) can be complicated when installing it via the default Administrator account on a Windows machine. When attempting to do this, either by double-clicking the executable file or executing it using Run as administrator privileges, you may get the following error message displayed below:

The error can occur in any version of Windows, up to and including Windows 10 1803 Build. The issue appears to pertain to the default Administrator account that is created on the operating system and can be observed occurring when creating a new Windows 10 Virtual Machine on Azure. It’s possible that the error may also occur in desktop versions of the operating system, depending on how the initial local administrator user account is deployed. There are a couple of ways to resolve this error, depending on your preferred method, familiarity with working with the inner engines of Windows and your inclination towards either a quick or “proper” solution.

The quick and easy solution

This route involves the creation of a new user account on the machine, which can then be logged into and used to install the application via User Account Control elevated privileges. The steps to achieve this are as follows:

  1. Type Windows + R on the start menu to open the Run box.
  2. Enter lusrmgr.msc in the Run box and hit enter. This will open the Local Users and Groups Microsoft Management Console (MMC) snap-in.
  3. Right-click on the Users folder and select New User
  4. Create a new user account with the required details and password. Ensure that the account is not disabled via the Account is disabled button and click Create to…well…create the account. 🙂
  5. Log out of Windows and log back in as the new user. When attempting to run the installation package again, you should be (correctly) prompted to enter Administrator credentials via the UAC control dialog and the installation should start successfully.

The proper solution

Although the above steps are perfectly acceptable and straightforward to follow if you are in a rush, they do not address the underlying problem with the default Administrator account – namely, that it will have issues installing any application that requires elevated privileges. In most cases, where an application requires installation onto a machine, it is generally better to login as the Administrator user account as opposed to relying solely on the UAC elevation prompt. As a consequence, the most ideal solution to save you from any future hassle is to fix the issue with the default Administrator account permanently.

Following some research online and testing on my side, I found this article which goes through the steps that will successfully address the problem and enable you to install Office 365 – and any other program – without issue. In my specific example, I had to follow the instructions listed in Method 2 and 3, followed by a restart of the machine in question, before I was able to install Office 365 successfully. Although the steps involved are a little more complex and error-prone, the article does provide clear instructions, along with screenshots, to help you along the way.

Conclusions or Wot I Think

I recently attended a Microsoft Partner training day covering Microsoft 365 Business and Enterprise and the topic of Office 365 came up regularly, as you can imagine. The deployment settings afforded to you via Microsoft 365 let you perform automated actions in a pinch, with perhaps the most common one being the removal of any local administrator privileges when a new machine is deployed using your organisation’s chosen template. As our instructor pointed out, this is incompatible with how Office 365 installations operate; because, as we have seen, full administrative privileges are required to install the software. We, therefore, find ourselves in this strange state of affairs where the Microsoft 365 solution as a whole is in a glass half full (or half empty, if you are feeling pessimistic) situation and, more generally, Office 365 deployments are hampered due to requiring local or domain level Administrator privileges. I would hope that, eventually, Microsoft would look to providing an installation package of Office that does not require such extensive permissions to install. Doing this would kill two birds with one stone – it would help to make the deployment of all the components of Microsoft 365 a breeze whilst also avoiding the error message discussed in this post. Here’s hoping that we see this change in the future to avoid interesting little side-journeys like this when deploying Office 365.