The moderator from the server forum suggested I post here (please see https://social.technet.microsoft.com/Forums/windowsserver/en-US/a894761b-963e-4e4a-a309-d28999209448/march-2017-security-updates-breaks-ntlm-authentication-of-samba-shares-over-netbios?forum=winserversecurity).

We had a production down weekend after installing Microsoft's security March 2017 rollup. This question is to help us understand what was included in the March rollup that broke production in order that we can properly document the workaround.

Scenario:

1. Windows 2008 R2 domain controllers.
2. March 2017 security rollup applied.
3. SAMBA shares hosted on AIX using NTLM authentication stopped working, giving access denied (client message)
Error on AIX host is: "FAILED with error NT_STATUS_NO_LOGON_SERVERS"
Error on AIX host is: "SPNEGO login failed: NT_STATUS_IO_TIMEOUT"
Observed UDP 137 packets sent from AIX to DC, but no response from DC (packets ignored or blocked at DC).
4. Domain controllers previously had installed KB3161949 which broke SAMBA using NETBIOS transport because of a tightened-up security posture due to the KB3161949 hotfix.
When KB3161949 is installed, there is a HKLM registry setting which will allow NETBIOS (UDP 137) with NTLM authentication outside of the local subnet by setting the AllowNBToInternet DWORD value to 1.
5. After installing March 2017 security rollup the AllowNBToInternet parameter no longer seems to work.

After much effort attempting to back out Microsoft March 2017 security updates on domain controllers (this did not resolve the issue) we solved our problem by making an emergency change to all AIX SAMBA to use Kerberos authentication.

It seems like the March rollup included a critical update to fix a denial of service vector in SMB. I am wondering if the SMB code fork deployed by Microsoft also contained code similar to that included in MS16-077 in a way that prevented the AllowNBToInternet option from working?

And please explain why, even after backing out the March rollup, the functionality of KB3161949 to AllowNBToInternet was no longer operational?

Note background information related to the issues exposed by KB3161949 are here: "https://social.technet.microsoft.com/Forums/windows/en-US/5b32fb1c-bb5d-4be0-8a61-5adcb6ea4eb7/kb3161949-june-2016-update-causes-network-file-shares-to-become-unavailable?forum=w7itpronetworking" and here is a link to the KB: "https://support.microsoft.com/en-us/help/3161949/ms16-077-description-of-the-security-update-for-wpad-june-14,-2016"

Often many of us work in an environment that is evolving to the latest OS, but perhaps technology or development of internal applications have held or slowed us from updating these to current standards. We are encouraged to use RSAT tools to manage these hosts and services, but these tools are only backwards compatible by N-1.

This means that with a Windows 10 (current build) laptop, which will use RSAT for 2016, I cannot manage my older Windows 2012 or even 2008r2 hosts. I then have to either use a VM which is running Win7 or 8.1 with RSAT to manage these or access the hosts directly. Making the tool go even backwards compatible N-2 versions would help - after all PowerShell is backwards compatible now.

Allow Microsoft Edge Favorites to be easily managed like the Internet Explorer Favorites folder structure (end user-manageable) and support folder redirection (especially in the Enterprise edition of Windows 10). The IE Favorites folder can be redirected to a network location and available on any computer a user logs into, Edge Favorites are stuck on the local hard drive in a non-user manageable form (ESE database). The same goes for Sticky Notes, in Windows 7 they were stored in the Roaming AppData folder and followed a user across computers. Now they have been converted to a "modern UI app" which is not readily supportable in the enterprise.

A bit of history here. Windows Deployment Services has been around for quite a number of years, and it uses a file-based deduplication mechanism to conserve disk space.

When we capture an image with WDS, what it is actually doing is creating hashes for all files on the disk and then checking to see if those hashes are present in RES.WIM. Any hashed files not present in RES.WIM are copied up to the server, added to RES.WIM, and then the disk image itself is just a list of hashes to pull out of RES.WIM to reconstruct the image.

Without deduplication, it is to our benefit to only create a single huge imaging group, because for each additional image group there is a new RES.WIM which is independent of the other and may duplicate hashed files from the other RES.WIM. Throw everything into it, XP, Vista, 7, 8, 10, and all of them automatically combine into a single huge RES.WIM hash pool that greatly reduces file storage.

Except RES.WIM has a problem in that we can never shrink it, because WDS cannot know what image files we've deleted and what hashed files it needs to keep. Even if we've deleted all our Win XP images, those files for XP will live on forever in the RES.WIM hash pool.

Apparently the only real way to shrink RES.WIM is to create a new image group, export images from the first one, and import to the new one, which takes up even more disk space, before we can finally remove the old image group to recover disk space. It's extremely unhandy and inconvenient.
,

Though, Microsoft has now come up with sector-based deduplication of drive volumes. Scan in the background, deduplicate identical sectors, and regain free disk space.

This accomplishes the same thing as the file-based deduplication of WDS, but this is now even better, because we can delete deduplicated files and we can recover the disk space used by the non-duplicate parts of the image file.

Sure, we can run both WDS and sector-based deduplication on the same drive, but then we still cannot ever shrink RES.WIM, so the benefits of dedupe + RES.WIM are less than just using deduplication alone.

It seems better to just disable WDS RES.WIM file hashing completely, save all images as raw huge file collections in separate WIMs, and then let the nightly optimization shrink the WIM image disk usage to nothing, merging its content with other WIM images previously saved to the deduplicated drive.

If we then delete unneeded images, we will recover disk space as expected, and disk usage will not just grow forever as with the current RES.WIM file dedupe.

Posted on Windows forums here:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/c33ce755-8c02-4f1c-94b9-2ac5cb79c794/2016-wds-deduplication-disable-reswim-usage?forum=winserversetup#c33ce755-8c02-4f1c-94b9-2ac5cb79c794

This is a security issue.

Hello

It's really strange that we use operating systems which do not describe its executables and their eligibility to access the internet.

If we monitor which programms access the internet on a Windows Machine, then we really often have to google for its executable name and just get informations like "we do'nt know what it does, but it is probably safe to allow internet access".

Therefore, please:
1) Finally, create a professional application & service architecture. No, to route everything over svchost.exe is not a secure design. Not at all.

2) Finally, create a datasheet for each executable and answer those questions:
a) For what is it responsible?
b) Is it a helper for a superior Function? (e.g. Hyper-V probably has different executables and services)
c) Does it need access to the LAN? Why?
d) Does it need access to the Internet? Why?
e) What kind of Data is transmitted?

We expect to get all knowledge, so that we are sure what we are doing when we create outgoing firewall rules.

Everything else is reckless.

Kind regards,
Tom