IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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:
Computer Configuration/Administrative Templates/Network/Network Provider: Hardened UNC Paths
Complete details on configuring the setting can be found here
If you have computers running Windows Vista or Server 2008, it is recommended to install the following hotfix before you install MS15-011
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 share
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 not supported to use wild char combinations (or regular expressions) for path names like:
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 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.
Keith Brewer and Ajay Sarkaria