Guidance on Deployment of MS15-011 and MS15-014

Hi, my name is Keith Brewer and many of you will know of me from my other Active Directory related posts. A few folks have recently approached me about the recent security updates (The other week we released MS15-011 & MS15-014). Most of the questions were general in nature but a few were specifically in relation to the interoperability between updated and non-updated systems. In this post I am hoping to deliver you some of the FAQ’s we have encountered and hopefully help you to better understand and deploy this important set of updates.

What about Windows 10?: It is important to note that UNC hardening is enabled by default in Windows 10 for Netlogon and SYSVOL. Registry keys are NOT present by default even when UNC hardening is enabled unless UNC hardening settings are being configured via group policy.

As you know these updates harden group policy and address network access vulnerabilities that can be used to achieve remote code execution (RCE) in domain networks. The MS15-014 update addresses an issue in Group Policy update which can be used to disable client-side global SMB Signing requirements, bypassing an existing security feature built into the product. MS15-011 adds new functionality, hardening network file access to block access to untrusted, attacker-controlled shares when Group Policy refreshes on client machines. These two updates are important improvements that will help safeguard your domain network.

Read more about these updates here:

MS15-011 is not turned on by default. It requires administrators to turn on Group Policy setting to harden specific SYSVOL and NETLOGON shares to protect enterprise deployments from the RCE vulnerability

After the MS15-011update is installed, the following new Group Policy Setting can be used to harden specific shares:

Frequently Asked Questions: (FAQs):

Do I need to install the update on only Windows Client OS or even Windows Server OS?

We recommend you update all Windows clients OS and Windows Server OS, regardless of SKU or role, in your entire domain environment. These updates only change behavior from a client (as in “client-server distributed system architecture”) standpoint, but all computers in a domain are “clients” to SYSVOL and Group Policy; even the Domain Controllers themselves

Do all my clients and servers need to be updated before configuring/enabling the UNC Hardened Access feature?

The feature and the configuration settings live completely on the client-side. Configuration is applied via Group Policy, but the settings do not take effect until after the GPO containing the settings is applied to the client. The update was designed in an interoperable way so that mixed-mode environmentswith updated servers and non-updated clients (or vice versa) continue to work as before.

What are the potential impacts of rolling out the GPO at the domain level to require hardened access to the \SYSVOL and \NETLOGON shares? There may be some clients that are not updated initially, or are but don’t get the new GPO settings before the Domain Controllers are set to use them?

Test first before performing a broad deployment. If your Windows domain controllers accidentally have a firewall policy set that blocks incoming Kerberos traffic, then clients will be unable to mutually authenticate the domain controller and will be unable to apply future Group Policy updates until the firewall policy is corrected or the UNC Hardened Access configuration is manually removed. Similarly, clients that attempt to connect to a Domain Controller through a WAN link may have issues when SMB traffic over the WAN link is forced through a 3rd party SMB WAN Accelerator that does not support Kerberos or SMB Signing.

What about a Windows client that has the settings enabled, but the UNC shares are located on a network device that is not Windows based?

For Windows clients communicating with 3rd party SMB Servers, compatibility depends on the policy settings configured by the system administrator and the protocol version and/or optional protocol features supported by the 3rd party SMB Server:

· If the administrator has configured a path to require Integrity, but the 3rd party SMB server is an SMB1 server that does not support SMB Signing, Windows will disallow the connection (SMB Signing is an optional protocol feature in v1, but is required in v2+)

· If the administrator has configured a path to require Privacy, but the 3rd party SMB server does not support SMB Encryption, Windows will disallow the connection (SMB Encryption is only supported in SMB v3+)

· If the administrator has configured a path to require Mutual Authentication, but the 3rd party SMB Server does not support Kerberos (or the client is unable to find appropriate Kerberos credentials), Windows will disallow the connection.

By default all Windows domain controllers are configured to require SMB signing on all shares hosted on the Domain Controller via the Default Domain Controller policy. Updated or “hardened” clients while being protected will still be able to apply policy from a Windows Server 2003 or Windows Server 2003 R2 Domain Controller.

If you have shares hosted on Windows Server 2003 or Windows Server 2003 R2 (Non-Domain Controllers), then you must ensure the policy “Digitally sign communications – always”is enabled on these servers for the updated clients to be able to access the shares.

Will an updated Domain Controller experience issues when replicating the SYSVOL replica set when the partner is Windows Server 2003 or Windows Server 2003 R2 (or vice versa)

Same as above. Domain Controller(s) mixed between updated and non-updated will not experience FRS or DFSR replication issues related to the application of this update. SYSVOL replication uses RPC, not SMB.

What if we have disabled SMB signing requirements on the Domain Controllers?

That is against best practice and certainly not recommended. See “What about a client that has the settings enabled, but the UNC shares are located on a network device that is not Windows based?” FAQ earlier for expected behavior.

Configuring the policy as recommended in MS15-011when (if) the Domain Controllers are configured with SMB signing disabled could cause one to lose control over the machines through group policy (especially if the clients can’t access NETLOGON/SYSVOL – then they won’t get the new modified/reverted policies. The clients will need to have the update uninstalled or the registry is pruned manually).

What if an application only supports NTLM authentication and accesses data kept on the SYSVOL or NETLOGON share?

Once the client is updated & hardened as recommended in MS15-011, Specifically the Mutual Authentication = 1, Kerberos will be required to make a successful connection to the NETLOGON/SYSVOL shares.

If you OR your application will access shares by using the IP Address of the Server, that will use NTLM and will cause failures.

How do we get the Group Policy settings into the central store?

Copy the modified networkprovider.admx(l) files from the system on which the update is installed to the central store location.

The admx files are available on the machine in c:\Windows\policydefinitions and the corresponding adml files are available in c:\Windows\policydefinitions\<lang>\

(For en-us it is: C:\Windows\PolicyDefinitions\en-US)

What kind of wildcards are supported when configuring the new Group Policy Setting?

· \\<Server>\<Share> – The configuration entry applies to the share that has the specified name on the specified server.

· \\*\<Share> – The configuration entry applies to the share that has the specified name on any server.

· \\<Server>\* – The configuration entry applies to any share on the specified server.

· \\<Server> – The same as \\<Server>\*

Note: Is it not supported to use wild char combinations (or regular expressions) for path names like:

· \\*share*\*

· \\*\*share*

A specific server or share name must be specified. All-wildcard paths such as \\* and \\*\* are not supported

If we were going to add a file server to the UNC list, would we need to add both the FQDN and the Netbios name to be protected? For example would we need to add –

No, only one of the two configuration entries is necessary (Either FQDN or Netbios)

\\fileserver\* alone would protect accesses to \\fileserver, \\fileserver.fabrikam.com, and \\fileserver.contoso.com

\\fileserver.fabrikam.com\* alone would protect access to \\fileserver (because it might be \\fileserver.fabrikam.com) but not \\fileserver.contoso.com (because the latter is clearly not the configured UNC path).

If the new group policy setting is configured at the domain level and also at the OU level, which will take precedence?

The OU policy would override the domain policy. The order of precedence is given here:

First local, then site, then domain and the OU (LSDOU). That last one wins.

The policy is not cumulative. It overrides the existing ones. In this particular case, you will need to add the NETLOGON & SYSVOL shares to the OU policy as well.

Many Thanks to Supportability Program Manager Ajay Sarkaria for helping putting together this information.

Join the conversation

Thanks @ Chris Puckett, We have just updated the blog with guidance on installing the Windows Vista/Server 2008 update(http://support.microsoft.com/kb/2272153) prior to installing the update & configuring
the hardened shares for Vista/2008 machines. The Windows 7/2008R2 update(http://support.microsoft.com/kb/982860) is included with SP1 so as long as your Windows 7/2008R2 machines is at least SP1 no action
should be required.

Perhaps my use of the term “conversation” has led to some confusion and for that I apologize.

If you are asking in general, Is a server response to a client connection requiring mutual authentication different then a server response to a client connecting without requiring mutual authentication? The answer is yes. The server response will be different.

However to be clear no update or change in configuration is/was required for any Windows machine to respond to a Kerberos client connection requiring mutual authentication.

Prior to MS15-011(and post MS15-011 without the GPO configured) when a client attempts to connect to a share hosted on a server, mutual authentication is not a requirement
Prior to MS15-011 there was no way to configure a client making a connection to a share to require mutual authentication.

So while my statement in the article “The feature and the configuration settings live completely on the client-side” is entirely correct from a code/configuration standpoint, the response that a server will have to a hardened client (MutualAuthentication=1
for share hosted on server) will be slightly different.

Thanks for your comment. Here is some more information on Mutual Authentication:

Mutual Authentication is a security feature in which a client process must prove its identity to a server, and the server must prove its identity to the client, before any application traffic is sent over the client-to-server connectionhttps://technet.microsoft.com/en-us/library/cc961730.aspx

Mutual Authentication is not a new feature. The use of the term “Mutual Authentication” is not specific to this update but within the scope of this update describes a new configuration capability to require Mutual Authentication.

When an application or service attempts to access a file on a UNC path, the Multiple UNC Provider (MUP) is responsible for enumerating all installed UNC Providers and selecting one of them to satisfy all I/O requests for the specified UNC path. On a typical
Windows client installation, MUP would try the Server Message Block (SMB) protocol first, but if the SMB UNC Provider is unable to establish an SMB connection to the server, then MUP would try the next UNC Provider and so on until one of them is able to establish
a connection (or there are no remaining UNC providers, in which case the request would fail).

Once the update is applied, Each time MUP receives a request to create or open a file on a UNC path, it evaluates the current UNC Hardened Access Group Policy settings to determine which security properties are required for the requested UNC path.

The update facilitates the ability for an administrator to configure MUP to request additional security features of the UNC provider that prior to this hotfix was not configurable. These Security features options being:

1.) Mutual Authentication
2.) Signing
3.) Encryption

In order to be considered the UNC provider must first support the configured security feature(s) and then if selected will negotiate what authentication protocol should be used between the client and server. If the Hardened Access Group Policy settings contains
configuration information for the requested UNC path and has been configured with MutualAuthentication=1, Kerberos would always be negotiated.

This update (ability for MUP to require additional security features) and recommended configuration (hardening of SYSVOL/NETLOGON) is completely implemented in the client side of this conversation. There are no changes implemented in this update to the server
side of the conversation.

I hope this further explains the use of the term “Mutual Authentication” within the scope of this update and clarifies how the update is implemented completely from the client side of the conversation.

What you are seeing is due to SMB connectivity. When a SMB connection is made (during startup, initial guess would be group policy application), CIFS connectivity is used (CIFS is basically another name for SMB). CIFS itself can be covered by a direct cifs/
SPN or by the HOST/ SPN.
In regards to the disjointed namespace; IF the SPNs are registered with your actual domain name instead of the disjointed name defined on the machine, then Kerberos can fail IF calls to that machine resolve to the disjointed name. However, machines will typically
register their disjointed SPN, so as long as you have a DNS zone for the disjointed name hosted on the DNS server your environment is pointed to, then it should resolve correctly, and there shouldn’t be a problem. That might be easily identifiable in your
data set by reviewing if the cifs call was to a FQDN (which in the case of startup, likely was), and if that FQDN matches your disjointed name, then you shouldn’t have a problem.

Per MS15-011 (http://support.microsoft.com/kb/3000483), “This security update is offered through Windows Update only to domain-joined computers. DLC and WSUS customers should apply this security update only
to domain-joined computers.”

For most environments the RequireIntergity=1 setting should not manifest from a client perspective a change in behavior as by default all domain controllers are already configured on the server side to require SMB Signing for connections to NETLOGON/SYSVOL
via “Digitally sign communications – always”.

So when we focus in on MutualAuthentication=1 this is really the behavioral change as now connections that used to be able to fall back to NTLM now are required to use Kerberos.

There are a number of configuration issues that may contribute to why Kerberos Authentication may be failing which is why I would recommend to begin troubleshooting there. Please use whatever methods are appropriate for you and your business to track down the
Kerberos failures up to and including opening a case with Microsoft Support.

For anyone receiving the Event ID error 1058, installing the appropriate update below on the affected client should resolve it.

Windows Vista and Windows Server 2008
KB 2272153 – It takes four minutes for a computer that is running Windows Vista or Windows Server 2008 to open a Microsoft Office 2003 document from a network sharehttp://support.microsoft.com/kb/2272153

Windows 7 and Windows Server 2008 R2
KB 982860 – A computer that is running Windows 7 or Windows Server 2008 R2 takes four minutes to open a Microsoft Office 2003 document from a network sharehttp://support.microsoft.com/kb/982860

If only Mutual Authentication is required and the connection is failing with STATUS_NETWORK_ACCESS_DENIED, then the client is likely experiencing issues with Kerberos authentication.

You need to identify why Kerberos authentication is not being utilized. If you can repro this issue by running “gpupdate”, a network trace may help during that time as a start. It could be anything from DNS configuration errors, firewall configuration errors,
Kerberos SPN configuration errors, etc.

You could also post your specific issue to the Directory Services Forum for additional troubleshooting advice.

Still not clear at all… Bulletin recommends applying GPO for Netlogon with "Mutual Authentication". Mutual Authentication sound like BOTH sides. But you write >>There are no changes implemented in this update to the server side of the conversation. <<
This does not add up. Is the "mutual auth" setting ignored for Netlogon, but used for other shares? The word "mutual" implies something happening on both sides. But what you say is that its one side only. Yet another GPO setting that sounds like one thing,
and does something different.

@Sunny,
A time skew of >5min would certainly cause issues with Kerberos Authentication. I would not expect the setting of MutualAuthentication=1 and/or RequireIntegrity=1 to cause a time skew.

If the domain member was not reliably obtaining time (experiencing time skew of >5min) and then SYSVOLNETLOGON where hardened (MutualAuthentication=1) you are likely to experience issues accessing those shares.
If you are experiencing time skews between domain members and the domain controllers, I would highly recommend opening a support case with Microsoft to assist with troubleshooting and determine what is going on.

I’m having problems when enabling this GPO settings. I only enabled RequireMutualAuthentication on the sysvol & netlogon share but clients are random failing to process the gpo settings at startup. (After a couple of minutes it works, but not initially)

I have the feeling that because of the smb signing and authentication it takes a bit longer to get connectivity and because of that gpo processing failes at startup. Not always, but sometimes.

All in the same internal lan, OS client is W7 fully patched, server is 2012R2.

I have several stand-alone 2008 servers (not a "domain-joined system" or a "domain controller") and Microsoft Updates does not install the patches, and neither do our manual install attempts of KB3000483 & KB3004375 — both give error "The update does
not apply to your system."

Many thanks for the article, I was wondering on how many cases MS have seen on client side SMB signing being disabled or is this a preventative fix for perceived possible issues? I am trying to decide whether to implement or not with all of the testing
that would be required against existing apps. Thanks

There is certainly something going on with the setting that we need to apply after MS15-011 is installed. Just like "Sander", we are seeing issues on our 2008/2008R2/2012 clients after applying the minimum recommended setting for "Harden UNC Paths" (SYSVOL/Netlogon).
In our case we are also seeing Time skews (>5 min) when the setting is applied. I can re-produce the problem at any time (by merely applying the setting locally on a client (domain joined)).

I’m attempting to create an analysis on the actual impact of this setting as well as where it’s implemented in our environment. The KB article says this does not create a setting in the registry that can be read so I was wondering if there was a way through
WMI? I’ve been pouring over the namespaces for the last couple of hours but I can’t see it. Any ideas?

Thank you for your recommendations, Keith.
I find that event 1058 with errorcode 65 reliably pops up when the computer boots with wired dot1x authentication.

When it boots on a network interface which doesn’t require authentiation, the error doesn’t show up.
I suppose the small network connection delay introduced by dot1x authentication might have an influence. I’ll look further into this.

"Mutual authentication" implies that new feature affects the client side AND the server side. You write here the hotfix only affects the client side of the connection. Is there really anything mutual here? Seems like a bad choice of words.

We’ve run into issues similar to the ones described by Sander. The policy fails to apply on boot, but applies correctly on a gpupdate. Kerberos authentication works correct in every other case we are aware of.

For some reason, during startup, the client requests a kerberos ticket for "cifs/" which seems to imply that it has failed to realise that it is attempting to access a DFS path or something of that nature. (I’ve not come across that SPN being assigned to any
account in an AD domain. I was under the impression that if it knows it is talking to a DFS root, the client should find an appropriate SPN for the server it is using.)

Our domain has a NetBIOS name that is not the same as the final label on the DNS domain name. I’m wondering if this might be a contributory factor?

The problem we are seeing is that the SPN it’s attempting to get a ticket for is the equivalent of cifs/consoto.com (to use the microsoft example) and not for a specific server. All the Domain controller SPNs are correctly registered for their own FQDN, but
I’m not aware that any account should be registering something like cifs/contoso.com or host/contoso.com?

I’m pretty sure GP is the application requesting files that generates these issues. A procmon boot trace of group policy shows a hexadecimal error code 0x00000201 I think) accessing group policy files on sysvol once the HardenedPaths key is present. As soon
as the mutual authentication requirement is removed from that key, the error ceases, but this is not a secure configuration.

Resolution:- Suggested to edit the GPO for UNC hardening and change value of RequireMutualAuthentication & RequireIntegrity to 0 from 1 (previous value) for path \*NETLOGON & \*SYSVOL. We have confirmed that this is a known reported problem where we get
ErrorDescription Network access is denied. In event id 1058 and group policy processing fails for computers when KB3004361 is applied

In case you have problems applying scripts during login , then you can modify the UNC hardening GPO and edit path for \*NETLOGON with value of RequireMutualAuthentication & RequireIntegrity to 0

Our security consultant advised we would have to identify all UNC shares and apply the GPO accordingly for all those UNC shares. Is that true? There seems to be a lot of confusion about this patch, and I think MS could have done a better job with mitigating
this vulnerability. …not that it matters – we have to deal with what they have provided.

Our logon scripts (for mapping drives) are failing when connecting through VPN. We usually can run a script manually to connect them but that fails. I tried to implement a GPO to map the drives and when connected through VPN that does not work either. Any thoughts?

We have 2012r2 DCs in our environment and a mix of 2008sp2, 08r2, and 2012r2 MS. We have implemented UNC hardening with ﻿requiremutualauthentication=1, requireintegrity=1﻿ ﻿﻿ and it works for all systems other than our 2008 SP2 MS.﻿ However, it was working fine when we had 2008 DCs for all member servers. Now, on our 2008sp2 MS group policy fails because they are no longer able to access sysvol or netlogon on the DCs when mutualauthentication is required. I have been through ms15-011 & 015 with a fine tooth comb multiple times and have also installed 2272153, still get access denied.

Below are the spns and I am confused as to why the 08r2 and above ms’s are still communicating correctly with the authentication hardening enabled but not the 2008sp2’s. Is there a certain spn that the 08sp2’s are going to require with the hardening enabled that one of the below will not suffice?
HOST/fqdn of dc/domain
HOST/netbios of dc/domain
RPC/infoxyz._msdcs.forest
GC/fqdn of dc/forest
exchangeAB/fqdn of dc
HOST/fqdn of dc/domain name
exchangeAB/netbios of dc
ldap/netbios/domain
ldap/infoxyz._msdcs.forest
ldap/dc fqdn/domain
ldap/dc fqdn/domain fqdn
ldap/dc fqdn
ldap/dc netbios
E3514235-4B06-11D1-AB04-00C04FC2DCD2/a954d911-02f3-4286-9ec0-1dffb212282b/domain fqdn
Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/dc fqdn
TERMSRV/dc netbios
TERMSRV/dc fqdn
WSMAN/dc netbios
WSMAN/dc fqdn
RestrictedKrbHost/dc netbios
HOST/dc netbios
RestrictedKrbHost/dc fqdn
HOST/dc fqdn