Guidance on Deployment of MS15-011 and MS15-014

Article
02/22/2015

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.

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.

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.

How will the updated Windows clients behave when communicating with Windows Server 2003 or Windows Server 2003 R2 Domain Controllers or Windows Server 2003 or Windows Server 2003 R2 file servers (Non-Domain Controllers)?

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 notsupported 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 -

\\fileserver\* RequireMutualAuthentication=1, RequireIntegrity=1

\\fileserver.contoso.com\* RequireMutualAuthentication=1, RequireIntegrity=1

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

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

\\fileserver.contoso.com\* alone would protect access to \\fileserver (because it might be \\fileserver.contoso.com) and \\fileserver.contoso.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 notcumulative. 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.

Keith Brewer and Ajay Sarkaria

Guidance on Deployment of MS15-011 and MS15-014

Read more about these updates here:

Frequently Asked Questions: (FAQs):

Additional resources