none
MS15-011 (KB3000483) GPO application (and installation) questions

    Question

  • I’ve been doing quite a bit of reading on the KB3000483 update and subsequent GPO deployment. What isn’t clear to me (and I can’t find an answer online) is if the update must first be deployed to both servers and clients for the security to work. That is, if the update has been installed on our domain controllers and we harden the UNC path \\*\sysvol for mutual authentication and integrity, will only clients that have the update installed be able to access files in the sysvol? And does that mean clients that do not have the update installed will not be able to access the sysvol directory? 

    Next question is where must the UNC hardening GPO be applied? Does it have to apply to both server and client, clients only or severs only? I realize the guidance on KB3000483 describes linking the GPO at the domain level but is that just because it's easy and comprehensive in that it applies to all domain computer objects (assuming policy is not blocked at a lower level.) 


    -- Jason

    Wednesday, February 18, 2015 8:38 PM

Answers

  • Thank you two for your replies. I ended up opening up a support case with Microsoft yesterday to get some clarifications. Here's a summary as I understood it:

    This isn’t as complicated as I initially thought in terms of scope of implementation. The important things to note are:

    • The concern is really focused on shares where executables run. Shares containing home directories are less of an issue because attackers are generally more focused on exploiting this vulnerability to run code/scripts without being noticed.
      • Therefore, in a domain environment, the sysvol and netlogon shares are the primary concerns because that’s where most user logon and computer start-up scripts are stored. Hardening the two UNC paths, \\*\SYSVOL and \\*\NETLOGON enhances security greatly and are really the main concerns.
    • This code and process is 100 percent “client” side driven. That is, the decisions and enforcement of the code is done by the “client” (the computer accessing the share). In a domain environment, “clients” are both workstations and servers because all systems are accessing the sysvol and netlogon shares while processing group policy. Therefore, installing the KB3000483 update on all systems is the best practice because all systems in the domain are “clients”.  Down-level systems like XP and non-Windows clients are unaffected by this update and new code. You can apply a UNC hardening GPO to XP clients or even newer clients that don’t have KB3000483 installed and no harm is done…the settings are simply ignored and those same clients will still be able to access the SYSVOL and NETLOGON shares as before—just not in the new, more secure manner.
    • Hardening UNC paths via GPOs is cumulative. That is, if we apply a UNC hardening GPO at the domain level to ensure sysvol and netlogon are hardened, OU administrators can create their own GPOs to harden UNC paths on their own servers and the end result on the client will be a cumulative list of hardened UNC paths. This is great news in a distributed support environment.
      • Even if the domain-level GPO is enforced, the lower-level OU GPO settings will still also apply to result in a cumulative list of hardened UNC paths on the client
      • The UNC hardening settings are stored in the registry on the clients at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
    • For each hardened UNC path, there are three types of security options. Mutual authentication, Integrity and Privacy.
      • Mutual authentication means the connection attempt must use Kerberos and cannot fall back to NTLMv2. If Kerberos cannot be used the connection will fail.
      • Integrity means SMB signing is required. If the client cannot negotiate SMB signing, the connection will fail.
      • Privacy means SMBv3 must be used. Only Server 2012 and Windows 8 support this. It is not recommend to use Privacy for now.
    • A valid test on a client to see if the installed update and GPO are working to harden a UNC path for mutual authentication is to try to access the hardened UNC path via IP address instead of server name. For instance, a hardened UNC path of \\*\SYSVOL  using RequireMutualAuthentication=1 will allow access via the path \\DC1\sysvol but will not allow access via \\192.168.1.1\sysvol This happens because in order for Kerberos to work the client must obtain a Kerberos ticket for the server to connect to. The client sends a request to the DC for a Kerberos ticket. Because the DC looks in AD to find a computer account with an SPN for the server name, using an IP address will fail because SPNs aren’t ever registered by IP address.  Therefore, using an IP address in a UNC path will always use NTLM and because we’ve set RequireMutualAuthentication for the UNC path, Kerberos is required and attempted access via IP address will fail. 


    -- Jason

    • Marked as answer by JasonBH Thursday, February 19, 2015 2:59 PM
    Thursday, February 19, 2015 2:59 PM

All replies

  • Hi Jason,

    Based on my understanding, it's recommended that we install the updates on all the computers which are listed in the Applies to section. Besides, as described in the KB article, we should link the UNC hardening GPO to Domain scope to get it applied to all computers in our domain.

    Best regards,

    Frank Shen


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, February 19, 2015 8:02 AM
    Moderator
  • I had a similar question myself, and you prompted me to search around.
    I found this blog post, which seems to me, to confirm that this is a client-side feature-change, and that there is no need to apply either the patch nor the settings to the server, for the client to be opted-in for this protection feature.

    Note that servers, are also clients, from the perspective of this feature, i.e. if you logon to a server and that causes a script etc to run from SYSVOL on the DC (as one simple example), the server you are logged on to is acting as a client.

    http://blogs.technet.com/b/srd/archive/2015/02/10/ms15-011-amp-ms15-014-hardening-group-policy.aspx

    This thread is also interesting:
    https://social.technet.microsoft.com/Forums/en-US/9745defb-9f30-4c28-8d96-eca929d25e3c/ms15011-kb3000483-kdc-fails-to-allow-access-to-netlogon-for-domain-members?forum=winserversecurity


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Thursday, February 19, 2015 9:00 AM
  • Thank you two for your replies. I ended up opening up a support case with Microsoft yesterday to get some clarifications. Here's a summary as I understood it:

    This isn’t as complicated as I initially thought in terms of scope of implementation. The important things to note are:

    • The concern is really focused on shares where executables run. Shares containing home directories are less of an issue because attackers are generally more focused on exploiting this vulnerability to run code/scripts without being noticed.
      • Therefore, in a domain environment, the sysvol and netlogon shares are the primary concerns because that’s where most user logon and computer start-up scripts are stored. Hardening the two UNC paths, \\*\SYSVOL and \\*\NETLOGON enhances security greatly and are really the main concerns.
    • This code and process is 100 percent “client” side driven. That is, the decisions and enforcement of the code is done by the “client” (the computer accessing the share). In a domain environment, “clients” are both workstations and servers because all systems are accessing the sysvol and netlogon shares while processing group policy. Therefore, installing the KB3000483 update on all systems is the best practice because all systems in the domain are “clients”.  Down-level systems like XP and non-Windows clients are unaffected by this update and new code. You can apply a UNC hardening GPO to XP clients or even newer clients that don’t have KB3000483 installed and no harm is done…the settings are simply ignored and those same clients will still be able to access the SYSVOL and NETLOGON shares as before—just not in the new, more secure manner.
    • Hardening UNC paths via GPOs is cumulative. That is, if we apply a UNC hardening GPO at the domain level to ensure sysvol and netlogon are hardened, OU administrators can create their own GPOs to harden UNC paths on their own servers and the end result on the client will be a cumulative list of hardened UNC paths. This is great news in a distributed support environment.
      • Even if the domain-level GPO is enforced, the lower-level OU GPO settings will still also apply to result in a cumulative list of hardened UNC paths on the client
      • The UNC hardening settings are stored in the registry on the clients at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
    • For each hardened UNC path, there are three types of security options. Mutual authentication, Integrity and Privacy.
      • Mutual authentication means the connection attempt must use Kerberos and cannot fall back to NTLMv2. If Kerberos cannot be used the connection will fail.
      • Integrity means SMB signing is required. If the client cannot negotiate SMB signing, the connection will fail.
      • Privacy means SMBv3 must be used. Only Server 2012 and Windows 8 support this. It is not recommend to use Privacy for now.
    • A valid test on a client to see if the installed update and GPO are working to harden a UNC path for mutual authentication is to try to access the hardened UNC path via IP address instead of server name. For instance, a hardened UNC path of \\*\SYSVOL  using RequireMutualAuthentication=1 will allow access via the path \\DC1\sysvol but will not allow access via \\192.168.1.1\sysvol This happens because in order for Kerberos to work the client must obtain a Kerberos ticket for the server to connect to. The client sends a request to the DC for a Kerberos ticket. Because the DC looks in AD to find a computer account with an SPN for the server name, using an IP address will fail because SPNs aren’t ever registered by IP address.  Therefore, using an IP address in a UNC path will always use NTLM and because we’ve set RequireMutualAuthentication for the UNC path, Kerberos is required and attempted access via IP address will fail. 


    -- Jason

    • Marked as answer by JasonBH Thursday, February 19, 2015 2:59 PM
    Thursday, February 19, 2015 2:59 PM