Ash's Blog

Changes to Convenience PIN / Windows Hello Behavior in Windows 10 Version 1607

Ash de Zylva — Sat, 13 Aug 2016 20:45:05 GMT

The purpose of this post is to quickly publish details of some changes designed to create distinction of our next generation credential, now called Windows Hello for Business and its associated PIN. If you are currently managing an enterprise computing environment utilizing Windows 10 with Windows Hello then you should read this article to determine if you need to take action. Please note that these changes should only affect Active Directory domain joined devices. Standalone devices and home PCs aren’t experiencing this change in the same way.

Recap on Windows Hello in Windows 10 Version 1511

Previously, there have been two paths to use Windows Hello (Biometric/PIN sign in) in your business: 1. You don’t deploy any additional infrastructure & you allow users to enrol a PIN or biometrics if they choose (this was the default) 2. You deployed Microsoft Passport for Work, which was the enterprise-grade, next generation credential that can be used to replace passwords. While using Passport for Work (now called Windows Hello for Business) offers huge security benefits, many organizations have yet to deploy the security technology, and are typically using #1 in the list above today. This is the focus of this article. The default behavior in Windows 10 Version 1511 is to allow users to enroll for a PIN (and Biometrics if the supported hardware is present) – the Settings app gives the user an “Add” button to initiate this flow: What this dialog doesn’t tell you is that since IT hasn’t configured Passport for Work infrastructure (Now called Windows Hello for Business), what you’re actually doing is creating a ‘convenience’ PIN. A Convenience PIN is very different to a Passport for Work (now called Windows Hello for Business) PIN because unlike the more secure option, it is merely a wrapper for the user’s domain password. The result of doing the enrollment above is that the users password is cached and substituted by the local system when signing in with a Convenience PIN. As mentioned, Windows 10, Version 1511 allows this type of enrolment by default. The reason is so that businesses and home users of all types can leverage Windows Hello Biometric logon from day one, and gain the simplicity of logging on using a gesture, without needing to deploy infrastructure. The control of this functionality was achieved through the “Use Passport for Work” group policy setting, or the “Use Biometrics” setting. Setting the “Turn on convenience PIN sign-in” had no effect and only applied to Windows 8.x. (Note that this GP setting might also appear as "Turn on PIN sign-in" - it's the same setting that was renamed in Windows 10.)

So, What's Changed?

Starting in Windows 10, Version 1607, the default behavior to allow convenience PIN creation has changed. The new default is that convenience PINs cannot be created on domain joined machines unless you specifically enable it via policy: This has implications for the following scenarios:

For newly built machines that are running 1607, you’ll notice that the options to configure PINs are greyed out and unavailable to users, whereas previously they were.
For machines that are upgraded to Windows 10, Version 1607 that have convenience PINs and biometrics enabled already for existing user accounts – they’ll still be able to sign in after the upgrade. That particular user will also be able to change their PIN, reset their PIN and remove their PIN:

However, if they do remove their PIN, they'll be unable to add one again or enrol Biometrics (because bio requires a PIN): In this scenario, this user can't use biometrics until the organisation deploys Windows Hello for Business infrastructure, or re-enables Convenience PIN sign in with policy. This is potentially a problem if your users have adopted PIN/Bio sign in and are expecting it to continue working the same way as it has previously. Specifically:

New users won't be able to enroll
Existing users won't be able to enroll on new or other PCs
If a user with a PIN and Biometric enrolment removes it, it can't be added again

If you wish to enable the original functionality for both scenarios above, you must specifically enable the Group Policy setting for Convenience PIN sign-in. You do this by setting the “Turn on convenience PIN sign-in”, which now controls the Convenience PIN behavior in Windows 10. (Note that this GP setting might also appear as "Turn on PIN sign-in" - it's the same setting that was renamed in Windows 10.) In summary, if you are looking to deploy Windows Hello for Business (formally Microsoft Passport for Work) then this might be the perfect opportunity to move to that more secure credential and not re-instate the convenience PIN sign in. However, if you have happy with the convenience PIN sign in functionality and security, you should enable the “Turn on convenience PIN sign-in” GP setting before you upgrade so that users can continue to use Windows Hello and not be interrupted by the upgrade. -Ash

WSUS Syncs Metadata, but Doesn't Download Updates

Ash de Zylva — Thu, 07 Jul 2016 12:10:08 GMT

Recently, I visited a customer who was having some challenges getting WSUS to synchronize with the public Windows Update service. While the fix is fairly straightforward, there isn't a lot of information around on this topic and was hard to find when doing Internet searches, so I'm documenting this here. In this particular case, this company had gone ahead and added the Windows Server role, configured the products they were after and update categories, and sync was successful. However, no matter what they tried, the updates themselves wouldn't download. To make this more confusing, there were no errors in the event log to help narrow down the problem. Turns out this particular issue was a problem with BITS (Background Intelligent Transfer Service) traffic and interactions with their "next generation" firewall doing inspection/modification of the traffic. If you are experiencing this, try running BITS in Foreground Download Mode. This essentially means that certain protocol commands (such as the RANGE parameters) aren't used as part of the query to get the content. The easiest way to do this in a way that just affects WSUS is to modify the configuration in the WSUS database directly. If you're hosting the WSUS database as a Windows Internal Database (WID), then the following command will do the trick:

sqlcmd -S \\.\pipe\MICROSOFT##WID\tsql\query -E -Q "update tbConfigurationC set BitsDownloadPriorityForeground=1"

Otherwise, if you're using SQL to host the database, you just need to execute the following against the SUSDB database either using the sqlcmd command above (changing out the WID DB for your SQL instance & DB) or just executing the following query using the SQL Management Studio and selecting the SUSDB database (recommended):

update tbConfigurationC set BitsDownloadPriorityForeground=1

After doing the above, restart the BITS Service (which will also restart WSUS which by default has a dependency on it) and requeue your downloads / syncs. Note that this issue generally doesn't occur with WSUS when used as part of System Center Configuration Manager since ConfigMgr queues the downloads itself rather than the call coming from WSUS, which has different defaults. Hope this helps!

Why Can't I Customize Certain Settings in Windows 10?

Ash de Zylva — Thu, 17 Mar 2016 15:50:40 GMT

The goal of this post is to help you understand some of the rationale as to why certain settings can or cannot be customized programmatically by OEMs or Enterprise IT in Windows 10. Note that we do review what mechanisms exist for customization and make improvements, so the specific limitations mentioned here may not be current. However, the overall rationale still applies to many aspects. One of Microsoft’s core priorities is to create more personal computing. One part of this includes respecting user preferences and not allowing 3rd parties to interfere with some user settings such as whether their camera can be turned on by an Universal App or whether software can install and add websites to your Internet favourites automatically. While there are obvious privacy implications with this (such as the camera example), there is also the expectation that users will be given a choice when these changes are made so they can choose what is right for them. We’ve been battling this problem for some time, and have made some decisions previously such as not allowing programmatic access to the Windows XP Start Menu pins which were designed to prevent applications from abusing this where they assume what the preferences of the user are and decide to set themselves front-and-centre. Windows 10 has more user preferences and areas than ever before – there are pins, Start tiles, jump lists, and Quick Access – just to name a few. All of these do not have programmatic access by design. That said, for some of these (eg, Start Layout) we do provide enterprise IT controls to bulk add these - but there is no item-by-item programmatic access. This has already had a great effect in preventing the cluttering of user controlled areas, such as the task bar. In addition, there are other settings such as search provider user preferences which have been a browser specific setting historically, but is becoming more essential to the operating system as Windows evolves, specifically with web search and Cortana. Search provider preference is another of these user settings to which we limit programmatic access due to the setting being abused by search engines as part of browser install procedures or bundled with other software. Also, some malware uses this approach to redirect users to ‘phishing’ versions of popular search engines. The approach here (with respect to search engine preferences) is a little different though. In Windows 10, 1511 and onwards, we don't allow for unattended programmatic access to change the search provider. When an application or script changes the setting, the user will be prompted within the browser to accept the change. If the user takes no action (ie, doesn't click accept), the change will be reversed. This means that you can theoretically set this (so can applications) but the user will need to accept the change. While this is designed to protect the user, I can appreciate this can be challenging for situations where you would prefer to automatically dictate the default for all of your users. Unfortunately this is not possible today without user intervention. As a workaround for Enterprise IT, we recommend that you create a guide that instructs users on how to select their search engine preferences. Alternatively, you can set the user’s search choice, and instructing the user to allow the change. Just remember that for the user to select the option in something like Edge, they need to have visit the other search engine's page first. Ash.

PSA - Known issue regarding Sysprep failing on Windows 10 image build & capture

Ash de Zylva — Wed, 16 Mar 2016 16:51:19 GMT

There's a known issue where sysprep fails (machine freezes or BSOD intermittently - SYSTEM_THREAD_EXCEPTION_NOT_HANDLED ) on Windows 10 when running on Hyper-V hardware. You would most commonly run across this issue when trying to prepare your image after running through a build-and-capture task sequence, usually using MDT. The cause is almost always an issue with the Legacy Network Adapter device type, which you might have used to enable PXE booting from inside the VM. To work around this issue, you should use Generation 2 VMs or Generation 1 VMs with non-legacy adapters (the standard adapter type). Note that if you are running with Gen 1 VMs and don’t use Legacy Adapters, you can't PXE boot - meaning you'll need to boot to an ISO or some other mechanism if you'll need that for your Windows 10 build.

Pimp my Windows 10 - Business Customization Reference

Ash de Zylva — Mon, 07 Mar 2016 04:58:41 GMT

This post serves to document the common asks from customers regarding what can and cannot be customized in Windows 10. Please check back regularly and share this post with others as I’ll be continuing to update it. Last updated August 2016 for Windows 10, Version 1607 - You'll see (New!) in sections that contain new content. There are many more settings than what's listed here - I'm just including the ones that are regular asks or issues that apply to many customers. Settings such as disabling the notification center aren't included because they remove a substantial benefit of the OS and generally aren't a good idea. I'm also not going to talk about things that are clearly unsupported such as deleting Windows files. There also a number of Group Policy settings that only apply to the Enterprise and Education SKUs of Windows 10 - these are being collected and documented here: https://technet.microsoft.com/en-us/itpro/windows/manage/group-policies-for-enterprise-and-education-editions Note that most MDM OMA URI’s listed below are documented here: https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962(v=vs.85).aspx and https://technet.microsoft.com/en-us/library/mt126215.aspx I've divided the settings up into categories:

Identity & Security
Interface & Shell
Included Apps
Other Customizations

Identity & Security

Block Microsoft Accounts

You can block MSA (Microsoft Account) using Group Policy, or MDM. These are the same settings available in Windows 8, but they behave slightly differently. While this setting continues to be enforced at the platform level, some pre-provisioned (built-in) apps (such as Photos and Store) allow you to sign into the app wth a Microsoft Account. Check out the blog post from my colleague below for more information about this. Reference Blog Post: http://blog.scottbreen.tech/2016/02/24/block-microsoft-accounts-windows-10/ Group Policy: Computer\Windows Settings\Security Settings\Local Policies\Security Options\Accounts: Block Microsoft Accounts MDM URI: ./Vendor/MSFT/Policy/Config/Accounts/AllowMicrosoftAccountConnection and AllowAddingNonMicrosoftAccountsManuall

(New!) Disable Wi-Fi Sense

This functionality is what allows users to connect to and share network details with others in their contacts. Many organisations like to disable this feature, which you can do so below. Note that the setting name only implies that it prevents users from connecting to networks shared with them, when in reality this setting blocks all aspects of Wi-Fi Sense, including the ability for your users to share networks with others, which is probably what you're looking for. Update: Wi-Fi Sense as a feature has been removed / deprecated in the 1607 release onwards. As such this setting is no longer relevant for that version. Group Policy: Computer\Admin Templates\Network\WLAN Service\Allow Windows to Automatically Connect to Suggested Open Hotspots

Interface & Shell

Set Lock Screen Background / Disable Windows Spotlight / Logon Screen Background

You can configure the lock screen background using the following setting. This setting is designed for Enterprise scenarios and doesn't work in the Pro or Home SKUs of Windows 10. Update: This setting was previously (Prior to Anniversary) called "Force a specific lock screen image". The name was changed to reflect that this setting now also controls the logon screen background. Group Policy: Computer\Admin Templates\Control Panel\Personalization\Force a specific default lock screen and logon image

Configure Start Menu Layout

There are a number of ways to do this. Previously you may have used CopyProfile in the Unattend to modify the default user profile but due to some issues with CopyProfile, it’s not a recommended approach currently. Instead, the way that seems to suit most businesses is to use a partial start layout, as documented in the link below. When you do this, you can have a section of Start that is for corporate apps, etc – but the remainder is available for customization by the user. To do this, configure a group on a test machine’s Start Menu the way you want it, and export it using the Export-StartLayout PowerShell cmdlet. Then use the file in one of the ways below. Note: You make a StartLayout XML file a Partial Layout by modifying the XML as per the link below. Reference Article: https://technet.microsoft.com/en-us/library/mt592638(v=vs.85).aspx Group Policy: User or Computer / Administrative Templates/Start Menu and Taskbar/Start Layout MDM URI: ./User/Vendor/MSFT/Policy/Config/Start/StartLayout PowerShell: (eg, if you want to do this in the build to load in a layout one-time for new user profiles) PS C:\> Export-StartLayout -Path \test.xml #Export on your lab machine setup the way you want PS C:\> Import-StartLayout -LayoutPath c\test.xml -mountpath c:\ #Import during task sequence or script

(New!) Set Taskbar Pins (Aka - the dreaded "How to Unpin Edge" question)

Updated for 1607: This is now possible! This is documented here: https://technet.microsoft.com/en-us/itpro/windows/manage/configure-windows-10-taskbar They key things to note is that this uses the same import methods for setting the Start Menu layout and requires editing that file to include the desired outcome for the taskbar. I'll be working on a separate blog post for this and I'll add a link here when it's available. Unpin Edge, Windows Store etc: You should use the layoutmodification.xml method from the link above.

Disable Windows Store (including Unpinning from Taskbar)

You can disable the Windows Store altogether, but only in Enterprise editions of Windows. When you disable the store app using Computer Group Policy, the updating of pre-provisioned (built-in) apps is disabled. If you want to disable the Store and still allow these apps to download, set this via user GP. Note that doing this will also result in the Store not being pinned to the taskbar. Also note that if you do this, you'll be unable to use the Private Store / Windows Store for Business functionality as this is accessed from within the Store application. Group Policy: User (or Computer)\Administrative Templates\Windows Components\Store\Turn off the store application MDM URI: No direct equivalent. You can use the AppLocker CSP to deny the Store App

Default Browser and File Associations

You can use this setting to make Internet Explorer the default browser in Windows 10. Feel free to set this, but remember that Edge is faster and more secure and is generally a better option for surfing the Internet. There is a separate setting (see below) for sending Intranet site traffic to IE in case you prefer that. Set everything the way you want it and export: Dism /Online /Export-DefaultAppAssociations:\\Server\Share\AppAssoc.xml Import via- Command Line: Dism.exe /Image:C:\ /Import-DefaultAppAssociations:\\Server\Share\AppAssoc.xml Group Policy: User \ Admin Templates \ Windows Components \ File Explorer \ Set a default associations configuration file

(New!) Send Intranet Traffic to Internet Explorer

As an alternative to, or in conjunction with setting the default browser, you can have Intranet zone sites opened in Edge trigger Edge to launch the site in Internet Explorer. Update: In Windows 10, Version 1607 - the intermediary page prompting the user to click to open the page in IE has been removed - the page just opens in IE as per IT configuration. Group Policy: User or Computer\Admin Templates\Windows Components\Microsoft Edge\Send all intranet traffic over to Internet Explorer OMA URI: None currently (March 2016)

(New!) Display Only The Business Store in The Windows Store App

This setting causes the Store App (it must be enabled itself) to only display the Private Store tab/pane and disables the retail experience. This is a much more preferred method versus disabling the store application altogether, and provides flexibility for you to configure and deploy and use Windows Store for Business at a later stage with minimal user impact. Group Policy: In 1607 - there is a GP now for this: User / Admin Templates / Windows Components / Store / Only display the private store within the Windows Store app MDM URI: ./User/Vendor/MSFT/Policy/Config/ApplicationManagement/RequirePrivateStoreOnly

Included Apps

Disable Automatic Twitter, Candy Crush, etc

These are automatically added apps that install out of the box. Note that the setting will not remove the apps if they are already installed, you need to set this early on which is why I’ve included the registry key below in case you want to set this in the image/build. This setting also disables suggested apps on the Start menu. Reference Blog Post: http://blogs.technet.com/b/mniehaus/archive/2015/11/23/seeing-extra-apps-turn-them-off.aspx Group Policy: Computer / Admin Templates / Windows Components / Cloud Content / Turn off Microsoft consumer experiences MDM URI: ./User/Vendor/MSFT/Policy/Config/Experience/AllowWindowsConsumerFeatures Registry: HKLM \ Software \ Policies \ Microsoft \ Windows \ CloudContent \ DisableWindowsConsumerFeatures = 1

Other Customizations

Disable Windows Tips

Windows Tips are the toast notifications you might have seen that are designed to help you get the most out of Windows. One of the reasons why you might want to disable these is because of the “Disable Apps to Help Improve Performance” tip that might be undesirable for your users if you’re already controlling what apps are disabled for them. Group Policy: Computer \ Admin Templates \ Windows Components \ Cloud Content \ Do Not show Windows Tips MDM URI: ./User/Vendor/MSFT/Policy/Config/Experience/AllowWindowsTips

Defer Updates (Windows Update for Business)

The Windows Update for Business settings are used to ensure clients are serviced in a delayed fashion, ensuring they are on the Current Branch for Business servicing model rather than Current Branch. Group Policy: Computer\Admin Templates\Windows Components\Windows Update\Defer Upgrades MDM URI: ./Vendor/MSFT/Policy/Config/Update/RequireDeferredUpdate

Telemetry Settings

These settings control Windows sending telemetry data to Microsoft. Note that a setting of 0 does not mean Windows won’t connect to Microsoft – it just means telemetry data won’t be sent. Also note that Windows Update for Business settings (Defer Upgrades) won’t work with this set to 0. Telemetry settings are documented in detail at the link below, so I won’t cover them here, but these are the levels: 0 – No telemetry data is sent from OS components (Only applies to Enterprise and Server) 1 – Sends basic telemetry data. 2 – Sends enhanced telemetry data including usage and insights data. 3 (default) – Sends full telemetry data including diagnostic data, such as system state. Related Link: https://technet.microsoft.com/en-us/library/mt577208(v=vs.85).aspx Group Policy: Computer\Admin Templates\Windows Components\Data Collection and Preview Builds\Allow Telemetry MDM URI: ./User/Vendor/MSFT/Policy/Config/System/AllowTelemetry I really hope the information above is a valuable resource to you. If you’ve found it helpful – remember to share it with others! Until next time, Ash.

Jargon Busting: Azure AD Join, MDM Enrolment & Add Account

Ash de Zylva — Wed, 02 Mar 2016 20:00:33 GMT

The terms used to describe MDM and cloud account sign in and management have evolved and changed over time from the original terms used in Windows 8. This post’s purpose is to give you the low-down on the options available to you in Windows 10, Version 1511 and onwards. They have had many names and functions, but the key point you should take away from this post is that there are only two types of enterprise cloud identity (Azure AD) you need to consider in Windows 10, and either can trigger MDM enrolment to occur if you wish. So we’ve had many names, but we’re actually only talking about three things: Azure AD Join, Work or School Accounts, and Device Management (MDM). A simple representation of this is as follows: We’ve had many names for these things in older versions of Windows 10, and in Windows 8:

Device Enrolment
Device Registration
MDM management
Workplace Join
and many more..

Forget everything you’ve heard before. There are just two ways to use an AAD account:

Azure Active Directory Join (AADJ) – Where the device joined Azure AD instead of your on premises, Windows Server AD the way you typically would. This allows the user to sign in with their corporate (Azure AD) credentials at the sign-in screen as their Primary Account. You can’t AADJ & traditional AD Join at the same time.
Add Work or School Account (“Add Account”) - Which adds an additional account (a Secondary Account) to the users login that facilitates single sign on (SSO) even when the user is logged on with some other account as their primary account (Eg, local account, Microsoft Account, etc). You can be traditional AD joined and still use the Add Account functionality.

There is also just one Mobile Device Management (MDM) type you need to worry about, which is MDM Enrolment. The term ‘enrol’ or ‘enrolment’ is used to imply MDM. Finally, you can either use the ways above to add an AAD account to automatically enrol in an MDM (using the Enrolment URL capabilities of Azure AD) or you can just manually enrol in MDM and add or use no corporate identity (except for enrolling in MDM. of course). When should I use one versus the other? One common question after covering the above is where each is intended to be used. With some exceptions depending on your organization’s needs, the identity options are geared as follows:

Azure AD Join (AADJ) is primarily designed for corporate-owned devices. Since you’ll be primarily signing in with a corporate identity, it’s not as suitable for personally-owned devices.
Add a Work or School Account is intended for all (other) use cases, so that corporate credentials can be added to the logged on user’s account, regardless of what they are logged on with – for example the user may be logged on with their Microsoft Account, but they may wish to add their corporate or school account as a secondary account.

I hope this has helped you better understand the options available in Windows 10!

Windows 10 Device Guard and Credential Guard Demystified

Ash de Zylva — Wed, 02 Mar 2016 02:39:03 GMT

While helping Windows Enterprise customers deploy and realize the benefits of Windows 10, I've observed there's still a lot of confusion regarding the security features of the operating system. This is a shame since some of the key benefits of Windows 10 involve these deep security features. This post serves to detail the Device Guard and Credential Guard feature sets, and their relationship to each other. First, let's set the foundation by thinking about the purpose of each feature: Device Guard is a group of key features, designed to harden a computer system against malware. Its focus is preventing malicious code from running by ensuring only known good code can run. Credential Guard is a specific feature that is not part of Device Guard that aims to isolate and harden key system and user secrets against compromise, helping to minimize the impact and breadth of a Pass the Hash style attack in the event that malicious code is already running via a local or network based vector. The two are different, but complimentary as they offer different protections against different types of threats. Let's dive in and take a logical approach to understanding each. It’s worth noting here that these are enterprise features, and as such are included only in the Windows Enterprise client.

Virtual Secure Mode

The first technology you'll need to understand before we can really dig into either Device Guard or Credential Guard, is Virtual Secure Mode (VSM). VSM is a feature that leverages the virtualization extensions of the CPU to provide added security of data in memory. We call this class of technology Virtualization Based Security (VBS), and you may have heard that term used elsewhere. Anytime we’re using virtualization extensions to provide security, we're essentially talking about a VBS feature. VSM leverages the on chip virtualization extensions of the CPU to sequester critical processes and their memory against tampering from malicious entities. The way this works is the Hyper-V hypervisor is installed - the same way it gets added in when you install the Hyper-V role. Only the hypervisor itself is required, the Hyper-V services (that handle shared networking and the management of VMs themselves) and management tools aren't required, but are optional if you’re using the machine for ‘real’ Hyper-V duties. As part of boot, the hypervisor loads and later calls the real 'guest' OS loaders. The diagram below illustrates the relationship of the hypervisor with the installed operating system (usually referred to as the host operating system) The difference between this and a traditional architecture is that the hypervisor sits directly on top of the hardware, rather than the host OS (Windows) directly interacting at that layer. The hypervisor serves to abstract the host OS (and any guest OS or processes) from the underlying hardware itself, providing control and scheduling functions that allow the hardware to be shared. In VSM, we’re able to extend this by tagging specific processes and their associated memory as actually belonging to a separate operating system, creating a ‘bubble’ sitting on top of the hypervisor where security sensitive operations can occur, independent of the host OS: In this way, the VSM instance is segregated from the normal operating system functions and is protected by attempts to read information in that mode. The protections are hardware assisted, since the hypervisor is requesting the hardware treat those memory pages differently. This is the same way to two virtual machines on the same host cannot interact with each other; their memory is independent and hardware regulated to ensure each VM can only access it’s own data. From here, we now have a protected mode where we can run security sensitive operations. At the time of writing, we support three capabilities that can reside here: the Local Security Authority (LSA), and Code Integrity control functions in the form of Kernel Mode Code Integrity (KMCI) and the hypervisor code integrity control itself, which is called Hypervisor Code Integrity (HVCI). Each of these capabilities (called Trustlets) are illustrated below: When these capabilities are handled by Trustlets in VSM, the Host OS simply communicates with them through standard channels and capabilities inside of the OS. While this Trustlet-specific communication is allowed, having malicious code or users in the Host OS attempt to read or manipulate the data in VSM will be significantly harder than on a system without this configured, providing the security benefit. Running LSA in VSM, causes the LSA process itself (LSASS) to remain in the Host OS, and a special, additional instance of LSA (called LSAIso – which stands for LSA Isolated) is created. This is to allow all of the standard calls to LSA to still succeed, offering excellent legacy and backwards compatibility, even for services or capabilities that require direct communication with LSA. In this respect, you can think of the remaining LSA instance in the Host OS as a ‘proxy’ or ‘stub’ instance that simply communicates with the isolated version in prescribed ways. Deploying VSM is fairly straightforward. You simply need to verify you have the appropriate hardware configuration, install certain Windows features, and configure VSM via Group Policy. Step One: Configure Hardware In order to use VSM, you’ll need a number of hardware features to be present and enabled in the firmware of the machine:

UEFI running in Native Mode (not Compatibility/CSM/Legacy mode)
Windows 64bit and it’s associated requirements
Second Layer Address Translation (SLAT) and Virtualization Extensions (Eg, Intel VT or AMD V)
A Trusted Platform Module (TPM) is recommended.

Step Two: Enable Windows Features The Windows features you’ll need to make VSM work are called Hyper-V Hypervisor (you don’t need the other Hyper-V components) and Isolated User Mode: If these options are greyed out or unavailable for install, it will typically indicate that the hardware requirements in step one haven’t been met. You’ll notice the name of the feature is called Isolated User Mode in here. It actually is the Virtual Secure Mode feature – you can thank a last minute name change for that. In order to not confuse people, this isn’t planned to change to reflect the VSM name at this time, and may look to being integrated as a standard Windows feature at a later stage. Update: In Windows 10, Version 1607 this is indeed an integrated feature and no longer needs to be explicitly enabled. Step Three: Configure VSM VSM and the Trustlets loaded within are controlled via either Mobile Device Management (MDM) or Group Policy (GP). For the purposes of this article, I’ll cover the Group Policy method as that’s the most commonly used option, but the same configuration is possible with MDM. The GP setting you need to know about is called Turn On Virtualization Based Security, located under Computer Configuration \ Administrative Templates \ System \ Device Guard in the Group Policy Object Editor: Enabling this setting, and leaving all the settings blank or at their defaults will turn on VSM, ready for the steps below for Device Guard and Credential Guard. In this default state, only the Hypervisor Code Integrity (HVCI) runs in VSM until you enable the features below (protected KMCI and LSA).

Device Guard

Now that we have an understanding of Virtual Secure Mode, we can begin to discuss Device Guard. The most important thing to realize is that Device Guard is not a feature; rather it is a set of features designed to work together to prevent and eliminate untrusted code from running on a Windows 10 system. Device Guard consists of three primary components:

Configurable Code Integrity (CCI) – Ensures that only trusted code runs from the boot loader onwards.
VSM Protected Code Integrity – Moves Kernel Mode Code Integrity (KMCI) and Hypervisor Code Integrity (HVCI) components into VSM, hardening them from attack.
Platform and UEFI Secure Boot – Ensuring the boot binaries and UEFI firmware are signed and have not been tampered with.

When these features are enabled together, the system is protected by Device Guard, providing class leading malware resistance in Windows 10. Configurable Code Integrity (CCI) CCI dramatically changes the trust model of the system to require that code is signed and trusted for it to run. Other code simply cannot execute. While this is extremely effective from a security perspective, it provides some challenges in ensuring that code is signed. Your existing applications will likely be a combination of code that is signed by the vendor, and code that is not. For code that is signed by the vendor, the easiest option is just to use a tool called signtool.exe to generate security catalogs (signatures) for just about any application. More detail on this in an upcoming post. The high level steps to configure code integrity for your organization is:

Group devices into similar roles – some systems might require different policies (or you may wish to enable CCI for only select systems such as Point of Sale systems or Kiosks.
Use PowerShell to create integrity policies from “golden” PCs (use the New-CIPolicy Cmdlet)
After auditing, merge code integrity policies using PowerShell (if needed) (Merge-CIPolicy Cmdlet)
Discover unsigned LOB apps and generate security catalogs as needed (Package Inspector & signtool.exe – more info on this in a subsequent post)
Deploy code integrity policies and catalog files (GP Setting Below + Copying .cat files to catroot - C:\Windows\System32\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\)

The Group Policy setting in question is Computer Configuration \ Administrative Templates \ System \ Device Guard \ Deploy Code Integrity Policy: VSM Protected Code Integrity The next component of Device Guard we’ll cover is VSM hosted Kernel Mode Code Integrity (KMCI). KMCI is the component that handles the control aspects of enforcing code integrity for kernel mode code. When you use Configurable Code Integrity (CCI) to enforce a Code Integrity policy, it is KMCI and it’s User-Mode cousin, UMCI – that actually enforces the policy. Moving KMCI to being protected by VSM ensures that it is hardened to tampering by malware and malicious users. Platform & UEFI Secure Boot While not a new feature (introduced in Windows 8), Secure Boot provides a high-value security benefit by ensuring that firmware and boot loader code is protected from tampering using signatures and measurements. To deploy this feature you must be UEFI booting (not legacy), and the Secure Boot option (if supported) must be enabled in the UEFI. Once this is done, you can build the machine (you’ll have to wipe & reload if you’re switching from legacy to UEFI) and it will utilize Secure Boot automatically. For more information about the specifics of deploying Device Guard, start with the deployment guide.

Credential Guard

Although separate from Device Guard, the Credential Guard feature also leverages Virtual Secure Mode by placing an isolated version of the Local Security Authority (LSA – or LSASS) under it’s protection. The LSA performs a number of security sensitive operations, the main one being the storage and management of user and system credentials (hence the name – Credential Guard) Credential guard is enabled by configuring VSM (steps above) and configuring the Virtualization Based Security Group Policy setting with Credential Guard configured to be enabled. Once this is done, you can easily check if Credential Guard (or many of the other features from this article) is enabled by launching MSINFO32.EXE and viewing the following information: You can also check for the presence of the LSAIso process, which is running in VSM: I hope this article has been useful for you and answered at least some of your questions about Device Guard and Credential Guard. If your thirst for knowledge is not yet quenched and you need more information while you wait for the follow up posts, check out the following Channel9 videos that cover this topic: https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-in-Windows-10-with-Dave-Probert https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-Processes-and-Features-in-Windows-10-with-Logan-Gabriel https://channel9.msdn.com/Blogs/Seth-Juarez/Isolated-User-Mode-in-Windows-10-with-Dave-Probert Stay tuned for further posts about this and other Windows 10 features. Hey, why not subscribe? Ash.

Windows Enterprise Client Boot and Logon Optimization

Ash de Zylva — Tue, 11 Aug 2015 04:35:16 GMT

Hi folks,

My colleague Mark Renoden has been writing an excellent multi-part series on how to optimise your enterprise clients for performance.

If this is something that is of interest to you, check it out here:

http://blogs.technet.com/b/markrenoden/archive/2015/07/15/windows-enterprise-client-boot-and-logon-optimization-part-1-introduction.aspx

Really well written & covers the basics from the beginning - definitely worth the time investment to read!

Windows 10 and Device Limits for Store Apps

Ash de Zylva — Thu, 30 Jul 2015 07:27:56 GMT

Just a quick PSA to get the word out there as I've had a few questions today about this issue.

If you're seeing errors or receiving emails that your device limit for the Store has been reached, this may very well be why!

Background

When we first launched Windows 8, users were able to associate their Microsoft Account (MSA) with up to 5 devices at a time, and their Store Apps were able to be installed on any of those 5 devices.

Realising this number was too small, we dramatically increased the number from 5 to 81 (for Windows 8.1 - get it, 81?). Well, we've revisited this and made the number something a little more logical...

In Windows 10, this number is now 10.

What this means is if you've previously gone above 10 (but below 81) you'll not have had a problem, right up until you upgrade to Windows 10. Note that this limitation applied to Windows 10, not the store, so existing Windows 8.1 devices that are above 10 should be fine.

Your best bet to avoid problems? Go to https://account.microsoft.com/devices and check what devices are associated with your account, and remove ones you no longer need or have from the various categories.

Happy Windows 10 upgrading!

Friendly Reminder: Get off FRS now!

Ash de Zylva — Sun, 26 Jul 2015 19:43:00 GMT

As mentioned in my last post, the need for environments to move away from FRS replicating SYSVOL is getting more and more pressing. This article serves as a friendly reminder to:

1. Check if you've moved to using DFSR for SYSVOL replication

2. Migrate to DFSR if you haven't yet!

First, some backstory.

In the beginning, there was FRS

When designing Active Directory for Windows 2000, there was a requirement for a common "system volume" (SYSVOL) that clients could connect to regardless of their location. Although Active Directory was conceived as a directory database, there are (and were) a number of scenarios that required files (as apposed to database objects) - login scripts, Group Policy setting files, etc. Due to Active Directory database replication being multimaster, we needed a multimaster file replication service to go along with it, to facilitate the hosting of a writable copy of SYSVOL on every domain controller in the domain. There was the existing LMREPL (LanMan replication) service, but this was not multimaster and was not going to cut it.

Enter FRS. FRS was designed to be perfect for this purpose, and it was integrated tightly into the promotion and subsequent operation of domain controllers. The rest is history.

Almost.

FRS, for all it's virtues, also has a number of flaws, and many inefficiencies. The most famous of these is the dreaded FRS Journal Wrap which you may have been lucky enough to experience for yourself. Effectively, you can put many of these issues down to the fact that we're talking about a 15+ year old file replication technology, and a lot has changed since.

Then came DFSR

DFSR was developed as a replacement for FRS, addressing a number of limitations. Features such as automatic journal wrap recovery, remote differential compression, and greater scalability meant it was superior to FRS in every way. Introduced in Windows Server 2003 R2, DFSR was originally only able to be used to replicate normal folders (so not SYSVOL). In Windows Server 2008, support was added for DFSR for SYSVOL replication, and the status quo has continued since. All subsequent released versions of Windows Server have included support for using either FRS for DFSR for SYSVOL replication.

The reason for the continued support for FRS is mostly due to backwards compatibility - being able to have legacy domain controllers (eg, 2003) present in the environment was important to facilitate domain migrations. While there is a tool to assist you in migrating from FRS to DFSR, it required you to at least be running 2008 Domain Functional Level (DFL) as all DCs needed to at least be 2008 to support the replication of SYSVOL using DFSR.

Against the odds, it's getting worse

You might be inclined to think "sure, FRS is bad - but it hasn't fallen over yet, so there's no rush, right?" - wrong!

Your risk of running with FRS for SYSVOL replication is actually increasing for a few reasons:

More data is probably being added to SYSVOL increasing the likelihood of something bad happening
As no further investment in FRS is occurring, issues and updates are not being discovered or fixed
FRS is being removed from future versions of Windows Server, potentially blocking your Active Directory upgrade
Newer operating systems (such as Windows 8 or Server 2012) are designed under the assumption of having a highly performing SYSVOL replication engine

The last point is actually the most interesting of the four - the way that edits are handled by the PowerShell CMDlets and GPMC/GPEdit has changed slightly so that the system is more robust - but actually causes more problems when combined with FRS.

Effectively, edits/restorations of policy now invoke a series of successive changes that involve files getting renamed and copied around - the problem is that with FRS this can cause access violations that are handled poorly, potentially resulting in data loss. When there's a KB published for this, I'll put the link in here. In the meantime, the strong recommendation is not to edit group policy from Windows 8 or 2012 or later against a domain that replicates SYSVOL with FRS.

Migrate now

Migrating the DFSR is pretty simple. Rather than retyping the instructions here, check out the following page about using the DFSRMig utility to do this:

https://technet.microsoft.com/en-us/library/dd640019(v=ws.10).aspx

Happy hunting of FRS in your environment!